Skip to content
RiverCore
Уразливість MCP вразила 7 000 серверів і 150 млн завантажень у ланцюжку постачання ШІ
MCP security flawAI supply chainCVE vulnerabilitiesMCP STDIO transport vulnerability AI SDKsAnthropic MCP unpatched CVEs 2026

Уразливість MCP вразила 7 000 серверів і 150 млн завантажень у ланцюжку постачання ШІ

22 кві 20266 хв. читанняSarah Chen

Одне архітектурне рішення в Model Context Protocol від Anthropic поширилося на понад 7 000 публічно доступних серверів і програмних пакетів, що сукупно налічують понад 150 мільйонів завантажень. Саме такий масштаб ураження OX Security пов'язує з єдиною «задуманою» слабкістю STDIO-транспорту MCP, і вона охоплює всі офіційно підтримувані мови SDK: Python, TypeScript, Java та Rust. З одинадцяти CVE, пов'язаних з цією першопричиною, виправлено три. Вісім — ні.

Цифри

Головна цифра — це співвідношення: 3 з 11 оприлюднених CVE наразі мають виправлення. LiteLLM (CVE-2026-30623), Bisheng (CVE-2026-33224) та DocsGPT (CVE-2026-26015) випустили патчі. Решта восьми, що стосуються GPT Researcher, Agent Zero, Fay Framework, Langchain-Chatchat, Jaaz, Upsonic, Windsurf і Flowise, залишаються відкритими на момент публікації звіту OX Security, як повідомляє The Hacker News. Це приблизно 27 відсотків усунених уразливостей серед проєктів, що разом забезпечують значну частину сучасного стеку агентного ШІ.

Цифра в 7 000 серверів потребує пояснення. Йдеться про публічно доступні екземпляри — тобто досяжні через інтернет кінцеві точки, де виконання команд через конфігурацію STDIO можна експлуатувати за правильного запиту. 150 мільйонів завантажень — це сукупна кількість скачувань пакетів із уражених проєктів, серед яких LiteLLM, LangChain, LangFlow, Flowise, LettaAI та LangBot. Завантаження є запізнілим індикатором розгортання, а не показником живої бази інсталяцій, але вони задають верхню межу потенційного ураження і нижню межу обсягу аудиторської роботи, яку команди нижче за ланцюжком зобов'язані провести.

Для порівняння — попередні RCE в окремих проєктах сфери ШІ-інструментів: 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 — усі вони, згідно з аналізом OX Security, сходяться до одного й того самого шаблону некоректного використання STDIO. Це щонайменше п'ять незалежних звітів за минулий рік про варіації однієї поведінки протоколу — ще до поточної партії з десяти. Сигнал від повторного, нескоординованого перевідкриття свідчить: дослідники раз у раз натикалися на одну й ту саму стіну, а стіна не рухалася.

Джерело не розкриває, скільки з 7 000 публічних серверів активно задіяні у виробничих агентних навантаженнях, а скільки є dev- чи demo-розгортаннями — а це важливо, оскільки реальна поверхня для експлуатації знаходиться десь усередині цього діапазону. Межа зрозуміла: максимум 7 000, мінімум — підмножина, вже ідентифікована публічними сканерами. Якщо відстеження активної експлуатації піде за схемою нещодавніх подій у ланцюжку постачання, можна очікувати, що каталог CISA KEV включить принаймні одну з цих CVE протягом 90 днів.

Що справді нового

Новиною тут є не RCE через ін'єкцію конфігурації. Ін'єкція команд через ненадійний конфігураційний ввід — це старий, добре задокументований клас уразливостей, і OWASP Top Ten охоплює категорії ін'єкцій уже понад десятиліття. Новим є механізм доставки: SDK, випущений автором протоколу, ідентичний для чотирьох мовних середовищ виконання, який перетворює поля конфігурації на виконання команд рівня ОС через STDIO-транспорт, коли запитується локальний STDIO-сервер.

