Исследователи кибербезопасности выявили критическую слабость в архитектуре Model Context Protocol (MCP), который применяется для интеграции больших языковых моделей (LLM) с внешними инструментами и сервисами. Ошибка, заложенная на архитектурном уровне, открывает путь к удалённому выполнению произвольного кода (RCE) и создаёт значимые риски для всей цепочки поставок ИИ-решений.
Суть уязвимости MCP: от конфигурации к выполнению команд
По данным OX Security, проблема кроется в том, как официальный SDK MCP от Anthropic реализует обмен через транспорт STDIO (standard input/output). Небезопасные значения по умолчанию в конфигурации приводят к тому, что путь от конфигурационных параметров до исполнения системных команд оказывается практически прямым. В результате злоумышленник может добиться выполнения произвольных команд на сервере, где запущен уязвимый MCP-сервер.
Исследователи отмечают, что реализация STDIO-интерфейса во всех поддерживаемых языках — Python, TypeScript, Java, Rust и др. — фактически допускает исполнение любой команды операционной системы. Если команда успешно поднимает STDIO-сервер, ей возвращается «дескриптор» подключения. Если же команда иная, выполнение всё равно происходит, но завершается с ошибкой уже после факта исполнения, что и открывает путь к RCE.
Масштаб проблемы: тысячи серверов и сотни миллионов загрузок
По оценке OX Security, архитектурная уязвимость затрагивает официальный SDK MCP Anthropic во всех языковых обвязках. На практике это означает более 7 000 публично доступных серверов и программных пакетов с совокупным числом скачиваний свыше 150 миллионов. Таким образом, речь идёт не о частном инциденте, а о типичном для цепочки поставок ИИ системном риске: одна неудачная архитектурная конструкция наследуется всеми downstream-проектами.
На базе этой слабости было обнаружено как минимум 10 уязвимостей в популярных экосистемах для работы с LLM: LiteLLM, LangChain, LangFlow, Flowise, LettaAI, LangBot и других. Во всех случаях итоговый эффект сводится к возможности удалённого выполнения команд на сервере, где внедрён уязвимый MCP-интерфейс.
Связанные CVE и реакция экосистемы
За последний год различные команды исследователей независимо фиксировали уязвимости, основанные на том же корневом дефекте протокола. Среди них: CVE-2025-49596 (MCP Inspector), уязвимости в LibreChat (CVE-2026-22252), WeKnora (CVE-2026-22688), @akoskm/create-mcp-server-stdio (CVE-2025-54994) и Cursor (CVE-2025-54136). Каждая из них проявляется по-разному, но общая логика одна — небезопасное использование STDIO в рамках MCP-протокола, что приводит к RCE.
Часть вендоров уже выпустила исправления или изменила конфигурацию по умолчанию, уменьшая риски эксплуатации. Однако Anthropic отказалась менять архитектуру MCP, указав, что текущее поведение протокола считается ожидаемым. Это оставляет в силе проблему в референсной реализации, от которой продолжают наследовать код тысячи разработчиков.
Почему это supply chain-проблема для ИИ
Особенность инцидента в том, что он затрагивает не один продукт, а всю экосистему, полагающуюся на Model Context Protocol. Как подчёркивают исследователи OX Security, одно архитектурное решение, принятое однажды, «протекло» во все языковые реализации, сторонние библиотеки и проекты, доверившиеся MCP как безопасному протоколу. В терминах кибербезопасности ИИ это типичный инцидент на уровне цепочки поставок (AI supply chain), когда уязвимость в базовом компоненте тиражируется по всей инфраструктуре.
Ситуация усугубляется тем, что LLM-агенты и MCP-интеграции часто имеют доступ к чувствительным ресурсам: внутренним базам данных, API-ключам, конфиденциальным чат-логам и бизнес-логике. Компрометация MCP-сервера с RCE даёт злоумышленникам прямой доступ к этим данным и может привести к масштабным утечкам и саботажу процессов.
Практические рекомендации по снижению рисков
Усиление сетевой сегментации и контроля доступа
Организациям, использующим MCP или зависящие от него продукты, рекомендуется закрыть публичный доступ по IP к чувствительным MCP-службам и ограничить их использованием внутри защищённых сегментов сети. MCP-серверы не должны быть напрямую доступны из интернета без жёстких средств аутентификации и фильтрации.
Безопасная эксплуатация MCP и мониторинг
Критически важно обрабатывать любые внешние конфигурации MCP как недоверенные данные и избегать передачи в них необработанных пользовательских входных значений. MCP-совместимые сервисы стоит запускать в изолированных средах (sandbox, контейнеры с ограниченными правами), минимизируя потенциальный ущерб от RCE. Также необходимо логировать и анализировать вызовы MCP-инструментов, чтобы своевременно обнаруживать аномальное поведение.
Гигиена цепочки поставок ИИ
Ещё один ключевой шаг — использовать MCP-серверы и библиотеки только из проверенных источников, отслеживать публикации о новых CVE и своевременно обновлять зависимости. Практики классической supply chain-безопасности (SBOM, контроль целостности, регулярные аудиты зависимостей) в контексте ИИ становятся не опцией, а необходимым стандартом.
Инцидент с MCP наглядно демонстрирует, как одно на первый взгляд технически оправданное решение в протоколе может превратиться в критический фактор риска для всей экосистемы ИИ. Чтобы избежать повторения подобных сценариев, разработчикам и организациям, внедряющим LLM и MCP, стоит пересмотреть подход к угрозам на уровне архитектуры, усилить контроль за зависимостями и выстроить системный процесс управления рисками в цепочке поставок ИИ.
