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