AWS виправила вразливість Kiro IDE, через яку приховані інструкції на завантаженій вебсторінці могли перетворитися на код, запущений на комп’ютері розробника. Спільне дослідження Kodem Security та Intezer показало: Kiro міг змінити власний файл ~/.kiro/settings/mcp.json і автоматично запустити визначений зловмисником MCP-сервер без окремого підтвердження зміни файлу чи команди.
Дослідники опублікували матеріал 19 липня 2026 року. Вони підтвердили проблему в Kiro IDE 0.9.2 на macOS і 0.10.16 на Ubuntu, а також перевірили, що версія 0.11.130 містить виправлення. AWS не присвоїла цій проблемі CVE. У звіті описано контрольовану демонстрацію, а не відому кампанію проти користувачів Kiro.
Кому потрібно діяти
| Запитання | Перевірена відповідь |
|---|---|
| Які збірки були вразливими в тестах? | Kiro IDE 0.9.2 і 0.10.16. Це не доводить, що кожна проміжна версія поводилася однаково. |
| Яка збірка точно виправлена? | 0.11.130. Встановіть найновішу доступну версію Kiro, а не лише цю збірку. |
| Що запускало ланцюжок? | Kiro обробляв контрольований атакувальником текст із web fetch, результату пошуку, документації або іншого зовнішнього джерела. |
| Що могло виконатися? | Команда MCP-сервера з правами поточного користувача. |
| Чи бачили реальні атаки? | Публічних даних про експлуатацію в реальних атаках немає. Дослідники використали локальний callback у контрольованому тесті. |
Найризикованішим був сценарій, коли користувач просив стару версію Kiro завантажити або стисло викласти незнайому документацію. Розробникам, які зберігають токени репозиторіїв, облікові дані реєстрів пакетів, хмарні профілі, ключі підпису чи доступ до production у тому самому середовищі, слід вважати незрозумілий MCP-запис можливою ознакою витоку облікових даних.
Як зламалася межа підтвердження
Kiro використовує MCP-конфігурації, щоб визначати зовнішні інструменти та команди їх запуску. В офіційній документації зазначено, що IDE стежить за глобальними й робочими файлами mcp.json та узгоджує запущені сервери після їх зміни.
- Користувач просив Kiro завантажити сторінку або знайти зовнішню інформацію.
- Отримана сторінка містила інструкції, приховані від людини, наприклад білий текст розміром в один піксель.
- Kiro сприймав цей текст як інструкцію й через можливість запису файлів змінював
~/.kiro/settings/mcp.json. - Спостерігач конфігурації перечитував файл і запускав новий MCP-сервер.
- Команда сервера виконувалася з правами облікового запису розробника.
У демонстрації користувач усе ж підтверджував завантаження незнайомої URL-адреси. Небезпечна прогалина з’являлася далі: Kiro не вимагав окремого змістовного підтвердження для зміни конфігурації та наступної команди. Proof of concept був недетермінованим, але під час тестів спрацьовував за одну-дві спроби.
Ця проблема межі довіри відрізняється від недавньої вразливості Cursor, що могла запустити git.exe під час відкриття репозиторію. В обох випадках звичайна дія розробника не повинна непомітно ставати виконанням коду на хості. Схожий ширший ризик створює отруєння AI-конфігурацій у екосистемах розробки.
Що перевірити користувачам Kiro
- Оновіть Kiro до найновішої версії та перезапустіть IDE. Версія 0.11.130 — перша збірка, яку дослідники прямо підтвердили як виправлену.
- Закрийте Kiro перед перевіркою MCP-конфігурації. Збережіть копію неочікуваних файлів і зафіксуйте час їх зміни до будь-якого редагування.
- Перегляньте глобальні та робочі MCP-файли. Перевірте
~/.kiro/settings/mcp.jsonі.kiro/settings/mcp.jsonу кожному проєкті. Якщо використовуєте власні агенти, перегляньте також їхні конфігурації. - Підтвердьте кожен запис сервера. Шукайте невідомі назви, вбудовані команди Node.js або shell, незнайомі URL, неочікувані виклики
curl,bash,npx,uvxчи завантажених скриптів. - Зіставте час, процеси та мережеву активність. Порівняйте зміни конфігурації зі сторінками, які завантажував Kiro. Перевірте невідомі дочірні процеси, вихідні з’єднання, механізми закріплення та зміни репозиторіїв.
- Якщо невідома команда виконалася, ізолюйте комп’ютер. Із чистого пристрою відкличте токени GitHub, реєстрів пакетів, хмарних сервісів, CI/CD та інших developer-систем. Замініть відкриті ключі, завершіть сесії й перевірте репозиторії та журнали збірок.
Оновлення закриває описаний шлях, але не видаляє вже запущений payload і не повертає секрет, який залишив комп’ютер. Не видаляйте незрозумілий запис із думкою, що на цьому інцидент завершено.
Чого ця вразливість не означає
Це не був пасивний browser zero-click: просте відкриття сторінки у звичайному браузері не є продемонстрованим тригером. Kiro мав отримати контрольований атакувальником вміст через роботу агента. Web fetch також не гарантував компрометацію, адже поведінка моделі була недетермінованою.
Дослідження не доводить активну експлуатацію, а проблема не має CVE. Ці межі важливі, однак точний файл довіри все одно варто перевірити: успішна спроба могла запустити будь-яку команду, доступну поточному користувачу.
FAQ
Чи безпечний Kiro після оновлення?
Дослідники підтвердили виправлення у Kiro IDE 0.11.130. Встановіть найновішу версію. Якщо стара збірка обробляла недовірений вебвміст, усе одно перевірте MCP-конфігурації та облікові дані, бо оновлення не скасовує попереднє виконання коду.
Чи треба видалити всі MCP-сервери?
Ні. MCP-сервери можуть бути легітимними інструментами розробника. Перевірте команду, аргументи, джерело й власника кожного запису; збережіть докази та вимкніть лише ті записи, походження яких не можете пояснити.
