Официальный MCP Python SDK: вредоносный сервер мог перехватить OAuth-учётные данные клиента

В официальном Python SDK для Model Context Protocol (MCP) — открытого стандарта подключения AI-приложений к внешним инструментам и данным — обнаружена уязвимость высокой степени серьёзности. Вредоносный MCP-сервер мог перенаправить OAuth-учётные данные клиентского приложения (секрет клиента, код авторизации и PKCE-верификатор) на подконтрольную атакующему конечную точку, после чего получить действующий токен доступа от легитимного сервера авторизации. Исправления выпущены в версиях 1.30.0 и 2.2.0, однако для двух из затронутых провайдеров одного обновления недостаточно — требуется дополнительная настройка параметра issuer=.

Суть уязвимости и механизм атаки

Согласно официальному бюллетеню безопасности (GHSA-qx49-fqc8-xw99), проблема заключается в недостаточной проверке подлинности данных (CWE-345) и недостаточной защите учётных данных (CWE-522). Когда MCP-клиент инициирует OAuth-аутентификацию, он запрашивает у MCP-сервера информацию о сервере авторизации. В уязвимых версиях SDK не проверял полученный ответ, что позволяло вредоносному серверу:

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

В результате клиент передавал атакующему client_secret, код авторизации и PKCE-верификатор code_verifier — одноразовое значение, предназначенное для защиты от повторного использования перехваченного кода авторизации. Передача верификатора полностью нейтрализует эту защиту. Секрет клиента является долгоживущим и остаётся действительным до принудительной ротации.

Для интерактивного провайдера OAuthClientProvider пользователь всё ещё должен подтвердить вход, но, как отмечает компания Cycode, обнаружившая уязвимость, страница подтверждения является подлинной страницей входа легитимного сервиса — визуально ничего подозрительного нет. Два провайдера для межмашинного взаимодействия (ClientCredentialsOAuthProvider и PrivateKeyJWTOAuthProvider) не требуют участия человека вовсе.

Затронутые версии и конфигурации

Уязвимый пакет — mcp (pip). Затронутые версии:

• 1.9.1 — 1.29.1: отсутствует проверка издателя и привязка учётных данных на всех путях;
• 2.0.0 — 2.1.1: проверки отсутствуют при использовании устаревшего резервного пути (когда сервер не публикует метаданные защищённого ресурса) или при ответе 403 insufficient_scope;
• Все альфа-версии от 2.0.0a1 до версий ниже 2.2.0.

Приложение уязвимо при одновременном выполнении двух условий: оно использует SDK как MCP-клиент по HTTP с одним из OAuth-обработчиков (OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider или устаревший RFC7523OAuthClientProvider) и может подключаться к MCP-серверу, который оператор не контролирует полностью, при этом располагая учётными данными для легитимного сервера авторизации.

Не затронуты: MCP-серверы, построенные на SDK; клиенты, использующие локальное подключение (stdio); клиенты, самостоятельно прикрепляющие токены или заголовки.

Оценка серьёзности

Бюллетень присваивает уязвимости оценку CVSS 7.5 (High) для провайдеров, работающих без участия человека. Для интерактивного OAuthClientProvider, где требуется подтверждение пользователя, оценка составляет 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N). На момент публикации бюллетеня идентификатор CVE не присвоен.

Ни бюллетень безопасности, ни отчёт Cycode не содержат сведений об активной эксплуатации уязвимости.

Оценка воздействия

Уязвимость представляет наибольший риск для организаций, развёртывающих AI-приложения на основе MCP, которые подключаются к сторонним MCP-серверам по HTTP и используют OAuth для аутентификации. Особенно критичен сценарий с межмашинными провайдерами: атака полностью автоматизирована и не требует социальной инженерии. Полученный атакующим токен доступа наследует все разрешения, предоставленные приложению, что может привести к полной компрометации учётной записи на стороне легитимного сервиса.

Рекомендации по устранению

Обновление пакета — необходимый, но не всегда достаточный шаг. Полный порядок действий:

1. Обновите пакет до версии 1.30.0 (ветка 1.x) или версии 2.2.0 (ветка 2.x). В исправленных версиях клиент определяет ожидаемый сервер авторизации до получения каких-либо метаданных и отклоняет несовпадающие.
2. Для ClientCredentialsOAuthProvider и PrivateKeyJWTOAuthProvider — обязательно передайте параметр issuer= с адресом легитимного сервера авторизации (например, issuer="https://auth.example.com"). Без этого параметра обновлённые провайдеры по-прежнему следуют за сервером авторизации, указанным MCP-сервером. В версии 1.30.0 предупреждение об отсутствии issuer= выводится как стандартное предупреждение об устаревании, которое Python скрывает по умолчанию — его легко пропустить.
3. Устаревший RFC7523OAuthClientProvider не поддерживает параметр issuer=. Необходимо перейти на один из двух других провайдеров.
4. Очистите сохранённые OAuth-регистрации однократно после обновления. Регистрации, созданные до исправления, не привязаны к конкретному серверу авторизации и остаются в таком состоянии.
5. Если клиент мог подключаться к недоверенному MCP-серверу — выполните ротацию секрета клиента и отзовите его токены на стороне сервера авторизации.

Для версий ниже исправленных единственная мера — подключение OAuth-клиентов исключительно к доверенным MCP-серверам.

Хронология раскрытия

Исправления с проверкой издателя вошли в релизы 1.30.0 и 2.2.0 от 7 сентября 2026 года и были описаны в примечаниях к выпуску как изменение поведения, а не как исправление безопасности. Бюллетень безопасности опубликован 28 сентября — в тот же день, когда Cycode выпустила свой разбор. В бюллетене указаны восемь человек, сообщивших о проблеме, включая исследователя Cycode.

Организациям, использующим MCP Python SDK для HTTP-клиентов с OAuth-аутентификацией, следует немедленно обновить пакет до версии 1.30.0 или 2.2.0, убедиться в наличии параметра issuer= для межмашинных провайдеров, очистить старые регистрации и при подозрении на компрометацию — выполнить ротацию секретов. Промежуток в три недели между выходом патча и публикацией бюллетеня означает, что часть пользователей могла обновиться, не осознавая критичность изменения.