Вразливість MCP Workflow Validation Interpreter: справжнє попередження
Ми не підтвердили названу вразливість MCP workflow validation interpreter — ось справжнє перевірене попередження GitHub про OAuth і що робити зараз.
Перевірено за наведеними джерелами .
Що мав охоплювати пошук «вразливості MCP workflow validation interpreter»
Якщо ви потрапили сюди, шукаючи вразливість MCP workflow validation interpreter, ви, ймовірно, шукаєте оголошення безпеки GitHub від 30 вересня 2026 року під назвою «Shared Prototype Mutation Through the MCP Workflow-Validation Interpreter Allows Owner Account Takeover». Ми перевірили офіційні джерела GitHub і не змогли підтвердити існування саме такого оголошення — ні під такою назвою, ні з такою датою, ні з експлойтом через мутацію спільного прототипу як механізмом. Ця стаття прямо про це каже, а далі натомість описує справжнє, перевірене нами попередження безпеки GitHub, знайдене в тому самому часовому проміжку.
Пошукові запити читачів на цю тему також включають «MCP interpreter security advisory», «owner account takeover MCP» та «shared prototype mutation exploit». Жодне з наших офіційних джерел не відповідає саме цій комбінації. Що ми дійсно підтвердили — це інше, справжнє попередження для офіційного Python SDK Model Context Protocol (MCP), опубліковане самими його розробниками, якому присвячена решта цієї статті.
Чому це не та вразливість MCP workflow validation interpreter, яку ви шукали
Наше правило для статей такого типу — вважати єдиним прийнятним джерелом подробиць конкретне назване оголошення: саме воно має підтверджувати уражені версії, версію з виправленням та кроки усунення. Перевіривши офіційні джерела GitHub на запитувану назву «Shared Prototype Mutation Through the MCP Workflow-Validation Interpreter Allows Owner Account Takeover» з датою 30 вересня 2026 року, ми не знайшли документа, який би їй відповідав — тобто жодне офіційне джерело не підтверджує саме цю вразливість MCP workflow validation interpreter під такою назвою чи датою. Ми вважаємо, що публікувати подробиці, запозичені з іншого, невідповідного попередження, було б гірше, ніж не публікувати нічого, бо команда могла б застосувати неправильне виправлення й хибно відчути себе захищеною.
Найближчий офіційний документ, який ми знайшли в тому самому часовому проміжку, — це оголошення безпеки GitHub для проєкту modelcontextprotocol/python-sdk, опубліковане 28 вересня 2026 року, за два дні до запитуваної дати. У його власному тексті описано, що клієнт OAuth може надсилати облікові дані на сервер авторизації, обраний MCP-сервером, а не експлойт через мутацію спільного прототипу всередині інтерпретатора валідації робочих процесів. Оскільки це справжній документ, який ми змогли підтвердити, у наступному розділі ми описуємо його як реальне оновлення, прямо зазначаючи, що він не відповідає первісно запитуваній назві чи механізму.
Справжнє попередження GitHub, яке ми знайшли: переспрямування облікових даних OAuth у MCP Python SDK
GitHub опублікував це попередження під назвою «OAuth client could send credentials to an authorization server chosen by the MCP server» 28 вересня 2026 року для пакета mcp, який розробники Python SDK Model Context Protocol поширюють через PyPI. У попередженні сказано, що уражені версії підтримки клієнта OAuth у SDK не перевіряли заявлену ідентичність сервера авторизації на кожному шляху виявлення й не прив'язували збережені або попередньо налаштовані облікові дані клієнта до сервера авторизації, якому вони належать. Там зазначено, що зловмисний або скомпрометований MCP-сервер міг використати цю прогалину, щоб переспрямувати ці облікові дані — зокрема секрет клієнта, код авторизації чи верифікатор PKCE — на кінцеву точку токенів, обрану на власний розсуд.
За даними попередження, це стосується застосунків, які використовують SDK як MCP-клієнт через HTTP за допомогою OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider або застарілого RFC7523OAuthClientProvider з лінії 1.x, коли такий клієнт може підключатися до MCP-сервера, якому він не повністю довіряє, маючи при цьому облікові дані для справжнього сервера авторизації. У попередженні зазначено, що версії 1.9.1–1.29.1 не мали цієї перевірки на жодному шляху, тоді як 2.0.0–2.1.1 не мали її лише на застарілому резервному шляху. Додано, що MCP-сервери, побудовані на SDK, клієнти на основі stdio та клієнти, які прикріплюють власні токени чи заголовки, не постраждали.
Виправлення, запропоноване в попередженні, — оновитися до версії 2.2.0 або новішої в лінії 2.x, або до 1.30.0 чи новішої в лінії 1.x. Там зазначено, що саме оновлення не повністю закриває прогалину для двох провайдерів на основі облікових даних: команда також має явно задати значення issuer, бо без нього клієнт усе ще слідує за тим сервером авторизації, який рекламує підключений MCP-сервер. У попередженні це наразі назване попередженням про застарівання, яке стане обов'язковим налаштуванням у майбутньому релізі 3.0.
| Лінія SDK | Уражені версії | Виправлена версія | Прогалина за описом попередження |
|---|---|---|---|
| 2.x | >=2.0.0a1, <2.2.0 | 2.2.0 | Відсутня перевірка issuer на шляхах, де сервер не публікував метадані захищеного ресурсу |
| 1.x | >=1.9.1, <1.30.0 | 1.30.0 | Відсутня перевірка issuer або прив'язка облікових даних на будь-якому шляху виявлення |
Щодо усунення проблеми, попередження радить командам очистити будь-яку реєстрацію клієнта OAuth, збережену до оновлення, оскільки реєстрація, збережена без issuer, залишається неприв'язаною — а це, за словами попередження, стосується всього, що зберігала лінія 1.x до версії 1.30.0. Також там зазначено, що клієнту, який міг підключатися до недовіреного MCP-сервера до виправлення, слід ротувати секрет клієнта та відкликати токени на сервері авторизації. Для версій до виправлення в попередженні сказано, що іншого обхідного шляху немає, крім як підключати OAuth-клієнти лише до вже довірених MCP-серверів.
Лише для довідки: примітки до релізу версії SDK 2.2.0 від тих самих розробників, опубліковані 7 вересня 2026 року, описують відповідну зміну коду як перевірку заявленого issuer сервера авторизації на кожному шляху виявлення, включно із застарілим шляхом, який раніше цю перевірку пропускав. Ми наводимо цю примітку лише для пояснення типу зміни коду, яку припускають кроки усунення з попередження, а не як окреме джерело фактів про саму вразливість.
Попередження не згадує n8n, жодну редакцію n8n чи n8n Cloud; воно називає лише Python-пакет mcp і не вказує ідентифікатор CVE чи те, чи інші продукти включають цей SDK у себе. Ми повідомляємо тут лише про те, чого воно не охоплює, бо це заявлене обмеження, а не прогалина, яку може заповнити інше джерело. Це залишається найближчим перевіреним офіційним документом до первісно запитуваної вразливості MCP workflow validation interpreter, а не підтвердженим збігом із нею. На нашу думку, оновлення безпеки стає придатним до дії лише тоді, коли його обсяг настільки чітко обмежений, — і саме це робить конкретне попередження кориснішим за розмите застереження.
Sources: OAuth client could send credentials to an authorization server chosen by the MCP server · Advisory · modelcontextprotocol/python-sdk · GitHub, Release v2.2.0 · modelcontextprotocol/python-sdk · GitHub
Що командам n8n варто зробити зараз і що залишається невідомим з попередження
Оскільки попередження мовчить про n8n, решта цього розділу — наші власні редакційні рекомендації для команд, які підключають n8n до зовнішніх MCP-інструментів.
Окремо від будь-яких рекомендацій самого попередження, ми радили б командам, які підключають n8n до зовнішніх MCP-серверів через AI-чат-клієнти, перевірити, чи їхні MCP-інструменти залежать від коду клієнта OAuth із цього SDK, і якщо так — підтвердити, яка версія використовується, перш ніж припускати, що виправлення їх не стосується.
Поки команда не підтвердить власну вразливість, рекомендовані перевірки:
Для команд, які хочуть структурованої практики критичного аналізу інтеграції MCP перед тим, як довіряти їй у продакшені, завдання MCP-сервера від n8n Balloon Challenges проводить через побудову MCP-сервера в n8n, який AI-клієнти можуть виявляти та викликати інструменти через нього — це один зі способів розвинути звичку такої перевірки.