Формулювання OX Security точне: «Model Context Protocol від Anthropic надає пряме виконання команд через конфігурацію via їхній STDIO-інтерфейс в усіх реалізаціях, незалежно від мови програмування». Механізм такий: STDIO-завантажувач був розроблений для запуску локального сервера і передачі дескриптора назад до LLM. Якщо передати йому команду, що не запускає сервер, він все одно виконає команду, а потім поверне помилку. Помилка — косметична. Виконання вже відбулося.

Чотири категорії атак конкретизують це: неавтентифікована та автентифікована ін'єкція команд через MCP STDIO; неавтентифікована ін'єкція через пряму конфігурацію STDIO з обходом захисту; неавтентифікована ін'єкція через редагування конфігурації MCP, кероване zero-click prompt injection; та неавтентифікована ін'єкція через MCP-маркетплейси, де мережеві запити запускають приховані STDIO-конфігурації. Третя категорія — та, що має насторожити керівників платформ. Zero-click prompt injection у редагування конфігурації означає, що зловмиснику не потрібно компрометувати машину розробника — достатньо підкинути контент, який агент прочитає під час звичайної роботи.

Другий по-справжньому новий елемент — реакція Anthropic. Згідно зі звітом OX Security, Anthropic відмовилася змінювати архітектуру протоколу і назвала цю поведінку «очікуваною». Це позиція щодо політики, а не недогляд. Вона переміщує межу безпеки від автора протоколу до кожного розробника-імплементатора на Python, TypeScript, Java та Rust. Відповідь дослідників варта цитування: «Перекладання відповідальності на імплементаторів не передає ризик. Воно лише приховує, хто його створив».

Що вже враховано командами безпеки

Більшість платформних команд, що використовують LangChain, LiteLLM або Flowise у виробництві, вже сприймають ці бібліотеки як такі, що швидко оновлюються і потребують частих патчів. Наявність RCE в проєкті, суміжному з LangChain, не є несподіванкою, а CVE-стрічки в цій екосистемі шумлять уже понад рік. Цю частину вже враховано.

Що не враховано: думка про те, що саме протокол, а не окрема бібліотека, є слабкою ланкою. Команди, що перевіряли графи залежностей на рівні пакетів і дійшли висновку «ми на виправлених версіях», можуть усе одно нести той самий кореневий дефект, бо шаблон закладено в референсному SDK від Anthropic. Це переформатовує роботу з усунення. Тепер це не «оновити LiteLLM», а «перевірити кожну MCP STDIO межу у вашому стеку, включно з власноруч написаними серверами на основі офіційного SDK».

Також недооцінений вектор маркетплейсу. MCP-маркетплейс, що роздає конфігурації через мережеві запити, де ці конфігурації можуть приховувати STDIO-команди, фактично є каналом розповсюдження програмного забезпечення без будь-яких вбудованих вимог до підписання. Якщо ви — CTO, що будує внутрішній MCP-маркетплейс для своєї інженерної організації, модель довіри там ближча до неперевіреного npm-дзеркала, ніж до курованого корпоративного реєстру. Відповідність технікам MITRE ATT&CK щодо компрометації ланцюжка постачання та виконання команд через інтерпретатори сценаріїв є прямою.

Найважливіше невідоме: скільки внутрішніх, непублічних MCP-серверів усередині підприємств мають той самий дефект. Джерело вимірює публічний інтернет. Приватні розгортання за VPN або сервісними мешами за визначенням виходять за межі цього підрахунку. Моя робоча оцінка: приватна поверхня ураження щонайменше така ж, як публічна цифра в 7 000, і цілком може бути в кілька разів більшою, адже основна цінність MCP — інтеграція внутрішніх інструментів.

Альтернативна точка зору

