Виявлено вразливість Azure DevOps MCP: приховані інструкції експлуатують ШІ-агентів

Дослідники з Manifold Security виявили вразливість у Azure DevOps MCP, яка дозволяє зловмисникам приховувати інструкції всередині коментарів до запитів на злиття (pull requests). Ці інструкції невидимі для людей, але можуть бути прочитані агентами штучного інтелекту, що призводить до потенційного несанкціонованого доступу.

Вразливість Azure DevOps MCP

Проблема полягає в тому, що описи запитів на злиття в Azure DevOps підтримують Markdown, який, своєю чергою, підтримує HTML-коментарі. Коментар, написаний як <!-- instructions here -->, не відображається у веб-інтерфейсі, тому людина, яка переглядає зміни, його не бачить. Однак агент ШІ може викликати офіційний сервер Azure DevOps MCP Microsoft для отримання цього ж опису запиту на злиття. Сервер повертає текст коментаря повністю, включно з прихованою частиною.

Як працює експлуатація

Конкретний інструмент, що відповідає за отримання запиту на злиття за ідентифікатором, виявився вразливим. Він пропускає захист, який Microsoft вбудувала для подібних сценаріїв. Інші інструменти на тому ж сервері, що охоплюють сторінки вікі та журнали збірок, обгортають ненадійний вміст роздільниками. Це дозволяє моделі агента відрізняти «це дані» від «це інструкція». Інструмент запитів на злиття не отримав такого оброблення, тому будь-що приховане в описі запиту на злиття досягає моделі як звичайний, довірений текст.

Зловмиснику достатньо мати доступ на запис до одного репозиторію, щоб розмістити приманку. Як тільки агент жертви переглядає її, цей агент, автентифікований як жертва, успадковує реальні дозволи жертви в усій організації, а не лише в одному проєкті, до якого торкнувся зловмисник. Ця техніка відома як ін'єкція запитів (prompt injection).

Умови для успішної атаки

Експлуатація вразливості Azure DevOps MCP на практиці залежить від кількох факторів:

• Режим автоматичного схвалення агента: Якщо агент працює в режимі автоматичного схвалення, без запиту підтвердження перед виконанням кожного виклику інструменту, прихована інструкція не буде виявлена. Повністю автономні конфігурації усувають цю перевірку.
• Широка область дії токена: Якщо персональний токен доступу, що стоїть за агентом, охоплює всю організацію, а не один проєкт, успішне захоплення може поширитися на конвеєри, вікі та репозиторії за межами початкового запиту на злиття.
• Наявність зайвих інструментів: Асистент для перегляду коду, який також може запускати конвеєри, читати вікі та публікувати коментарі, надає додаткові шляхи для завдання шкоди та витоку даних у разі захоплення.

Рекомендовані заходи захисту

Доки Microsoft не випустить офіційне виправлення, рекомендуються такі зміни:

• Обмежте область дії токенів: Надавайте токени лише для одного проєкту, а не для всієї організації. Це обмежує можливості захопленого агента.
• Завантажуйте лише необхідні інструменти MCP: Локальний сервер Azure DevOps MCP підтримує прапорець для обмеження груп інструментів, які він надає. Агент, призначений лише для перегляду, не потребує доступу до конвеєрів або вікі.
• Залучайте людину до процесу: Для будь-яких дій, що перетинають межі проєктів, залучайте людину для підтвердження. Автоматичне схвалення усуває єдиний контроль, на який розраховує ця атака.
• Ведіть журнали дій агентів: Відстежуйте дії ваших агентів. Агент перегляду, який раптово запускає збірку в непов'язаному проєкті або публікує коментар з даними, які його не просили отримувати, є сигналом для тривоги.

Широкі наслідки та статус виправлення

Доказ концепції Manifold працював як проти GitHub Copilot CLI, так і проти Claude Code, що свідчить про те, що це не єдина проблема конкретного постачальника, а скоріше шаблон, за яким слід стежити. Будь-який сервер MCP, який передає агенту створений користувачами контент (квитки, повідомлення підтримки, коментарі до коду) без належного обгортання та маркування, може бути вразливим.

Manifold повідомила про проблему до Центру реагування на безпеку Microsoft (MSRC), який визнав та класифікував її. Однак станом на момент публікації не було призначено CVE, і патч не був випущений. Microsoft ще не застосувала свій механізм захисту до інструменту запитів на злиття, як це вже зроблено для вікі та журналів збірок. До цього часу вищезгадані заходи є єдиним реальним захистом.

Що це означає для розробників

Розробникам слід негайно перевірити конфігурації своїх ШІ-агентів в Azure DevOps. Необхідно обмежити область дії токенів до одного проєкту, завантажувати лише необхідні інструменти MCP та залучати людину до схвалення дій, що виходять за межі проєкту, щоб запобігти експлуатації.

Ключові факти

• Виявлено вразливість Azure DevOps MCP, що дозволяє приховувати інструкції в коментарях до запитів на злиття (pull requests).

• Приховані інструкції невидимі для людей, але доступні для читання агентами ШІ.

• Атака використовує Markdown-коментарі HTML (<!-- instructions here -->) у описах запитів на злиття.

• Вразливість дозволяє агенту ШІ, що працює від імені жертви, отримати доступ до проєктів, до яких атакуючий не мав доступу.

• Ця техніка називається "ін'єкція запитів" (prompt injection).

Джерела

• Azure DevOps MCP Flaw: How to Lock Down Your AI Review Agent Before Microsoft Patches It