AWS закрыла SSRF в mcp-gateway-registry: шлюз мог обращаться к внутренней сети и облачным метаданным

AWS исправила уязвимость CVE-2026-125926 в mcp-gateway-registry - открытом реестре и шлюзе для серверов Model Context Protocol. Пользователь с учётной записью и правом регистрировать или изменять серверы может направить запросы шлюза к внутренним сервисам, включая сервис метаданных облака. Так через шлюз видны внутренние API и данные, закрытые от внешних пользователей. Затронуты версии от 1.0.3 до 1.34.0 включительно, исправление вышло в 1.35.0. Оценка CVSS 3.1 - 8.5, уровень высокий.

Где ошибка и что она даёт

mcp-gateway-registry - открытый реестр и шлюз для серверов Model Context Protocol. Проект собирает каталог MCP-серверов и инструментов, управляет доступом к ним и проксирует вызовы: клиент обращается к шлюзу, а тот перенаправляет запрос зарегистрированному серверу. Поэтому через шлюз идёт трафик от агентов к инструментам, и он видит больше, чем отдельный клиент.

Model Context Protocol - протокол, по которому LLM-клиенты вызывают внешние инструменты и получают данные из подключённых сервисов. Реестр хранит описания серверов, включая адрес, по которому к ним надо обращаться. Этот адрес называют upstream-адресом: это вышестоящий сервис, куда шлюз отправляет запрос.

Ошибка в том, что в версиях до 1.34.0 включительно реестр не проверял этот адрес при регистрации и изменении сервера. Пользователь с соответствующими правами мог указать адрес внутреннего сервиса, недоступного ему напрямую. Запрос после этого отправлял уже шлюз - со своей сетевой позиции. В части случаев он возвращал ответ пользователю.

Так работает SSRF, server-side request forgery: сервер по указанию пользователя сам обращается к произвольному адресу. Отличие от обычного прокси в том, что запрос идёт не с адреса пользователя, а из сети шлюза, где доступно больше целей.

Последствия зависят от сети, в которой развёрнут реестр. Рядом со шлюзом обычно стоят внутренние сервисы, закрытые от внешних пользователей: административные панели, внутренние API, служебные эндпоинты. В облачной установке к ним добавляется сервис метаданных экземпляра - внутренний HTTP-сервис, который выдаёт конфигурацию и временные учётные данные привязанной роли. Если реестр запущен с облачной ролью и метаданные доступны, чтение ответов может привести к утечке учётных данных.

Оценки в записи CVE две: CVSS 3.1 - 8.5, высокий уровень, и CVSS 4.0 - 6.3, средний. Класс ошибки - CWE-918, server-side request forgery. Старшая оценка учитывает сетевой вектор, низкие требуемые привилегии, отсутствие участия пользователя и высокое влияние на конфиденциальность.

Условия эксплуатации

Атака идёт по сети и не требует локального доступа. Нужны действующая учётная запись и права на регистрацию или изменение сервера. Без учётной записи ошибка не срабатывает, но и высоких привилегий не нужно: достаточно роли, которая управляет серверами в реестре. Участие пользователя не требуется: достаточно запроса к API.

Второе условие - сеть. Запрос уходит с адреса шлюза, поэтому цель должна быть достижима из его окружения. Если исходящий трафик реестра ограничен, часть внутренних целей закрыта, но не все: шлюз по своей роли ходит к зарегистрированным серверам и служебным компонентам.

Третье условие - возврат ответа. Когда реестр отдаёт содержимое ответа пользователю, данные читаются напрямую. Когда ответ не возвращается, остаётся слепой вариант: по кодам состояния и задержкам видно, что внутренний сервис существует и отвечает. Практическая ценность такого варианта ниже, но он помогает готовить следующую атаку.

Затронутые версии

Уязвимы версии mcp-gateway-registry от 1.0.3 до 1.34.0 включительно. Проблема исправлена в 1.35.0. Проект открытый, поэтому сборки с изменениями и форки нужно проверять отдельно: патч из основной ветки туда сам не попадёт.

Номер версии стоит учитывать отдельно. В 1.25.0 исправили другую, несвязанную ошибку в API управления. Установка на 1.25.0 или новее содержит то исправление, но от CVE-2026-125926 остаётся уязвимой до 1.35.0.

Что исправляет патч

В версии 1.35.0 реестр проверяет upstream-адрес при регистрации и изменении сервера. Это закрывает путь для новых записей. Сохранённые ранее конфигурации проверка не пересматривает: релиз прямо оставляет их без изменений. Поэтому после обновления старые регистрации надо пересмотреть вручную.

AWS отдельно благодарит внешнего исследователя novice-22 за участие в согласованном раскрытии ошибки.

Если обновиться нельзя

Пока патч не установлен, основной ограничитель - права. Регистрировать и изменять серверы должны только доверенные учётные записи. Это сужает круг тех, кто может воспользоваться ошибкой.

Второй ограничитель - сеть. Исходящий трафик от компонентов реестра и сервера аутентификации стоит ограничить адресами, которые им действительно нужны. Помогают сетевые политики, группы безопасности и прокси с белым списком. На Amazon EC2 следует требовать IMDSv2 и выдавать роли каждого компонента только необходимые права. Эти меры снижают риск, но не заменяют обновление и проверку из следующего раздела.

Что проверить после обновления

Сначала адреса зарегистрированных серверов. Просмотрите список и исправьте или удалите всё, что появилось без понятной причины. Патч не трогает старые записи, поэтому эта проверка обязательна, а не опциональна.

Затем журналы приложения за период, когда работала уязвимая версия. Ищите неожиданные регистрации и изменения серверов. По ним видно, пробовал ли кто-то направить upstream-адрес на внутренний сервис.

Третье - облачная роль. Если реестр работает с привязанной ролью и журналы не позволяют исключить подозрительную активность, проверьте действия роли и смените её учётные данные. Заодно пересмотрите список учётных записей с правом регистрации и изменения серверов.

Порядок действий: найти установки на версиях от 1.0.3 до 1.34.0, обновиться до 1.35.0, затем проверить старые регистрации и журналы. Если обновление откладывается, сначала сузить права и исходящий сетевой доступ.