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

Коротко о главном

В официальном MCP Python SDK (пакет mcp) закрыта уязвимость GHSA-qx49-fqc8-xw99 с оценкой CVSS 7.5: вредоносный MCP-сервер мог подсунуть клиенту чужой сервер авторизации и получить его OAuth client secret, код авторизации и PKCE-ключ. Уязвимы версии 1.9.1–1.29.1 и 2.0.0–2.1.1, исправление — в 1.30.0 и 2.2.0. Если вы создаёте ИИ-агентов на Python с подключением к сторонним MCP-серверам, обновление нужно сделать сегодня.

Бюллетень опубликован в репозитории modelcontextprotocol/python-sdk 28 сентября 2026 года, подробный технический разбор выпустила компания Cycode. На 29 сентября CVE-идентификатор не присвоен, сообщений об эксплуатации в реальных атаках нет. Но сценарий атаки тихий: для сервера авторизации кража выглядит как обычный легитимный вход, поэтому стандартный мониторинг её не заметит. Про то, как устроены агенты и зачем им MCP, мы писали в материале об ИИ-агентах и их внедрении в бизнес.

Одного обновления пакета недостаточно: для двух провайдеров «машина-машина» защита включается только после явной передачи параметра issuer=. Ниже — как работает обход, кого он касается и какой порядок действий закрывает риск полностью.

Что нашли в MCP Python SDK

Model Context Protocol (MCP) — открытый протокол, через который ИИ-приложения и агенты подключаются к внешним инструментам и данным. Когда MCP-клиенту нужно залогиниться, он спрашивает у MCP-сервера, где находится его сервер авторизации, а затем получает у этого сервера OAuth-токены. Согласно бюллетеню, в уязвимых версиях SDK сошлись две слабости: поле issuer в метаданных сервера авторизации проверялось не на всех путях обнаружения, а учётные данные клиента не были жёстко привязаны к тому серверу, для которого их выдали.

Затронуты три класса-провайдера: OAuthClientProvider (интерактивный вход с участием пользователя), ClientCredentialsOAuthProvider и PrivateKeyJWTOAuthProvider (автоматический вход без человека), а также устаревший RFC7523OAuthClientProvider в линейке 1.x. Для неинтерактивных провайдеров оценка — 7.5, для интерактивного — 6.5.

Как злоумышленник обходит проверку

По разбору Cycode, атака начинается с того, что вредоносный MCP-сервер отвечает кодом 404 на первый запрос обнаружения. SDK переходит на запасной путь поиска, и в этой ветке адрес сервера авторизации оказывается пустым — а проверка издателя в коде выполнялась только тогда, когда адрес был получен на первом шаге. В итоге конфигурация, которую подсунул атакующий, принимается без сверки, и он сам задаёт адрес, куда клиент отправит секреты.

Особенно неприятно, что страница входа при этом может быть настоящей: пользователя отправляют к реальному провайдеру идентификации, он подтверждает доступ, а SDK относит client secret, код авторизации и PKCE-ключ на конечную точку атакующего. PKCE, который как раз должен защищать от перехвата кода, в такой схеме не спасает. С этими данными злоумышленник получает валидные access- и refresh-токены у настоящего сервиса — с теми же правами, что у вашего клиента, и с возможностью долго сохранять доступ.

Почему это важно для команд разработки

MCP-клиенты сегодня встроены во внутренние ассистенты, агентов поддержки и CI-ботов, а список подключаемых серверов растёт быстрее, чем их проверка. Уязвимость превращает любой непроверенный MCP-сервер в точку кражи долгоживущих учётных данных: client secret переиспользуется, а refresh-токен позволяет возвращаться в систему снова. Сильнее всего рискуют сервисные сценарии с ClientCredentialsOAuthProvider и PrivateKeyJWTOAuthProvider — там нет человека, который мог бы заметить странность, а секреты заранее выданы на уровне всей интеграции.

Для руководителя это ещё и вопрос цепочки поставок: SDK — общий фундамент для множества агентских фреймворков и внутренних инструментов, поэтому уязвимая версия может прийти транзитивной зависимостью, даже если команда не подключала mcp напрямую.

Что сделать прямо сейчас

Проверьте зависимости. Найдите пакет mcp во всех сервисах, включая транзитивные зависимости: pip show mcp или поиск по lock-файлам. Уязвимы 1.9.1–1.29.1 и 2.0.0–2.1.1.

Обновитесь до исправленной версии: 1.30.0 для линейки 1.x или 2.2.0 и новее для 2.x. Обходного пути для старых версий, по данным бюллетеня, нет.

Включите привязку к издателю. Для ClientCredentialsOAuthProvider и PrivateKeyJWTOAuthProvider передайте параметр issuer= с адресом вашего сервера авторизации — без этого обновление защиту не включает.

Очистите сохранённые OAuth-регистрации после обновления, чтобы клиент заново прошёл обнаружение уже с проверкой.

Если клиент когда-либо подключался к непроверенным MCP-серверам, считайте секреты скомпрометированными: смените client secret и отзовите выданные токены на стороне провайдера идентификации.

Ограничьте круг серверов. Ведите allowlist доверенных MCP-серверов и не давайте агентам подключаться к произвольным адресам — это снижает риск и для будущих уязвимостей того же класса.

Часто задаваемые вопросы

Какие версии MCP Python SDK уязвимы? Пакет mcp версий 1.9.1–1.29.1 и 2.0.0–2.1.1. Исправления вышли в 1.30.0 и 2.2.0.

Есть ли у уязвимости номер CVE? На 29 сентября 2026 года CVE не присвоен; уязвимость отслеживается как GitHub Security Advisory GHSA-qx49-fqc8-xw99.

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

Достаточно ли просто обновить пакет? Для интерактивного OAuthClientProvider — обновления и очистки сохранённых регистраций. Для ClientCredentialsOAuthProvider и PrivateKeyJWTOAuthProvider нужно ещё передать issuer=, иначе проверка не заработает.

Что делать, если клиент уже ходил на сторонние MCP-серверы? Ротировать client secret, отозвать токены у провайдера идентификации и проверить журналы доступа к сервисам, которые открывала интеграция.

Источники

Model Context Protocol, GitHub Security Advisory GHSA-qx49-fqc8-xw99 — «OAuth client could send credentials to an authorization server chosen by the MCP server», 28 сентября 2026 года (первоисточник).

Cycode — технический разбор уязвимости MCP Python SDK OAuth, сентябрь 2026 года.

The Hacker News — «Official MCP Python SDK Flaw Can Let Malicious Servers Steal OAuth Credentials», 29 сентября 2026 года.