# OX Security: архитектурный риск STDIO в MCP и десятки уязвимых AI-платформ

> OX Security опубликовала исследование о том, что транспорт STDIO в официальных MCP SDK запускает указанную в конфигурации команду без проверки. Если пользовательский ввод или внедрённая инструкция попадает в конфигурацию MCP, это ведёт к выполнению кода на сервере. По оценке исследователей, под риском до 200 тысяч экземпляров; Anthropic считает поведение ожидаемым.

- Канонический HTML: [/incidents/ox-security-mcp-stdio-design-flaw](https://ai-first.tech/incidents/ox-security-mcp-stdio-design-flaw)
- Язык: русский
- Редакционный принцип: защитный контекст без вредоносных полезных нагрузок и инструкций обхода.

- Дата: 2026-04-15
- Категория: Уязвимость платформы
- Затронуто: Продукты на официальных MCP SDK (Python, TypeScript, Java, Rust): LiteLLM, LangFlow, Flowise, Windsurf, Letta и другие
- Критичность: Критический
- CVE: CVE-2026-30615, CVE-2026-30623

## Что произошло

15 апреля 2026 года OX Security выпустила исследование под названием «The Mother of All AI Supply Chains». Исследователи сообщили более чем о 30 скоординированных раскрытиях и более чем 10 CVE в продуктах, использующих MCP SDK. Среди примеров — выполнение кода без аутентификации в LangFlow, обход проверки ввода во Flowise и выполнение кода через внедрение инструкций в Windsurf (CVE-2026-30615); LiteLLM выпустила отдельное исправление (CVE-2026-30623). По оценке OX, экосистема насчитывает более 150 млн загрузок SDK, более 7000 публично доступных MCP-серверов и до 200 тысяч уязвимых экземпляров. Anthropic отказалась менять протокол, назвав поведение ожидаемым, и добавила в документацию предупреждение об осторожном использовании STDIO.

## Где нарушилась защита

Транспорт STDIO запускает локальный процесс по команде из конфигурации и не проверяет, является ли он MCP-сервером. Многие платформы позволяли пользователям или самому агенту менять эту конфигурацию через веб-интерфейс или файл настроек. Граница доверия нарушилась на стыке: SDK переложил проверку на разработчиков, а продукты не проверяли, кто и какую команду туда записывает.

## Последствия

- Более 10 CVE и около 30 раскрытий в популярных AI-платформах
- До 200 тысяч потенциально уязвимых экземпляров по оценке исследователей
- Девять из одиннадцати проверенных каталогов MCP приняли тестовую вредоносную публикацию без проверки (по данным CSA)

## Реакция

Часть вендоров выпустила исправления, включая LiteLLM и Windsurf. Anthropic не стала менять архитектуру, сославшись на ответственность разработчиков за проверку ввода. Cloud Security Alliance выпустила аналитическую записку с рекомендациями.

## Уроки для бизнеса

- Позиция «так задумано» у вендора протокола переносит риск на каждую компанию, использующую SDK
- Конфигурация MCP — критичный объект: кто может её менять, тот может выполнять код
- Каталоги MCP-серверов нельзя считать проверенным источником

## Меры защиты

- Провести аудит всех STDIO-определений MCP в используемых продуктах
- Ввести список разрешённых команд для запуска MCP-серверов
- Запретить агентам и пользователям без прав администратора менять конфигурацию MCP
- Установить исправления LiteLLM, Windsurf, LangFlow и других затронутых продуктов
- Изолировать MCP-серверы в контейнерах с минимальными правами

Связанные карточки угроз: A33, A34, A47, A38

## Первоисточники

- [The Mother of All AI Supply Chains: Technical Deep Dive](https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-technical-deep-dive/) — OX Security
- [MCP by Design: RCE Across the AI Agent Ecosystem](https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-by-design-rce-ox-security-20260420-csa/) — Cloud Security Alliance
- [Security Update: CVE-2026-30623 — Command Injection via Anthropic's MCP SDK](https://docs.litellm.ai/blog/mcp-stdio-command-injection-april-2026) — LiteLLM