Уязвимость MCP SDK в официальном Python-пакете позволяла вредоносному MCP-серверу перехватить OAuth-данные клиента: client secret, authorization code и PKCE proof key. Для разработчиков AI-инструментов это неприятный сценарий: приложение думает, что входит в настоящий сервис, а ключи уезжают на token endpoint атакующего.
Проблему описали сопровождающие SDK в security advisory, сообщает The Hacker News. Исправления вышли в версиях 1.30.0 для ветки 1.x и 2.2.0 для ветки 2.x. Уязвимость получила высокую оценку риска: 7,5 для двух machine-to-machine OAuth-провайдеров и 6,5 для интерактивного сценария, где пользователь вручную подтверждает вход. CVE на 29 сентября 2026 года назначен не был.
Model Context Protocol, или MCP, быстро стал стандартным способом подключать AI-приложения к внешним инструментам и данным. Python SDK используется для создания MCP-серверов и клиентов, поэтому проблема затрагивает не игрушечный слой вокруг чат-ботов, а инфраструктуру, через которую AI-агенты ходят в репозитории, таск-трекеры, внутренние API и корпоративные сервисы.
Суть бага в проверке authorization server. Когда MCP-клиенту нужно авторизоваться, он спрашивает у сервера, где находится сервис входа. В уязвимых версиях SDK этот ответ проверялся недостаточно строго. Вредоносный MCP-сервер мог указать собственный OAuth-сервер или подмешать метаданные так, чтобы пользователь видел настоящий login page, но sensitive-данные для обмена токена уходили не туда.
Особенно неприятна деталь с PKCE. Этот механизм нужен, чтобы украденный authorization code нельзя было просто переиспользовать. Но если клиент сам отправляет атакующему и код, и proof key, защита превращается в красивую наклейку на пустой двери. Исследователи Cycode, которые сообщили о проблеме, показали тестовый сценарий полного обмена: с украденными данными атакующий получает валидный access token реального сервиса с теми правами, которые были выданы приложению.
Под удар попадают приложения, которые используют SDK как MCP-клиент поверх HTTP и один из OAuth-провайдеров: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider или устаревший RFC7523OAuthClientProvider из ветки 1.x. Важное условие: клиент должен подключаться к MCP-серверу, которому нельзя полностью доверять, и при этом иметь учетные данные для настоящего authorization server. MCP-серверы, собранные на SDK, локальные stdio-клиенты и клиенты, которые прикрепляют собственные токены, не затронуты.
Диапазоны версий выглядят так: в ветке 1.x уязвимы релизы с 1.9.1 по 1.29.1, исправление находится в 1.30.0. В ветке 2.x уязвимы версии с 2.0.0 по 2.1.1, исправление - в 2.2.0. В новых релизах клиент заранее определяет ожидаемый authorization server и отклоняет данные, если они указывают на другой сервис входа.
Обновление, правда, не закрывает все автоматически. Для ClientCredentialsOAuthProvider и PrivateKeyJWTOAuthProvider нужно явно передать параметр issuer= с адресом сервиса входа, которому принадлежат учетные данные. Без этого клиенты по-прежнему могут следовать за тем, что им сообщает MCP-сервер. Неприятный нюанс: в версии 1.30.0 предупреждение об этом оформлено как обычный deprecation warning, а Python по умолчанию такие сообщения часто прячет. То есть исправление можно установить и все равно пропустить главный флажок.
Устаревший RFC7523OAuthClientProvider лучше убрать: у него нет опции issuer=. После обновления сопровождающие рекомендуют один раз очистить сохраненные OAuth client registrations, потому что старые регистрации не привязаны к конкретному login service. Если клиент уже мог подключаться к недоверенному MCP-серверу, придется сделать скучную, но нужную работу: ротировать client secret и отозвать токены на стороне сервиса авторизации.
История хорошо показывает, почему безопасность AI-агентов все чаще упирается не в промпты, а в обычную инженерную дисциплину вокруг identity. Уязвимость MCP SDK не требовала магии: достаточно было убедить клиента поверить неправильному серверу. Чем больше компаний подключают AI-клиентов к рабочим системам, тем дороже становится такой класс ошибок - особенно там, где machine-to-machine-доступ живет без человека в цикле.
