FlawOpen

flawopen.com/Teardowns/cve-2026-27826-mcp-atlassian-ssrf

● CVE-2026-27826 · CVSS 8.2[1], [3] · Высокий
Исследования · FlawOpen

CVE-2026-27826: SSRF в MCP Atlassian

Исходная SSRF-уязвимость CVE-2026-27826 через HTTP-заголовки исправлена в версии 0.17.0. Отдельные последующие SSRF-уязвимости исправлены в 0.22.0; изучите каждое предупреждение перед выбором минимальной версии для всего парка.[1], [2], [6], [8], [9], [10], [11]

💡 Простыми словами (ELI5)

Представьте почтовую службу, которой разрешено доставлять посылки только в утверждённые офисы компании. Посетитель указывает другой адрес в специальной форме, а сотрудники принимают его без проверки. Серверный fetcher работает как такая служба: заголовки запроса задавали адрес, и сервер отправлял туда запрос. Исправление в версии 0.17.0 проверяет переданное URL до подключения и также проверяет перенаправления; оператор может дополнительно задать список разрешённых доменов.[1], [2]

Ключевые понятия и термины

Server-side request forgery (SSRF)
Уязвимость, позволяющая повлиять на исходящий запрос сервера так, чтобы он достиг адреса, к которому приложение не собиралось обращаться.[1], [4]
Транспорт MCP
Канал связи между клиентом и сервером MCP. Эта проблема затрагивала streamable-HTTP и SSE, но не описанное в уведомлении развёртывание только через stdio.[1]
Мультитенантная аутентификация по заголовкам
Режим, принимающий URL и токены Atlassian в каждом запросе для создания API-клиента конкретного арендатора.[1], [2]
Политика исходящего трафика
Сетевые ограничения, определяющие адреса, к которым служба может подключаться, и уменьшающие последствия ошибок проверки URL в приложении.[12], [1]
Косвенная prompt injection
Недоверенный контент, возвращённый инструментом, может содержать инструкции, влияющие на модель. Для этого CVE в уведомлении описаны ответы под контролем атакующего, попадающие в результаты инструментов; это отдельный путь воздействия, а не сама SSRF.[1], [7]
Последующие исправления SSRF
В исходном предупреждении CVE-2026-27826 исправленной указана версия 0.17.0. Позднее сопровождающий проект описал четыре отдельных неполных пути исправления как CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 и CVE-2026-77274; в каждом предупреждении исправленной указана версия 0.22.0. Это отдельные CVE, а не расширение диапазона CVE-2026-27826. Перед выбором минимальной версии для всего парка проверьте и более поздние предупреждения.[8], [9], [10], [11]

Связи со стандартами

Анализ первопричины

В затронутом HTTP-пути сервер извлекал из запроса X-Atlassian-Jira-Url или X-Atlassian-Confluence-Url и передавал значение в JiraConfig или ConfluenceConfig для создания fetcher. В уязвимой ветке аутентификации по заголовкам адрес до первого запроса fetcher не сверялся с настроенным на сервере URL арендатора и не проверялся политикой разрешённых направлений. Уведомление сопровождающего указывает на middleware запросов и поставщик зависимостей, а не на отдельный обработчик инструмента MCP. Требуются затронутый HTTP-транспорт и условия ветки аутентификации по заголовкам; не следует распространять вывод на все развёртывания MCP.[1], [2]

Пошаговый сценарий атаки

Шаг 1

Доступный HTTP-транспорт

Развёртывание использует streamable-HTTP или SSE и открывает конечную точку MCP для клиента, который может до неё достучаться.[1], [2]

Шаг 2

Заголовки задают URL сервиса

В затронутой ветке аутентификации по заголовкам присутствуют URL и токен Jira или Confluence, а ожидаемого альтернативной веткой заголовка Authorization нет.[1], [2]

Шаг 3

Middleware создаёт fetcher

Middleware сохраняет полученный URL, а поставщик зависимостей использует его при настройке fetcher Atlassian, не обеспечивая ожидаемую границу назначения.[1], [2]

Шаг 4

Сервер отправляет исходящий запрос

При инициализации fetcher обращается к адресу, выбранному вызывающей стороной. В зависимости от сети и ответа это может открыть внутренние службы или добавить управляемый третьей стороной текст в результаты инструмента.[1], [2]

Исходный код: Уязвимый vs Защищённый вариант

Уязвимый фрагмент позволяет URL из заголовка запроса выбирать адрес исходящего подключения сервера. Upstream-патч 0.17.0 не заменяет режим арендатора с URL из заголовка серверным реестром арендаторов: он проверяет переданный URL Jira или Confluence в ASGI middleware до создания fetcher, а затем добавляет response hook для проверки адресов перенаправления. Защищённый фрагмент показывает эти два upstream-контроля; реализация валидатора опущена. Серверный реестр арендаторов — более надёжная альтернативная архитектура, но этот патч её не реализует. В более поздних уведомлениях для 0.22.0 описаны отдельные остаточные пути, поэтому не считайте 0.17.0 минимальной версией для всего парка без их проверки. Проверка DNS также должна выполняться при соединении для защиты от rebinding; однократного разрешения имени недостаточно для полной защиты от SSRF.[1], [2]

Фрагмент исходного кода: Фрагмент upstream-патча для middleware и fetcher (путь Jira; для Confluence добавлена аналогичная проверка).

УЯЗВИМАЯ РЕАЛИЗАЦИЯ
header_jira_fetcher = JiraFetcher(config=header_config)
current_user_id = header_jira_fetcher.get_current_user_account_id()
БЕЗОПАСНЫЙ ИСПРАВЛЕННЫЙ ВАРИАНТ
ssrf_error = validate_url_for_ssrf(jira_url_str)
if ssrf_error:
    scope["state"]["auth_validation_error"] = (
        f"Forbidden: Invalid Jira URL - {ssrf_error}"
    )
    return

header_jira_fetcher = JiraFetcher(config=header_config)
header_jira_fetcher.jira._session.hooks["response"].append(
    _make_ssrf_safe_hook(validate_url_for_ssrf)
)
current_user_id = header_jira_fetcher.get_current_user_account_id()

Чек-лист по защите системы для инженеров

Источники