Критическая уязвимость MCP-шлюза IBM ContextForge: CVSS 10 и побег из песочницы

Коротко о главном

10 сентября 2026 года в популярном open-source MCP-шлюзе IBM ContextForge (пакет mcp-contextforge-gateway в PyPI) закрыли уязвимость CVE-2026-53710 с максимальным баллом CVSS 10.0. Дефект в компоненте python_sandbox_server позволяет обойти песочницу RestrictedPython и через инструмент execute_code выполнить произвольные команды операционной системы с правами процесса-сервера — а при экспозиции по HTTP/SSE ещё и без аутентификации. Уязвимы все версии до 1.0.2; исправление — обновление до 1.0.2 и выше. Если ваша команда разворачивает ИИ-агентов через этот шлюз, это повод для внепланового аудита, а не для планового патча к следующему релизу.

Для команд, которые строят агентные ИИ-системы, вывод прямой: слой оркестрации инструментов (MCP) стал полноценной поверхностью атаки, и его безопасность нельзя откладывать. Мы в YuSMP регулярно закрываем такие риски в рамках услуг по информационной безопасности и аудита кода приложения — ниже разбираем, что именно сломалось и как реагировать.

Что такое MCP-шлюз и почему это важно

Model Context Protocol (MCP) — открытый протокол, через который большие языковые модели вызывают внешние инструменты: базы данных, API, файловую систему, выполнение кода. ContextForge — это шлюз-оркестратор от IBM, который федерирует множество MCP-серверов за единой точкой входа, добавляет аутентификацию, наблюдаемость и маршрутизацию вызовов. По сути это «маршрутизатор» между ИИ-агентом и всем, к чему агент может дотянуться в инфраструктуре. Компрометация такого шлюза открывает доступ ко всей связанной с ним периферии сразу.

Один из подпроектов ContextForge — python_sandbox_server, который даёт агенту инструмент execute_code для выполнения Python-кода в изолированной среде на базе библиотеки RestrictedPython. Идея песочницы в том, чтобы разрешить полезные вычисления, но запретить опасные операции — доступ к файловой системе, запуск подпроцессов, импорт системных модулей. Именно эта изоляция и оказалась дырявой.

Как устроена уязвимость

По данным GitHub Security Advisory (GHSA-xm98-3vcf-fph7) и базы PyPI/OSV, побег из песочницы становится возможен из-за трёх накладывающихся ошибок. Во-первых, «сырой» встроенный getattr оставлен доступным в наборе safe_builtins без обязательной обёртки _getattr_, которая по правилам RestrictedPython должна опосредовать доступ к атрибутам. Во-вторых, проверка validate_code ищет опасные dunder-строки (вроде __globals__, __subclasses__) буквальным сравнением подстрок — а вредоносный код собирает эти имена динамически в рантайме, и фильтр их не замечает. В-третьих, инструмент execute_code может быть выставлен по транспорту HTTP/SSE вообще без слоя аутентификации.

Публичный PoC демонстрирует цепочку: код на лету конструирует dunder-имена, через доступный getattr проходит по иерархии классов Python, добирается до subprocess.Popen и запускает команду ОС. В боевом сценарии это означает полное выполнение произвольного кода на хосте, где работает сервер песочницы. Вектор атаки — сетевой, сложность низкая, привилегии и участие пользователя не требуются: отсюда и вектор CVSS AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H с максимальным баллом 10.0. Флаг S:C (Scope: Changed) отражает как раз то, что компрометация выходит за границы уязвимого компонента.

Что это значит для команд разработки

Главный урок шире одного CVE: песочница на базе RestrictedPython — это не граница безопасности, на которую можно полагаться против недоверенного ввода. RestrictedPython изначально задумывался как инструмент ограничения «полудоверенного» кода, а не как защита от целенаправленной эксплуатации. Как только LLM-агент получает возможность выполнять сгенерированный или пришедший извне код, любой такой «изолятор» нужно рассматривать как потенциально пробиваемый и укладывать вокруг него настоящие границы — контейнерную изоляцию, seccomp/AppArmor, сетевую сегментацию и минимум привилегий у процесса.

Второй урок — про экспозицию. Инструмент выполнения кода, доступный по сети без аутентификации, превращает «внутреннюю утилиту для агента» в открытую дверь для любого, кто дотянется до порта. Для агентных систем это типовая ошибка: разработчики держат в голове, что «инструментами пользуется только наш агент», и не закрывают транспорт. Практический вывод — инвентаризация всех MCP-серверов и инструментов, которые вы разворачиваете, с явной проверкой, какие из них слушают сеть и требуют ли они аутентификации.

Что делать прямо сейчас

Немедленно обновите mcp-contextforge-gateway до версии 1.0.2 или новее — это устраняет корневую причину. Если обновиться сразу нельзя, отключите или закройте доступ к инструменту execute_code и не выставляйте python_sandbox_server в сеть; ограничьте транспорт HTTP/SSE аутентификацией и доверенной подсетью.

Дальше — проверьте логи шлюза на подозрительные вызовы execute_code и аномальные дочерние процессы у сервера песочницы за период до патча: раз есть публичный PoC, стоит исходить из того, что сканирование началось. Убедитесь, что процесс песочницы работает под непривилегированным пользователем и в изолированном контейнере с урезанными capabilities, чтобы даже успешный побег упирался в следующий слой защиты. И заложите в процесс регулярную проверку зависимостей MCP-стека: экосистема ContextForge за последние месяцы получила и другие серьёзные находки, включая SSTI-уязвимость в рендеринге шаблонов через несанкционированное окружение Jinja2.

Часто задаваемые вопросы

Насколько это серьёзно? Максимально: CVSS 10.0, удалённое выполнение кода без аутентификации при сетевой экспозиции инструмента. Это верхняя граница шкалы критичности.

Какие версии затронуты и где исправление? Уязвимы все версии mcp-contextforge-gateway до 1.0.1 включительно; исправление вышло в 1.0.2. Обновление до 1.0.2 или новее закрывает дефект.

Мы используем MCP, но не ContextForge — нас это касается? Конкретный CVE — про ContextForge. Но методический вывод универсален: любой инструмент выполнения кода у ИИ-агента нужно изолировать по-настоящему и не полагаться на песочницу уровня библиотеки как на границу безопасности.

Была ли эксплуатация в реальных атаках? На момент публикации подтверждённых массовых атак не заявлено, но опубликован рабочий PoC. Для критичной инфраструктуры это достаточный повод считать риск активным и патчиться в приоритетном порядке.

Источники

GitHub Security Advisory — GHSA-xm98-3vcf-fph7: mcp-contextforge-gateway has RestrictedPython sandbox bypass via getattr builtin in python_sandbox_server (первоисточник вендора).

OSV / PyPI Advisory Database — PYSEC-2026-3862 (CVE-2026-53710), CVSS 10.0, исправление в 1.0.2.