В офіційному 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.30.0 (гілка 1.x) або версії 2.2.0 (гілка 2.x). В оновлених версіях клієнт визначає очікуваний сервер авторизації до отримання будь-яких метаданих і відхиляє ті, що не збігаються.
- Для
ClientCredentialsOAuthProviderіPrivateKeyJWTOAuthProvider— обов’язково передайте параметрissuer=з адресою легітимного сервера авторизації (наприклад,issuer="https://auth.example.com"). Без цього параметра оновлені провайдери як і раніше слідують за сервером авторизації, вказаним MCP-сервером. У версії 1.30.0 попередження про відсутністьissuer=виводиться як стандартне попередження про застарівання, яке Python приховує за замовчуванням — його легко проґавити. - Застарілий
RFC7523OAuthClientProviderне підтримує параметрissuer=. Потрібно перейти на один із двох інших провайдерів. - Очистіть збережені OAuth-реєстрації одноразово після оновлення. Реєстрації, створені до виправлення, не прив’язані до конкретного сервера авторизації і залишаються в такому стані.
- Якщо клієнт міг підключатися до ненадійного 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= для міжмашинних провайдерів, очистити старі реєстрації та, за підозри на компрометацію, виконати ротацію секретів. Проміжок у три тижні між виходом патча та публікацією бюлетеня означає, що частина користувачів могла оновитися, не усвідомлюючи критичність змін.
