Компанія Anthropic створила протокол Model Context Protocol (MCP) як відкритий стандарт для комунікації між ШІ-агентами та зовнішніми інструментами. У березні 2025 року OpenAI адаптувала його, а згодом приєдналася й Google DeepMind. У грудні 2025 року Anthropic передала MCP до Linux Foundation, і кількість завантажень перевищила 150 мільйонів. Однак нещодавно четверо дослідників з OX Security виявили архітектурну проблему, яка загрожує всім цим системам.
Стандартний транспортний механізм MCP на базі STDIO (стандартний ввід/вивід), який використовується для підключення ШІ-агента до локального інструменту, виконує будь-які отримані команди операційної системи без будь-якої перевірки або встановлення меж між конфігурацією та командою. Зловмисна команда може повернути помилку вже після свого виконання, при цьому інструменти розробника не генерують жодних попереджень.
Дослідники OX Security (Моше Сіман Тов Бустан, Мустафа Наамні, Нір Задок та Рон Бар) просканували екосистему та виявили 7 000 серверів на публічних IP-адресах з активним транспортом STDIO. Вони оцінюють загальну кількість вразливих екземплярів до 200 000, виходячи з виявленої пропорції. Дослідникам вдалося підтвердити виконання довільних команд на шести реальних виробничих платформах, які обслуговують клієнтів. В результаті дослідження було виявлено понад 10 CVE (Common Vulnerabilities and Exposures) з рейтингом “високий” або “критичний” для таких продуктів, як LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, Bisheng, DocsGPT, GPT Researcher, Agent Zero, LettaAI та інших.
Кевін Карран, старший член IEEE та професор кібербезпеки в Університеті Ольстера, незалежно підтвердив виданню Infosecurity Magazine, що дослідження виявило “шокуючу прогалину в безпеці фундаментальної ШІ-інфраструктури”.
Anthropic підтвердила, що така поведінка є штатною, і відмовилася вносити зміни до протоколу, характеризуючи модель виконання STDIO як безпечну за замовчуванням, а перевірку вхідних даних — як відповідальність розробника. Це позиція, яку висунула OX Security. Єдине, що Anthropic офіційно заявила, це слово “очікувана”. Компанія не випускала окремої публічної заяви та не відповіла на запит VentureBeat щодо коментарів.
OX Security стверджує, що вимога до 200 000 розробників правильно перевіряти вхідні дані є проблемою. Найсильніший технічний аргумент Anthropic: перевірка STDIO або порушить роботу транспорту, або перенесе вектор атаки на рівень нижче. Обидві позиції технічно обґрунтовані. Питання полягає в тому, що робити, поки триває ця дискусія.
Більшість великих видань висвітлили цю проблему. Однак жодне з них не надало детального аудиту за кожним продуктом, який необхідний керівнику служби безпеки для оцінки власних розгортань MCP. Ця публікація має на меті це виправити.
П’ять ключових питань допоможуть визначити, чи вразливі ваші розгортання MCP, чи тримаються ваші патчі та які дії слід вжити негайно.
Чи вразливі ми?
Якщо ваші команди розгорнули будь-який ШІ-агент, підключений через MCP, використовуючи стандартний транспорт STDIO, то відповідь — так. Ця вразливість не є помилкою в коді окремого продукту. Це конструктивна особливість за замовчуванням у специфікації MCP від Anthropic, яка поширилася на всі офіційні SDK мовами Python, TypeScript, Java та Rust. Кожен наступний проєкт, що довіряв протоколу, успадкував її.
OX Security ідентифікувала чотири основні вектори експлуатації: ін’єкція команд без автентифікації через веб-інтерфейси ШІ-фреймворків (продемонстровано на LangFlow та LiteLLM); обхід механізмів безпеки в інструментах, які використовували білі списки команд, шляхом ін’єкції аргументів (npx -c), що було продемонстровано на Flowise та Upsonic; атаки “нульового кліку” (zero-click prompt injection) в IDE для розробки ШІ, де шкідливий HTML-код змінює локальні конфігураційні файли MCP. Windsurf (CVE-2026-30615) став єдиним IDE, де експлуатація вимагала нульової взаємодії з користувачем, хоча Cursor, Claude Code та Gemini-CLI також вразливі до більш загальних атак цього типу. Також існує ризик розповсюдження шкідливих пакетів через реєстри MCP, куди OX Security надіслала безпечний доказ концепції (proof-of-concept) до 11 реєстрів, і дев’ять з них прийняли його без перевірки безпеки.
Картер Ріс, віце-президент з ШІ та машинного навчання в Reputation та член Комісії з питань ШІ штату Юта, заявив виданню VentureBeat, що фокус розгляду проблеми має змінитися: “STDIO протоколу MCP — це поверхня привілейованого виконання, а не з’єднувач. Корпоративні команди повинні ставитися до нього як до доступу до production-оболонки: забороняти за замовчуванням, використовувати білі списки, ізолювати та припинити покладатися на те, що перевірка вхідних даних на нижчих рівнях витримає навантаження в масштабі”.
Особливу увагу слід приділити сімейству IDE, оскільки воно вражає робочі станції розробників, а не сервери. Розробник, який відвідує вебсайт, контрольований зловмисником, може ініціювати зміну свого локального конфігураційного файлу MCP. У випадку Windsurf, зміна виконується негайно без запиту на підтвердження. Cursor, Claude Code та Gemini-CLI вимагають певної форми взаємодії з користувачем, але якщо інтерфейс демонструє зміну конфігурації, не показуючи наслідків виконання, натискання “підтвердити” не є усвідомленою згодою.
Чи виправив проблему постачальник?
Деякі постачальники це зробили. Деякі частково. Деякі ще не підтвердили. Наведена нижче таблиця відображає кожен вразливий продукт, тип експлуатації, стан виправлення та залишену прогалину. Критичним є стовпець “Виправлення протоколу?”. У кожному рядку стоїть “Ні”.
|
Продукт |
Тип експлуатації |
Виправлено? |
Виправлення протоколу? |
Прогалина |
Дії |
|
LiteLLM |
Ін’єкція команд через UI адаптера |
ТАК |
НІ |
LiteLLM виправлено. Нові конфігурації STDIO поза LiteLLM успадковують те саме вразливе за замовчуванням. |
Зафіксуйте версію v1.83.7-stable або новішу (CVE-2026-30623). Перевірте за консультативним висновком GitHub. Проведіть аудит усіх інших визначень STDIO. |
|
LangFlow |
Виконання віддаленого коду через публічний auto_login + STDIO |
Частково |
НІ |
Токен автентифікації вільно доступний через публічний кінцевий пункт. STDIO виконує все, що йде за ним. |
Блокуйте публічний auto_login. Ізолюйте всі MCP-сервіси від хост-системи. |
|
Flowise / Upsonic |
Обхід білого списку (ін’єкція аргументів npx -c) |
Посилено, обхід підтверджено |
НІ |
Білий список дає хибне відчуття безпеки. OX обійшов його. Це тривіально. |
Не покладайтеся на білі списки команд. Застосовуйте ізоляцію процесів на рівні sandbox. |
|
Windsurf (CVE-2026-30615) |
Ін’єкція промптів без взаємодії до локального виконання коду |
ЗАЯВЛЕНО, не підтверджено |
НІ |
Єдине IDE з експлойтом, що вимагає нульової взаємодії. Вражає робочі станції розробників, а не сервери. |
Вимкніть автоматичну реєстрацію MCP-сервера. Вручну перегляньте всі активні конфігурації. |
|
Cursor / Claude Code / Gemini-CLI |
Ін’єкція промптів до зміни локальної конфігурації MCP |
Cursor виправлено (CVE-2025-54136); інші варіюються |
НІ |
Потрібна взаємодія користувача, але UI зміни конфігурації не відображає наслідків виконання. Підтвердження не є усвідомленою згодою. |
Перевірте конфігураційні файли MCP (~/.cursor/mcp.json, аналогічні шляхи). Вимкніть автоматичну реєстрацію. Перегляньте всі очікуючі зміни конфігурації перед підтвердженням. |
|
Langchain-Chatchat (CVE-2026-30617) |
Виконання віддаленого коду через транспорт MCP STDIO |
ЗАЯВЛЕНО, не підтверджено |
НІ |
Фреймворк чат-ботів успадковує той самий стандарт STDIO. Статус виправлення не підтверджено. |
Інвентаризуйте всі розгортання Langchain-Chatchat. Ізолюйте від хост-системи. Відстежуйте поради постачальника щодо виправлення. |
|
Реєстри MCP (9 з 11) |
Прийнято шкідливий PoC без перевірки |
Н/З |
НІ |
Реєстрам бракує перевірки безпеки надходження. Встановлення призводить до ризику бекдора. |
Використовуйте реєстри з документованою перевіркою надходження. Перевіряйте встановлені пакети за відомими хешами. |
Чи переживе проблема виправлення?
Так. Кожне виправлення на рівні продукту в таблиці усуває конкретну точку входу в цьому продукті. Жодне з них не змінює поведінку протоколу MCP STDIO. Керівник служби безпеки, який сьогодні виправляє LiteLLM, а завтра налаштовує новий MCP STDIO-сервер, успадкує ту саму вразливу конфігурацію за замовчуванням на новому сервері. Виправлення необхідні, але недостатні.
Це було передбачувано. Коли VentureBeat вперше повідомив про проблеми безпеки MCP у січні, Меррітт Бер, головний співробітник з безпеки Enkrypt AI та колишній заступник CISO в AWS, попереджала: “MCP постачається з тією ж помилкою, яку ми бачили в кожному великому розгортанні протоколу: вразливі налаштування за замовчуванням. Якщо ми не вбудуємо автентифікацію та принцип найменших привілеїв з самого початку, ми будемо виправляти наслідки витоків протягом наступного десятиліття”. Cloud Security Alliance незалежно підтвердила висновки OX Security в окремій дослідницькій нотатці та рекомендувала організаціям розглядати інфраструктуру, пов’язану з MCP, як активну, невиправлену загрозу. Налаштування за замовчуванням не змінилися. Поверхня атаки зросла.
Ріс стверджував, що позиція Anthropic, хоча й внутрішньо послідовна, не витримує реалій корпоративного світу. “Це перестає бути помилкою розробника і стає розподіленим режимом збою, коли один і той самий клас збою повторюється в такій великій кількості незалежних реалізацій”, — сказав він VentureBeat. “Рекомендації не є архітектурним контролем. Покладання на тисячі розробників нижчого рівня для послідовного тлумачення межі довіри є відомим антипатерном у корпоративній безпеці”.
Anthropic оновила свій файл SECURITY.md через дев’ять днів після першого контакту OX у січні 2026 року, вказавши, що адаптери STDIO слід використовувати з обережністю, але не внесла архітектурних змін. Оцінка дослідників цього оновлення: “Ця зміна нічого не виправила”.
Ріс зайняв більш зважену позицію. “Варто віддати належне Anthropic”, — сказав він VentureBeat. “Після розкриття інформації вони оновили свої рекомендації з безпеки, рекомендуючи обережність з адаптерами STDIO. Це значний крок, навіть якщо дослідники стверджують, що це не повноцінне виправлення на рівні протоколу”.
Що змінилося на рівні протоколу?
Нічого архітектурного. Anthropic не реалізувала виконання тільки за маніфестом, білий список команд в офіційних SDK або будь-які інші засоби пом’якшення на рівні протоколу. OX Security рекомендувала всі три. Оновлення рекомендацій у SECURITY.md було єдиною зміною. Дослідження OX почалося в листопаді 2025 року і включало понад 30 процесів відповідального розкриття інформації в екосистемі до публікації 15 квітня.
Розбіжність є суттєвою. Архітектурний аргумент Anthropic заслуговує на повну увагу. STDIO — це локальний транспорт для підпроцесів, розроблений для запуску процесів на машині, яка його налаштувала. Межа довіри, за моделлю Anthropic, знаходиться з тим, хто контролює конфігураційний файл. Якщо ви можете записувати в конфігурацію MCP, ви за визначенням є особою, уповноваженою виконувати команди на цій машині. За такою логікою, те, що виглядає як ін’єкція команд, є функцією, яка працює належним чином. Обмеження того, що STDIO може запускати на рівні протоколу, або порушить основну функцію транспорту, оскільки його мета — запускати довільні локальні процеси, або перемістить поверхню атаки в сам запущений процес. Аргумент “неупередженого стандарту” також є захищеним: універсальний протокол, який жорстко кодує обмеження виконання, перестає бути універсальним. Контраргумент OX з їхнього консультативного висновку: “Перенесення відповідальності на розробників не переносить ризик. Це лише затуманює, хто його створив”.
Не чекайте на виправлення на рівні протоколу. Розглядайте кожне налаштування MCP STDIO як поверхню для неперевіреного вводу, незалежно від того, в якому продукті воно знаходиться.
Послідовність дій для усунення проблеми в понеділок
Інвентаризація. Визначте кожне розгортання MCP-сервера в середовищах розробки, тестування та продакшену. Шукайте конфігураційні файли MCP (mcp.json, mcp_config.json) у домашніх каталогах розробників та шляхах конфігурації IDE (~/.cursor/, ~/.codeium/windsurf/, ~/.config/claude-code/). Перелічіть запущені процеси, які відповідають бінарним файлам MCP-серверів. Позначте будь-які, що використовують транспорт STDIO з доступом до публічного IP. OX виявила 7 000 на публічних IP. Ваше середовище може містити екземпляри, про які ви не знаєте.
Виправлення. Зафіксуйте кожен уражений продукт на його виправленій версії. LiteLLM v1.83.7-stable включає виправлення для CVE-2026-30623. DocsGPT, Flowise та Bisheng також випустили виправлення. Windsurf та Langchain-Chatchat залишаються в статусі “заявлено” станом на 1 травня 2026 року. Cursor був виправлений щодо попереднього пов’язаного розкриття (CVE-2025-54136), але успадковує ту саму стандартну конфігурацію протоколу. Перевіряйте поради кожного постачальника вранці, коли ви виконуєте цей крок.
Ізоляція (Sandbox). Ізолюйте кожну службу з підтримкою MCP від операційної системи хоста. Ніколи не надавайте серверу повний доступ до диска або привілеї виконання команд оболонки. Обхід білого списку в Flowise/Upsonic доводить, що самого обмеження команд недостатньо.
Аудит реєстрів. Перегляньте кожен MCP-сервер, встановлений з реєстру стороннього розробника. Дев’ять з 11 реєстрів прийняли доказ концепції OX без перевірки безпеки. Використовуйте реєстри з документованими процесами перевірки надходження. Видаліть будь-який MCP-сервер, походження якого ви не можете підтвердити.
Ставтеся до конфігурації STDIO як до неперевіреної. Цей крок залишається чинним для всіх майбутніх виправлень та продуктів. Стандартний режим протоколу не змінився. Кожне визначення STDIO-сервера є поверхнею для виконання команд. Ставтеся до нього так само, як до вводу користувача в запиті до бази даних: припускайте, що він ворожий, доки не буде перевірено.
Ваша вразливість не може чекати на виправлення протоколу
Anthropic та OX Security не згодні щодо того, хто несе відповідальність за безпеку транспорту STDIO в MCP. Ця незгода не буде вирішена цього тижня. Те, що можна вирішити цього тижня, — це інвентаризація ваших розгортань MCP, їх виправлення, ізоляція та ставлення до них як до неперевірених поверхонь виконання, якими вони є.
Як зазначив Ріс: “Ключове питання тут — архітектурна політика, а не експлойти”. Бер попереджала в січні, що небезпечні налаштування за замовчуванням призведуть саме до такого результату. OX задокументувала 200 000 серверів, що працюють з полем конфігурації, яке одночасно є поверхнею для виконання. Розробник протоколу стверджує, що він працює належним чином. Ваше питання в понеділок — не хто правий. А яке з ваших серверів є вразливим.
Як захиститися (Порада ІТ-Блогу): Завжди перевіряйте налаштування безпеки протоколів, що використовуються для взаємодії між компонентами вашої системи, особливо якщо вони передбачають виконання коду. Не покладайтеся на налаштування за замовчуванням, а ретельно вивчайте документацію щодо безпеки та застосовуйте найкращі практики ізоляції та автентифікації.
За матеріалами: venturebeat.com