Вада в офіційному MCP Python SDK дозволяє шкідливим серверам викрадати OAuth-дані

У чому полягає вада

В офіційному MCP Python SDK є вада безпеки, яка дозволяє шкідливому MCP-серверу змусити застосунок передати OAuth-дані, якими той користується для входу в справжній сервіс. Розробники SDK описали проблему в бюлетені безпеки, опублікованому 28 вересня. MCP (Model Context Protocol) — відкритий стандарт для підключення AI-застосунків до зовнішніх інструментів і даних, а цей пакет — його офіційний Python SDK.

У вразливих версіях клієнт, якому потрібно було ввійти, запитував у MCP-сервера, де розташований його сервер авторизації, і SDK не завжди перевіряв цю відповідь. Шкідливий сервер міг вказати на підконтрольний зловмиснику сервіс входу, і клієнт надсилав свій client secret, код авторизації та ключ PKCE нападнику, а не справжньому провайдеру.

Чому це небезпечно

Ключ PKCE — одноразове значення, покликане унеможливити повторне використання викраденого коду авторизації, тож його передача знімає й цей захист. Маючи викрадені дані, нападник може запросити чинний access token у справжнього сервісу.

Компанія Cycode, яка повідомила про ваду, продемонструвала повний обмін у тесті та заявила, що отриманий токен має всі права, надані застосунку. client secret є довготривалим, тому працює, доки його не змінять. Ваду оцінено як високу, 7.5, для двох провайдерів, що працюють без участі людини, і як 6.5 для інтерактивного. Станом на 29 вересня ідентифікатор CVE ще не було присвоєно.

Хто в зоні ризику

Застосунок уразливий, якщо він використовує SDK як MCP-клієнт через HTTP з OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider або застарілим 1.x RFC7523OAuthClientProvider і може підключитися до сервера, який не контролює повністю, маючи дані для справжнього сервісу входу. 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.

Що робити

Оновіться до 1.30.0 або 2.2.0. У виправлених версіях клієнт спершу сам визначає, якого сервісу входу очікує, і відхиляє будь-який, що вказує на інший.

Застосунки з ClientCredentialsOAuthProvider або PrivateKeyJWTOAuthProvider мають додатково передати issuer=, щоб назвати сервіс входу, якому належать ці дані; без цього саме оновлення нічого не змінює. Застарілий RFC7523OAuthClientProvider не має параметра issuer=, тож його слід замінити. На старіших версіях підключайтеся лише до тих MCP-серверів, яким довіряєте.

Перевірки issuer з'явилися в примітках до випусків 1.30.0 і 2.2.0 7 вересня як зміни поведінки, а не як виправлення безпеки; бюлетень вийшов 28 вересня, того ж дня, коли Cycode опублікувала свій розбір. Про атаки з використанням вади не повідомлялося.