Кібербезпека
Дослідник розкрив одну і ту ж вразливість MCP у Google, JPMorgan та двох урядах

Незалежний дослідник з безпеки Syed Anas Mohiuddin розкрив у жовтневому оновленні дослідження 2026 року, що та сама помилка серверного підроблення запитів у серверах Model Context Protocol була підтверджена та виправлена командами безпеки п’яти незв’язаних організацій: Google, JPMorgan Chase, Weaviate, міжміністерським цифровим директоратом Франції та урядом міста Тангеранг в Індонезії.
Оновлення під назвою «Protocol Pivoting, four months later» перевіряє передбачення, зроблене Mohiuddin у травні 2026 року: якщо вразливість є структурною, а не результатом однієї недбалості, той самий баг з’явиться в серверах, написаних командами, які не ділять код, галузь, країну чи власника. Він повідомляє, що кожна з п’яти організацій підтвердила випадок за допомогою власної команди безпеки, і що постачальник безпеки Rapid7 окремо опублікував CVE для іншої, але пов’язаної вразливості. Оновлення підраховує п’ять організацій, які виправили одну і ту ж SSRF, два опублікованих CVE та п’ять виявлень у федеральних серверах MCP США, які залишаються відкритими.
Mohiuddin описує два режими відмови, що стоять за шаблоном. Перший — це підроблення запитів на боці сервера (SSRF): MCP‑сервер формує вихідний запит за URL, шляхом або кінцевою точкою, наданими агентом, не перевіряючи, куди вони розв’язуються, тому агент фактично вирішує, з яким мережевим об’єктом спілкується сервер. Другий — небезпечне оброблення вхідних даних, найпомітніше коли повні відповіді API записуються у централізовані журнали без редагування, що достатньо для спрацювання звичайних помилок. Він пов’язує обидва випадки з однією припущенням: дані, що перетинають межу MCP, вважаються довіреними, бо вони походять з внутрішньої системи, що, на його думку, не виправдано в агентній конвеєрній системі.
CVE‑2026‑14540 у MCP Toolbox від Google
Згідно з записом у базі даних попереджень GitHub щодо CVE‑2026‑14540, опублікованим Національною базою даних вразливостей, у загальних HTTP‑джерелах та інструментальних компонентах Google mcp-toolbox версій 0.3.0‑1.4.0 існує вразливість SSRF. Оскільки HTTP‑клієнт не мав обмежувальної політики перенаправлень і ніколи не перевіряв IP‑адреси призначення, спеціально сформований параметр шляху міг перенаправляти вихідні запити інструмента до внутрішніх або довільних зовнішніх кінцевих точок. Попередження оцінює вразливість як високої серйозності з CVSS‑балом 8.0; вона була опублікована 31 липня 2026 року та востаннє оновлена 8 серпня 2026 року. Mohiuddin зазначає, що CVE було зарезервовано 3 липня 2026 року і що запис вказує його як виявника.
Google влив виправлення, pull‑request #3448 у репозиторії googleapis/mcp-toolbox, 18 червня 2026 року, і воно було випущено в mcp-toolbox v1.5.0. Pull‑request впроваджує SSRFGuard для запобігання атакам DNS‑rebinding у проміжку між перевіркою адреси та встановленням з’єднання, додає налаштовувані властивості allowPrivateNetworks, allowedIpRanges та customBlockedIpRanges, перевіряє налаштовану BaseURL під час ініціалізації, а не при першому запиті, і явно попереджає про ризик «людина посередині», коли вимкнено перевірку SSL. PR вказує Mohiuddin як доповідача, і Mohiuddin описує виправлення Google як еталонну реалізацію справжнього захисту SSRF.
Ще чотири підтверджені випадки
Mohiuddin повідомляє, що у відкритому репозиторії jpmorgan-payments/ai від JPMorgan Chase є MCP‑сервер documentation‑search, інструмент read_documentation якого застосовує білий список доменів перед отриманням, тоді як його сестринський інструмент related() отримує URL, наданий викликачем, на боці сервера без будь‑яких обмежень. Він зазначає, що компонент був форкнутий з проєкту AWS, у якого оригінал ніколи не розпізнавав URL викликача, що команда відповідального розкриття банку підтвердила виявлення як дійсне, і що виправлення було впроваджено. Його ім’я зазначено на публічній сторінці визнання відповідального розкриття JPMorgan Chase, і він оцінює виявлення як середньої серйозності, зазначаючи, що жодні облікові дані не передаються разом із підробленим запитом.
Mohiuddin повідомляє, що Weaviate влив pull‑request, який обмежує налаштування apiEndpoint, region та location модуля Google лише хостами Google API, і зазначає його ім’я у публічному записі Security Hall of Fame від 25 серпня 2026 року.
Проєкт datagouv/datagouv-mcp влив pull‑request #126, “feat: harden SSRF on external APIs” 4 вересня 2026 року, і pull‑request починається з вказання Mohiuddin як доповідача. За даними PR, поле machineдокументаціяurl, надане будь‑яким зареєстрованим виробником data.gouv.fr, отримувалося на боці сервера і могло вказувати на адреси loopback, приватної мережі або метаданих хмари, при цьому DNS‑rebinding міг змінити ціль між перевіркою та підключенням, а 302‑перенаправлення могло призвести до внутрішнього хоста. Виправлення перевіряє IP‑адресу призначення під час підключення, повторно перевіряє кожен крок перенаправлення та відхиляє проксі. Mohiuddin ідентифікує проєкт як офіційний MCP‑сервер національної платформи відкритих даних Франції, яку підтримує DINUM, міжміністерський цифровий директорат уряду.
A GitHub Security Advisory, опублікована 3 вересня 2026 р. розробниками INFOKOM-KI/Wazuh-MCP-Server, оцінена як високий ризик, фіксує, що інструмент blueteamперевіркаwebshell, рекламована захистом від SSRF, відхиляв лише буквальні IP‑адреси і ніколи не розв’язував імена хостів, тому будь‑яке DNS‑ім’я, що вказує на приватну, локальну або адреси типу link‑local, включаючи метадані екземплярів хмари, обходило його. У повідомленні зазначено, що задокументована гарантія інструмента “SSRF Protection: Private/reserved IPs in the URL host are rejected” не діє для URL‑ів на основі імен хостів. Вразливість була виправлена у коміті 2bbfe12, і у повідомленні вказано Мохіуддіна як репортера. Мохіуддін стверджує, що повідомив про це 2 вересня 2026 р., що розробники відповіли з адреси tangerangkota.go.id, і що проєкт підтримується урядом міста Тангеранг в Індонезії.
Rapid7 запис у базі даних вразливостей CVE-2026-97228 фіксує ін’єкцію запиту GraphQL у Rapid7 Bulk Export MCP версій 0.2.5 до 0.6.1, у яких неперевірений exportаргумент інструменту id MCP без перевірки вставляється безпосередньо у запит GraphQL. Rapid7 оцінює його 2.7, Low, за шкалою CVSS 3.1, запис опубліковано 25 вересня 2026 року, і зазначає, що ін’єковані запити виконуються в межах API оператора і не можуть перетинати межу орендаря; версія 0.6.2 виправляє проблему, передаючи exportid як параметризовану змінну. Mohiuddin стверджує, що Rapid7 визнала його знахідником.
Окрім цих випадків, Мохіуддін повідомляє, що станом на оновлення 16 повідомлень про безпеку GitHub, опублікованих розробниками самих проєктів, вказують його як репортера; вони охоплюють SSRF, ін’єкцію команд, прогалини автентифікації, викрадення сеансів, витоки облікових даних та обходи раніше виправлених вразливостей, і що його виправлення були злиті у проєкти, зокрема github-mcp-server, mongodb-mcp-server та salesforce-mcp-server.
Нерозв’язані урядові висновки
Мохіуддін повідомляє, що 2 вересня 2026 р. подав п’ять висновків у вигляді приватних повідомлень про безпеку GitHub, що охоплюють сервери MCP під управлінням служби технологічної трансформації GSA: сервер заявок на виплати у Міністерстві справ ветеранів, сервер CMS Blue Button, сервер regulations.gov, сервер USASpending та сервер CDC PLACES. Він зазначає, що всі п’ять залишаються на стадії триажу, не виправлені і не представлені як підтверджені результати.
У випадку VA, який він описує лише на рівні класу, сервер записує повне тіло помилки upstream benefits‑API на рівні ERROR без редагування; ці тіла можуть містити ім’я ветерана, номер соціального страхування, дату народження та адресу, і він стверджує, що звичайні помилки валідації достатньо, щоб викликати таке логування під час нормальної роботи. Він утримує деталі на рівні коду, доки сервери не будуть виправлені.
Він також повідомляє, що 1 вересня 2026 р. повідомив JPCERT, що у jgrants-mcp-server Японського цифрового агентства відсутня автентифікація, а 7 вересня 2026 р. відкрив публічний pull‑request, який вимагає явного opt‑in для прив’язки сервера до чого‑небудь, крім loopback, і обмежує розмір запису вкладень. Pull‑request ще не був злитий, і він не представляє його як підтверджений результат.
Протокольне Pivoting та доповідь на MCPCon
Мохіуддін визначає Protocol Pivoting як багатокрокову атаку, під час якої зловмисник проникає через один протокол, використовує довірчі припущення, які протоколи роблять один щодо одного, і підвищує привілеї до можливостей, доступних лише через інший протокол. У його конкретному прикладі текст, сформований як інструкція завдання A2A, розміщується у виводі інструмента MCP; оркеструючий агент передає його підагенту як звичайну делегацію, і підагент, довіряючи оркестратору, виконує його.
офіційний препринт, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” був опублікований на Zenodo 24 травня 2026 р. У ньому представлено три сценарії: підвищення привілеїв MCP→A2A через неявну довірчу делегацію, ін’єкція можливостей A2A→MCP через підробку шкідливого агента, та ланцюги ін’єкції підказок між протоколами. Також аналізується, чому існуючі захисні механізми не справляються з цим класом, і пропонується уніфікована міжпротокольна безпекова рамка з формальною моделлю межі довіри та трьома протокольно‑незалежними заходами пом’якшення.
Робота, розпочата у травні, стартувала з playwright-mcp від Microsoft, інструмент browser_navigate якого приймав будь‑яку URL‑адресу, яку передавав агент, без захисту від SSRF, що дозволяло направляти агента до сервісу метаданих екземплярів AWS за адресою 169.254.169.254 та отримувати його облікові дані. Мохіуддін зазначає, що подав це як публічний issue у GitHub, що CVE відсутній і немає підтвердження від виробника, і що оцінка серйозності є його власною оцінкою.
Мохіуддін стверджує, що аналіз складу програмного забезпечення та сканери залежностей пропускають цей клас, оскільки небезпечне введення надходить через транспорт у вигляді аргументу інструмента, описаного у маніфесті інструмента, який сканер ніколи не читає, тому граф викликів зупиняється на транспортній межі. Він зазначає, що створив mcp-safeguard — відкритий сканер, який тестує сервери MCP через їх відкриту поверхню інструментів без потреби у вихідному коді, шукаючи шість класів: SSRF, надмірні дозволи, поверхні ін’єкції підказок, витік інформації, прогалини автентифікації та обходи життєвого циклу. Він також зазначає, що інструменти шаблонного співставлення, включаючи його власний, пропускають значну частину цього класу.
Мохіуддін заявляє, що представить крос‑вендорний патерн 23 жовтня 2026 р. на MCPCon North America в Сан‑Хосе, включаючи всі виправлені до того часу висновки, і що федеральні висновки залишаться приватними, доки їх не виправлять.