Консенсусна позиція полягає в тому, що Anthropic помиляється і це є помилка на рівні протоколу. Альтернативний аргумент: Anthropic може бути технічно правою в тому, що STDIO-транспорти за своєю природою виконують локальні процеси, і що розміщення межі довіри всередині транспорту, призначеного для запуску дочірніх процесів, є категоріальною помилкою. Якщо конфігурація MCP розглядається як довірений ввід (так само, як довіряють файлу systemd unit або Dockerfile), то «конфігурація призводить до виконання команд» — це функція, а не недолік.

Проблема з цим захистом — операційна, а не теоретична. На практиці конфігурація MCP передається через мережеві межі, редагується LLM, що реагують на запити користувачів, і розповсюджується через маркетплейси. Припущення про довіру, під яким проектувався протокол, не витримує патернів розгортання, які сам протокол активно заохочує. Anthropic може бути права в специфікації і все одно помилятися в реальному світі. Назвати поведінку «очікуваною» закриває розмову саме там, де вона має починатися.

Якщо Anthropic збереже цю позицію ще два квартали, я очікую, що принаймні один резонансний інцидент, пов'язаний з конфігурацією MCP-маркетплейсу, змусить змінити політику там, де хвиля CVE цього не зробила.

Ключові висновки

  • Одинадцять CVE пов'язані з одним архітектурним рішенням MCP STDIO; станом на аналіз OX Security виправлено лише три (LiteLLM, Bisheng, DocsGPT).
  • Ураження охоплює 7 000+ публічних серверів і 150 млн+ завантажень у реалізаціях SDK на Python, TypeScript, Java та Rust.
  • Anthropic відмовилася від архітектурних змін і назвала поведінку «очікуваною», перекладаючи відповідальність за виправлення на кожного розробника-імплементатора.
  • Чотири категорії атак включають zero-click prompt injection у конфігурації MCP та приховані STDIO-команди, що роздаються через маркетплейси, — це розширює модель загроз за межі традиційного патчингу залежностей.
  • Прогнозована перевірка: якщо принаймні одна з восьми невиправлених CVE потрапить до CISA KEV протягом 90 днів після 20 квітня 2026 року, позиція Anthropic щодо «очікуваної поведінки» зміниться до Q3 2026.

Часті запитання

З: Що таке уразливість MCP STDIO в SDK від Anthropic?

Це «задумана» слабкість, за якої STDIO-транспорт MCP перетворює конфігураційний ввід на виконання локальних команд незалежно від того, чи команда насправді запускає STDIO-сервер. OX Security повідомляє, що вона впливає на офіційний SDK Anthropic у Python, TypeScript, Java та Rust, уможливлюючи віддалене виконання коду на будь-якій системі з вразливою реалізацією.

З: Які проєкти уражені і які виправлено?

Оприлюднені CVE охоплюють GPT Researcher, LiteLLM, Agent Zero, Fay Framework, Bisheng, Langchain-Chatchat, Jaaz, Upsonic, Windsurf, DocsGPT та Flowise. На момент аналізу OX Security патчі опублікували лише LiteLLM (CVE-2026-30623), Bisheng (CVE-2026-33224) та DocsGPT (CVE-2026-26015).

З: Що інженерним командам слід зробити негайно?

Перевірте кожну MCP STDIO межу у вашому стеку, включно з внутрішніми серверами на основі офіційного SDK; вважайте конфігураційний ввід MCP з будь-якого мережевого джерела ненадійним; помістіть MCP-сервіси у пісочницю; заблокуйте доступ публічних IP-адрес до чутливих серверів інструментів і встановлюйте MCP-сервери лише з перевірених джерел. Патчинг на рівні залежностей необхідний, але недостатній, оскільки кореневий дефект закладено в референсній реалізації протоколу.

SC
Sarah Chen
RiverCore Analyst · Dublin, Ireland
ПОДІЛИТИСЯ
// RELATED ARTICLES
ГоловнаРішенняПроєктиПро насКонтакт
Новини06
Дублін, Ірландія · ЄСGMT+1
LinkedIn
🇺🇦UK