Злонамерен MCP сървър може да подлъже приложение, изградено върху официалния MCP Python SDK, да предаде OAuth идентификационните си данни, които използва за влизане в реална услуга, съобщават поддържащите екипи на SDK в консултативно съобщение за сигурност.
Засегнатите версии изпращат клиентския тайна (client secret), кода за оторизация (authorization code) и PKCE доказателствения ключ към край точка за токени, контролирана от атакуващия. Корекцията за сигурност е налична във версии 1.30.0 и 2.2.0.
Model Context Protocol (MCP) е отворен стандарт за свързване на AI приложения с външни инструменти и данни, а този пакет е неговият официален Python SDK за изграждане на MCP сървъри и клиенти.
С откраднатите идентификационни данни атакуващият може да поиска валиден токен за достъп от реалната услуга за влизане. Cycode, фирмата за сигурност, която докладва за пролуката, демонстрира пълния обмен в тест и заявява, че полученият токен носи каквито права са били предоставени на приложението. Клиентският таен ключ е дълготраен, така че продължава да работи, докато не бъде подменен.
Уязвимостта е оценена като висока (7.5) за двата провайдъра, които работят без присъствие на човек. За интерактивния провайдър, при който някой трябва да стартира влизането, оценката е 6.5. Към 29 септември няма асоцииран CVE номер.
Как сървър открадва идентификационните данни
Когато MCP клиент трябва да влезе в системата, той пита сървъра, към който се свързва, къде може да бъде намерена неговата услуга за влизане, наречена authorization server. При засегнатите версии SDK не винаги проверява този отговор. Злонамерен сървър може да го насочи към услуга за влизане по избор на атакуващия — или чрез посочване на собствения сървър на атакуващия, или чрез подаване на данни за влизане, които назовават реалната услуга на потребителя, но изпращат идентификационните данни другаде.
След това клиентът изпраща своята тайна, своя код за оторизация и своя PKCE доказателствен ключ на атакуващия вместо на реалната услуга. Доказателственият ключ е еднократна стойност, предназначена да предотврати повторното използване на откраднат код за оторизация, така че предаването му премахва тази защита.
При интерактивния провайдър потребителят все пак трябва да одобри влизането. Cycode заявява, че страницата, която одобряват, е автентичната страница за влизане, така че нищо не изглежда подозрително. Двата машина-към-машина (machine-to-machine) провайдъра не изискват влизане и никакво човешко участие.
Кой е засегнат
Дадено приложение е засегнато, ако използва SDK като MCP клиент през HTTP с един от OAuth провайдърите OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider или остарелия 1.x RFC7523OAuthClientProvider и може да се свързва със сървър, който не контролира напълно, докато държи идентификационни данни за реална услуга за влизане. MCP сървъри, изградени с SDK, локални (stdio) клиенти и клиенти, които прикачват свои собствени токени, не са засегнати.
| Line | Affected | Fixed in |
|---|---|---|
| 1.x | 1.9.1 through 1.29.1 | 1.30.0 |
| 2.x | 2.0.0 through 2.1.1 | 2.2.0 |
Какво да направите
Обновете до 1.30.0 за клона 1.x или 2.2.0 за клона 2.x. Коригираните версии определят коя услуга за влизане очакват преди извличането на каквито и да било данни и отхвърлят всякакви заявки, които посочват различна услуга.
Обновяването не решава напълно проблема за два от провайдърите. Ако използвате ClientCredentialsOAuthProvider или PrivateKeyJWTOAuthProvider, в съобщението се посочва, че „обновяването не променя нищо, докато не подадете и issuer=“, за да посочите услугата за влизане, към която принадлежат тези идентификационни данни. Без това те продължават да следват сървъра, към който ги насочва MCP сървърът.
Във версия 1.30.0 предупреждението за това е стандартно предупреждение за остарял функционалност (deprecation warning), което Python скрива по подразбиране, така че е лесно да бъде пропуснато. Остарелият RFC7523OAuthClientProvider изобщо няма опция issuer=, така че преминете към един от другите два провайдъра.
След обновяване изчистете еднократно всички съхранени регистрационни данни на OAuth клиенти, тъй като по-старите не са обвързани с услуга за влизане и остават в това състояние. Ако даден клиент вече се е свързвал с ненадежден сървър, подменете (ротирайте) неговия клиентски таен ключ и отменете токените му в услугата за влизане. При по-старите версии няма друго решение, освен да се свързвате само с MCP сървъри, на които се доверявате.
Ракриване на уязвимостта
Проверките за issuer са включени в бележките към версии 1.30.0 и 2.2.0 на 7 септември, вписани като промени в поведението, а не като корекция за сигурност. Бюлетинът за сигурност последва на 28 септември — същия ден, в който Cycode публикува своя доклад. Бюлетинът отдава заслуги на осем изследователи, включително изследователя на Cycode.
Нито в бюлетина, нито от Cycode се съобщава за извършени атаки с използване на тази уязвимост, нито има данни за такива от други източници.