Источник: CERT/CC Vulnerability Note VU#777338 — https://kb.cert.org/vuls/id/777338
В SGLang обнаружены три опасные уязвимости, а исправления пока нет#
По данным CERT/CC, в SGLang выявлены три уязвимости: две позволяют выполнить произвольный код удалённо, ещё одна связана с обходом путей (path traversal). Для эксплуатации есть важные условия: должен быть включён режим multimodal generation, а атакующий должен иметь сетевой доступ к сервису SGLang.
Даже с этими ограничениями риск остаётся высоким для команд, использующих SGLang в AI-инфраструктуре. SGLang — это open-source-фреймворк для обслуживания LLM и мультимодальных моделей. CERT/CC отмечает поддержку Qwen, DeepSeek, Mistral и Skywork, а также совместимость с OpenAI API. Речь идёт не о локальном инструменте для экспериментов, а о компоненте, который часто находится прямо на пути обработки запросов к моделям.
Отдельное внимание заслуживает статус координации. На момент публикации, по данным CERT/CC, исправления отсутствовали, а сопровождающие проекта не ответили на запросы в процессе раскрытия информации.
Поэтому этот бюллетень нельзя воспринимать как типичную рекомендацию «обновитесь до исправленной версии». Пока основная мера защиты — контроль доступности сервиса.
Какие проблемы описывает CERT/CC#
CERT/CC сообщает о трёх независимых уязвимостях в среде выполнения multimodal generation.
Первая связана с удалённым выполнением кода через ROUTER-сокет планировщика (scheduler) в runtime multimodal generation. Согласно описанию, сокет содержит опасный обработчик входящих сообщений, который позволяет добиться RCE при доступности интерфейса из сети.
CERT/CC отдельно подчёркивает, что эта проблема отличается от CVE-2026-3060 и CVE-2026-3059. В тех случаях ZMQ broker автоматически привязывался ко всем сетевым интерфейсам без явного уведомления пользователя. Новая уязвимость, обозначенная как CVE-2026-7301, по описанию доступна через scheduler host, который по умолчанию слушает адрес 0.0.0.0.
Этот нюанс критически важен. Если сервис привязан к 0.0.0.0, он доступен через все сетевые интерфейсы, если только доступ не ограничивают firewall хоста, облачные security groups, сетевые политики контейнеров или внешний proxy. В AI-инфраструктуре внутренние инструменты часто разворачивают быстро и рассчитывают на приватность сети. Такие предположения перестают работать, когда сервис оказывается в слишком открытой VPC, общем пространстве Kubernetes, неправильно настроенном ingress или на тестовом сервере с публичным доступом.
Вторая проблема — path traversal без аутентификации в runtime multimodal generation. CERT/CC сообщает, что атакующий может записывать произвольные файлы в любые каталоги, куда процесс сервера имеет право записи, используя специальные последовательности в имени загружаемого файла при обращении к определённым endpoint.
Это не означает автоматическое выполнение кода, но риск остаётся серьёзным. Произвольная запись файлов может привести к краже учётных данных, изменению конфигурации, закреплению в системе или подготовке дальнейшей атаки — всё зависит от того, куда разрешена запись и как настроен сервер. При этом в бюллетене не утверждается, что каждая установка одинаково уязвима для дальнейшей компрометации после записи файлов. Консервативный вывод выглядит так: если недоверенный пользователь может обращаться к уязвимому endpoint, он потенциально способен размещать файлы в областях, доступных процессу SGLang.
Третья проблема — ещё один сценарий RCE без аутентификации, который возникает при включённой опции --enable-custom-logit-processor. По данным CERT/CC, объекты Python, загружаемые этим механизмом, десериализуются без проверки.
Этот параметр стоит проверить отдельно. Если опция не включена, данный путь эксплуатации может быть неприменим. Если же она активна на сервисе, доступном по сети, риск существенно возрастает. Небезопасная десериализация давно считается одним из классических способов добиться выполнения кода, особенно в системах Python, принимающих сериализованные объекты от внешних источников.
Наибольший риск — сервисы с сетевой доступностью#
Модель угроз в бюллетене достаточно проста: включённый multimodal mode плюс сетевой доступ к сервису. Публичный доступ из интернета — самый очевидный сценарий, но далеко не единственный.
Системы обслуживания моделей часто подключают к notebook-средам, API-шлюзам, пакетным обработчикам, платформам тестирования моделей, агентным фреймворкам и пользовательским приложениям. Если SGLang доступен недоверенным арендаторам, пользовательским нагрузкам, скомпрометированным контейнерам или сегментам сети со слабым контролем доступа, риск остаётся тем же.
Термин «сетевой доступ» не стоит трактовать слишком узко. Сюда входит прямое подключение к сервису SGLang, доступные интерфейсы scheduler, открытые порты контейнеров, облачные load balancer, чрезмерно разрешающие правила firewall и любые proxy-маршруты, пересылающие запросы к затронутым endpoint.
Для эксплуатации также имеет значение совместимость с OpenAI API. Такая совместимость упрощает замену backend-компонентов без изменений в клиентской части. Однако команды могут не пересматривать модель доверия для специфических интерфейсов каждого backend. Это безопасно только тогда, когда программное обеспечение хорошо изучено и имеет ограниченную поверхность атаки. Ситуация меняется, если дополнительные runtime-компоненты принимают сложные входные данные, например загрузки файлов или сериализованные объекты Python.
Что проверить#
Пока исправление отсутствует, CERT/CC рекомендует ограничить доступ к интерфейсам сервиса, изолировать их от недоверенных сетей и использовать сегментацию сети вместе с механизмами контроля доступа.
Практический список действий:
- Проверьте, используется ли SGLang где-либо в инфраструктуре, включая лаборатории, тестовые кластеры, notebook-среды и временные GPU-серверы.
- Проверьте, включён ли режим multimodal generation.
- Убедитесь, что scheduler host и связанные интерфейсы не привязаны к
0.0.0.0без необходимости. - Проверьте, что открытые порты недоступны из публичного интернета и недоверенных внутренних сегментов.
- Проведите аудит Kubernetes Services, ingress-правил, security groups, firewall хостов, VPN-маршрутов и публикации портов контейнеров.
- Проверьте использование опции
--enable-custom-logit-processor. - Рассматривайте endpoint с возможностью загрузки файлов как чувствительные до появления исправления или надёжных компенсирующих мер.
- Запускайте сервис с минимально необходимыми правами на файловую систему, чтобы ограничить последствия возможной записи файлов.
Если сервис должен оставаться доступным, разместите перед ним жёсткий механизм контроля доступа. Не полагайтесь на неизвестность порта, скрытые endpoint или предположение, что адрес знают только доверенные пользователи. При использовании reverse proxy проверьте, какие запросы он реально пересылает. Если сервис должен быть внутренним, обеспечьте это на сетевом уровне.
Чего не стоит утверждать#
В заметке CERT/CC нет информации об активной эксплуатации этих уязвимостей в реальных атаках. Также отсутствуют исправленная версия, комментарий сопровождающих проекта и полный перечень затронутых сценариев развёртывания.
Неправильно утверждать, что каждая установка SGLang автоматически уязвима для удалённой эксплуатации. CERT/CC указывает конкретные условия: должен быть включён режим multimodal generation, а атакующий должен иметь сетевой доступ к сервису. Один из путей RCE дополнительно зависит от включения --enable-custom-logit-processor.
Но и недооценивать проблему из-за этих условий не стоит. Платформы обслуживания AI-моделей часто работают в быстро меняющейся среде, где экспериментальные функции, широкие сетевые привязки и предположения о «внутреннем использовании» встречаются регулярно. Серьёзная уязвимость остаётся серьёзной даже тогда, когда для её эксплуатации требуется сетевой доступ.
Итог#
На момент публикации патча нет.
Если SGLang используется с включённым multimodal generation, рассматривайте его как критическую границу безопасности. Уберите публичную доступность, ограничьте внутренний доступ, проверьте использование custom logit processor и минимизируйте права на файловую систему. В некоторых случаях разница между локализованной проблемой и полной компрометацией сервера может сводиться к одному открытому интерфейсу.