Вразливість в офіційному MCP Python SDK дозволяла шкідливому серверу викрадати OAuth-облікові дані застосунку та перебирати акаунт. Виправлення — у версіях 1.30.0 і 2.2.0.
28 вересня 2026 року підтримувачі офіційного Python SDK протоколу Model Context Protocol (MCP) опублікували безпековий бюлетень GHSA-qx49-fqc8-xw99 про вразливість, яка дозволяла шкідливому MCP-серверу викрадати OAuth-облікові дані застосунку, що до нього підключається. Ідеться не про короткочасний сесійний токен, а про клієнтський секрет, код авторизації та PKCE-ключ — набір, якого достатньо, щоб від імені застосунку отримати повноцінний access-токен з усіма його правами.
Вразливість виявила й описала компанія Cycode, що спеціалізується на безпеці ланцюга постачання програмного забезпечення. Станом на 29 вересня CVE-ідентифікатор ще не був присвоєний, а виправлення вже вийшли у версіях 1.30.0 (гілка 1.x) і 2.2.0 (гілка 2.x). Відомих атак із використанням цієї вразливості на момент публікації не зафіксовано, однак сам характер проблеми — викрадення довгоживучих облікових даних — робить її небезпечною для всіх, хто підключає AI-застосунки до зовнішніх MCP-серверів.
Що сталося
Cycode виявила, що MCP-клієнт, побудований на офіційному SDK, у вразливих версіях не завжди перевіряв, який саме сервіс логіну (authorization server) йому називає MCP-сервер. Шкідливий сервер міг вказати на власний токен-ендпоінт і змусити застосунок надіслати туди чутливі дані: клієнтський секрет, свіжий код авторизації та PKCE-ключ (code_verifier).
Отримавши цей набір, атакуючий надсилає його на справжній токен-ендпоінт реального сервісу логіну, отримує валідний access-токен і підтверджує перехоплення акаунта. Cycode продемонструвала повний ланцюг на реальному authorization server з увімкненим PKCE. Код авторизації — одноразовий, але клієнтський секрет довгоживучий: він продовжує працювати, доки його не змінять, тому атакуючий зберігає можливість авторизовуватися знову й знову.
Вразливість оцінено як високу (CVSS 7,5) для двох провайдерів, що працюють без участі людини, і як середню (6,5) для інтерактивного провайдера, де хтось має запустити вхід. Показово, що перевірки issuer з'явилися у релізах 1.30.0 і 2.2.0 ще 7 вересня, але були описані як «зміна поведінки», а не як безпекове виправлення. Бюлетень вийшов 28 вересня — того ж дня, коли Cycode опублікувала свій розбір. Це означає, що майже три тижні користувачі могли оновлюватися, навіть не підозрюючи, що в релізах закрито безпекову прогалину.
Що таке MCP і чому це важливо
Model Context Protocol (MCP) — це відкритий стандарт для підключення AI-застосунків до зовнішніх інструментів і даних. Його представила компанія Anthropic у 2024 році, і відтоді протокол швидко став фактичним стандартом для того, щоб AI-агенти могли звертатися до баз даних, репозиторіїв, API та корпоративних сервісів. Офіційний Python SDK — один із найпопулярніших інструментів для створення MCP-серверів і клієнтів.
Чому саме OAuth-облікові дані — критична ціль? Коли MCP-клієнт авторизується на сторонньому сервісі, він отримує токен із тими правами, які застосунку надали. Викравши клієнтський секрет і код авторизації, атакуючий отримує ті самі права, що й легітимний застосунок, — без жодного злому самого сервісу. Для корпоративних сценаріїв, де агенту делегують доступ до пошти, хмарних ресурсів або CI/CD, це означає компрометацію всього, до чого агент мав доступ. І на відміну від фішингу чи соціальної інженерії, тут жертва може взагалі не вводити жодних даних — достатньо, щоб її застосунок підключився до «неправильного» MCP-сервера.
Технічний розбір: як сервер краде облікові дані
Механізм атаки елегантний і тому небезпечний. Коли MCP-клієнту потрібно увійти, він запитує у MCP-сервера, де розташований його authorization server — сервіс логіну. За специфікацією клієнт має переконатися, що цей сервіс є тим, якому належать його облікові дані (перевірка issuer). У вразливих версіях SDK ця перевірка була неповною або взагалі була відсутня.
Атакуючий MCP-сервер міг зробити одне з двох: або назвати власний токен-ендпоінт, або віддати метадані логіну, які вказують на справжній сервіс користувача, але спрямувати самі облікові дані в інше місце. Клієнт «довіряв» відповіді сервера й відправляв клієнтський секрет, код авторизації та PKCE-ключ туди, куди той вказав.
Особливо підступним є злам PKCE. Proof Key for Code Exchange — це механізм, який існує саме для того, щоб перехоплений код авторизації не можна було використати повторно. Віддавши атакуючому і код, і ключ, клієнт зводить нанівець цей захист. Для інтерактивного провайдера людина все ще має підтвердити вхід — і сторінка, яку вона бачить, є справжньою сторінкою логіну, тому нічого не виглядає підозрілим. Два провайдери типу machine-to-machine взагалі не потребують участі людини, що й пояснює вищий бал CVSS для них.
Ключова деталь — асиметрія між тим, що бачить користувач, і тим, що насправді відбувається. Користувач бачить легітимну сторінку логіну свого сервісу й підтверджує вхід, а тим часом його застосунок у фоновому режимі віддав секрет і код сторонньому серверу. Саме ця «невидимість» атаки робить її складною для виявлення звичайними засобами.
Кого це стосується
Під загрозою застосунок, який одночасно: використовує SDK як MCP-клієнт через HTTP; застосовує один із провайдерів OAuth — OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider або застарілий RFC7523OAuthClientProvider (гілка 1.x); підключається до сервера, який він не контролює повністю; і при цьому тримає облікові дані для реального сервісу логіну.
Зачеплені версії: від 1.9.1 до 1.29.1 у гілці 1.x (виправлено в 1.30.0) та від 2.0.0 до 2.1.1 у гілці 2.x (виправлено в 2.2.0). Іншими словами, під уразливість потрапляють майже всі випуски обох гілок за останній час — тобто переважна більшість реальних інсталяцій.
Водночас уразливість не стосується MCP-серверів, побудованих на SDK, локальних клієнтів через stdio, а також клієнтів, які підключають власні токени без використання провайдерів OAuth. Тобто загроза сконцентрована саме на конфігураціях, де клієнт авторизується через OAuth на сервері, якому не можна повністю довіряти. Це, зокрема, типові сценарії підключення агентів до публічних каталогів MCP-серверів.
Як захиститися
Перший і головний крок — оновити SDK до виправлених версій 1.30.0 або 2.2.0. У них клієнт спершу визначає, який сервіс логіну він очікує, і відкидає будь-який інший.
Однак оновлення — це не вся історія. Для провайдерів ClientCredentialsOAuthProvider та PrivateKeyJWTOAuthProvider виправлення «не змінює нічого, доки ви не передасте параметр issuer=» — так радять у бюлетені. Цей параметр явно називає сервіс логіну, якому належать облікові дані; без нього клієнт і далі слідуватиме за тим сервером, на який вкаже MCP-сервер. У версії 1.30.0 попередження про це є звичайним deprecation warning, який Python приховує за замовчуванням, тому його легко пропустити. А застарілий RFC7523OAuthClientProvider взагалі не має параметра issuer= — від нього варто перейти на один із двох інших провайдерів.
Додаткові кроки після оновлення: одноразово очистити збережені OAuth-реєстрації клієнта, оскільки старі записи не прив'язані до сервісу логіну; якщо клієнт міг підключатися до ненадійного сервера — змінити клієнтський секрет і відкликати токени на сервісі логіну. На старих версіях єдиний спосіб уникнути проблеми — підключатися лише до MCP-серверів, яким ви довіряєте.
Окремо варто переглянути сам список MCP-серверів, до яких підключаються ваші агенти. Кожен публічний або сторонній сервер — це потенційна точка входу, і мінімізація цього списку зменшує площу атаки. Якщо ви вже використовуєте MCP-агенти у своїх проєктах, варто також перевірити, чи не «витекли» вже ваші облікові дані, — це можна зробити за допомогою нашого інструменту перевірки витоків.
Хронологія подій
Коротка хронологія, щоб зрозуміти, наскільки «тихо» пройшло виправлення:
- 7 вересня 2026 — у релізах 1.30.0 і 2.2.0 з'являються перевірки issuer, описані в реліз-нотах як зміна поведінки, а не як безпековий фікс.
- 28 вересня 2026 — Cycode публікує детальний розбір, а підтримувачі випускають безпековий бюлетень GHSA-qx49-fqc8-xw99.
- 29 вересня 2026 — станом на цю дату CVE-ідентифікатор ще не присвоєно, а відомих атак із використанням вразливості в дикій природі не зафіксовано.
Тобто майже три тижні між «виправленням» і «оголошенням» — це час, протягом якого частина користувачів могла оновитися випадково, а частина — так і залишитися на вразливих версіях, не підозрюючи про ризик.
Що це означає для безпеки AI-агентів
Ця вразливість — важливий дзвіночок для всієї молодої екосистеми AI-агентів. MCP стрімко набирає популярності, і багато команд уже делегують агентам доступ до реальних систем — пошти, репозиторіїв, хмарних сервісів, корпоративних API. Вразливість в офіційному SDK показує, що навіть «еталонний» інструмент може мати прогалини в довірі між клієнтом і сервером, які відкривають шлях до перехоплення акаунтів.
Прикметно, що це не перше безпекове виправлення в цьому SDK за останній час. Ще раніше, у версії 1.27.2, закрили іншу проблему — CVE-2026-52869, коли транспорти SSE та Streamable HTTP маршрутизували запити в наявну сесію лише за ідентифікатором сесії, не перевіряючи, чи належить вона тому самому автентифікованому клієнту. Разом ці виправлення свідчать про те, що протокол, який стрімко став стандартом де-факто, зараз проходить інтенсивний період зміцнення безпеки — і що «офіційний SDK» не звільняє від пильності.
Три висновки для розробників і команд безпеки. По-перше, AI-агенти успадковують ті самі проблеми постачання та авторизації, що й звичайний софт, — і навіть більші, бо агенту делегують дедалі ширші права. По-друге, «безпекове» виправлення, опубліковане як звичайна зміна поведінки без чіткого анонсу, означає, що частина користувачів оновиться пізно або не оновиться взагалі — варто стежити за бюлетенями залежностей уважніше, ніж за реліз-нотами. По-третє, будь-який зовнішній MCP-сервер слід розглядати як потенційно недовірений, доки ви не контролюєте його повністю.
Для тих, хто лише починає працювати з AI-агентами та хоче вибудувати грамотну модель довіри й авторизації, корисно почати з бази — у нашому матеріалі про кібербезпеку й навчання зібрано основи, з яких варто стартувати.
Висновок
Вразливість в офіційному MCP Python SDK — нагадування про те, що навіть популярні й довірені інструменти AI-екосистеми можуть містити серйозні прогалини в авторизації. Вона дозволяла шкідливому серверу викрасти клієнтський секрет, код авторизації та PKCE-ключ і від імені застосунку перебрати акаунт. Виправлення вже доступні у версіях 1.30.0 і 2.2.0, але для частини провайдерів потрібен явний параметр issuer=.
Головна порада проста: оновіть SDK, явно вкажіть issuer для відповідних провайдерів, очистіть старі OAuth-реєстрації та змініть секрети, якщо був ризик підключення до ненадійного сервера. І запам'ятайте правило, яке ця історія ілюструє краще за будь-яку іншу: в AI-агентів довіра має бути явною і перевіреною, а не успадкованою за замовчуванням.
