Дослідники з Intezer спільно з Kodem Security виявили в агентній IDE AWS Kiro ланцюжок атаки, який давав змогу через прихований текст на звичайній веб-сторінці досягти віддаленого виконання довільного коду на машині розробника. Атака експлуатувала можливість агента перезаписувати конфігураційний файл серверів Model Context Protocol без фактичного схвалення користувача. AWS усунула проблему, однак окремий CVE для цієї вразливості не було присвоєно. Усі користувачі Kiro на версіях нижче 0.11.130 мають негайно оновитися до актуальної збірки 1.0.x через офіційну сторінку завантаження.
Механізм атаки: від веб-сторінки до виконання коду
Архітектура безпеки Kiro ґрунтувалася на моделі «людина в циклі»: агент міг виконувати команди оболонки, завантажувати URL і редагувати файли, але передбачалося, що розробник схвалює кожну ризиковану дію. Вразливість дозволяла повністю обійти цей контрольний механізм.
За даними дослідників, ключовою ланкою ланцюжка був файл ~/.kiro/settings/mcp.json, який визначав список серверів Model Context Protocol і команди для їх запуску. Під час зміни цього файла Kiro автоматично перезавантажувала конфігурацію та запускала описані в ній сервери з привілеями поточного користувача. На момент дослідження агент міг записувати до mcp.json через вбудований інструмент fsWrite без запиту схвалення.
Для доставки зловмисних інструкцій у контекст агента використовувався класичний прийом: у демонстраційному сценарії інструкції були розміщені у вигляді однопіксельного білого тексту (color:#fff;font-size:1px) на сторінці, яка зовні виглядала як звичайна API-документація. Розробник бачив чисту довідкову сторінку, а агент інтерпретував прихований блок як завдання з налаштування, записував зловмисний сервер до mcp.json і перезавантажував конфігурацію. Упродовж кількох секунд запускався підставний MCP-сервер, що виконував код атакувального.
Як повідомляють дослідники, в демонстрації корисне навантаження кожні десять секунд надсилало на сервер зворотного виклику імʼя хоста, імʼя користувача та платформу — цього було достатньо для підтвердження факту виконання. Той самий примітив дозволяв виконати будь-яку команду, доступну розробнику: викрасти облікові дані та вихідний код, закріпитися в системі або розгорнути атаку на внутрішню інфраструктуру.
Показово, що Kiro в низці випадків відображала спливне повідомлення про зміну конфігурації MCP із запитом схвалення. Однак, за даними Intezer, конфігурація перезавантажувалася незалежно від дій користувача — попередження не забезпечувало реального захисту. Єдина дія, яку розробник фактично схвалював, — завантаження URL.
Дослідники зазначають, що атака не є абсолютно надійною: модель недетермінована й може проігнорувати прихований блок, просто узагальнивши вміст сторінки. Втім, у тестах атака спрацьовувала в межах однієї-двох спроб. Зворотний виклик було спрямовано на localhost, тому реальні користувачі не зазнавали впливу.
Хронологія: три дослідження — одна архітектурна проблема
Виявлена Intezer вразливість — не перший випадок експлуатації цього архітектурного патерна в Kiro. У день релізу продукту в липні 2025 року Йоханн Ребергер з Embrace The Red продемонстрував аналогічний вектор: інʼєкція через промпт записувала код у файл налаштувань MCP і виконувала його під час збереження. Він також вказав на другий маршрут — запис до .vscode/settings.json для додавання команд оболонки до списку дозволених.
AWS відреагувала випуском Kiro 0.1.42, додавши запит схвалення для таких записів, але, згідно з бюлетенем безпеки AWS-2025-019, цей захист діяв лише в режимі Supervised. Режим Autopilot, що використовувався за замовчуванням, і далі дозволяв запис без схвалення — саме його й експлуатував ланцюжок Intezer у 2026 році.
Паралельно компанія Cymulate виявила споріднену вразливість: Kiro автоматично виконувала код, записаний у .vscode/tasks.json, під час відкриття теки. AWS присвоїла цій проблемі ідентифікатор CVE-2026-10591 з оцінкою 8.8 за CVSS 3.1 і 8.6 за CVSS 4.0, усунувши її в серії 0.11, що підтверджено бюлетенем безпеки AWS.
За даними Intezer, ланцюжок через mcp.json залишався працездатним на версіях 0.9.2 (macOS) і 0.10.16 (Ubuntu) на момент подання звіту через HackerOne 11 лютого 2026 року. Дослідники підтвердили виправлення у версії 0.11.130.
Ужиті заходи та поточна модель захисту
AWS перейшла від довіри до рішень моделі щодо чутливих файлів до примусових перевірок на рівні платформи. Згідно з документацією з безпеки Kiro, файли mcp.json, .vscode/tasks.json, каталог .git та інші критичні шляхи тепер віднесено до категорії захищених і вони потребують явного схвалення перед записом.
Документація прямо вказує: «Supervised mode is a code review workflow, not a security control» — режим Supervised є робочим процесом ревʼю коду, а не механізмом безпеки. Версія Kiro 1.0 реалізує модель дозволів на основі можливостей, запитуючи згоду користувача на будь-яку дію, яку не було попередньо дозволено. Захист захищених шляхів діє в обох режимах — і Autopilot, і Supervised.
Intezer підтвердила, що атака не відтворюється, починаючи з версії 0.11.130. Експлуатацію вразливості в реальних атаках не зафіксовано, однак публічний PoC доступний. Дослідження охоплювало лише Kiro IDE — чи поширюється проблема на Kiro CLI або веб-версію, не встановлено.
Рекомендації
- Негайно оновіть Kiro до актуальної версії 1.0.x. На момент публікації останньою доступною збіркою є 1.0.165.
- Перевірте вміст
~/.kiro/settings/mcp.jsonна наявність невідомих MCP-серверів або підозрілих команд запуску. - Не використовуйте версії нижче 0.11.130 — вони вразливі до описаного ланцюжка атаки.
- Обмежте автоматичне завантаження зовнішнього контенту агентними IDE: кожен URL, який агент завантажує на запит розробника, є потенційним вектором інʼєкції промптів.
- Аудитуйте конфігураційні файли (
mcp.json,.vscode/tasks.json,.vscode/settings.json) у CI/CD-пайплайнах і під час ревʼю — будь-які неочікувані зміни в них можуть свідчити про компрометацію.
Три незалежні дослідження за рік виявили один і той самий архітектурний дефект: агент, здатний редагувати файли, які визначають межі його власних повноважень. Це не унікальна проблема Kiro — подібні класи вразливостей виявлялися й в інших агентних середовищах розробки. Ключовий урок: механізм безпеки, який модель може обійти шляхом маніпуляції контекстом, не є механізмом безпеки. Контроль має бути реалізований на рівні платформи, поза досяжністю агента, й діяти в усіх режимах роботи без винятків.
