GhostCommit: як шкідливе зображення обманює ШІ-асистентів | CyberCalm

Наталя Зарудня

ByНаталя ЗарудняГоловний редакторГоловний редактор та засновниця CyberCalm. Понад 10 років у кібербезпеці та технологічній журналістиці. Пишу про захист даних, мобільну безпеку, штучний інтелект та соціальні мережі.Follow: 13.07.2026 Поширити 5 хв. читання

Команда дослідників з ASSET Research Group (Університет Міссурі-Канзас-Сіті) продемонструвала атаку GhostCommit, яка перетворює звичайне зображення на канал витоку конфіденційних даних. Шкідлива інструкція ховається не в рядках коду, а всередині PNG-файлу — і більшість інструментів автоматичного ревʼю коду її навіть не «бачать».

Зміст

Найнебезпечніший файл — той, який ніхто не відкриває
Справа не лише в тому, який ШІ ви обрали
Рішення існує — рецензент має «відкривати» зображення

ШІ-асистенти для програмування стали повсякденним інструментом розробників: вони переглядають код, пояснюють складні функції й пишуть цілі модулі за одним запитом. Але саме ця зростаюча довіра, як показують дослідники, може обернутися головною вразливістю.

Атака, яку автори назвали GhostCommit, не націлена безпосередньо на мовну модель. Вона експлуатує те, на що ШІ не звертає достатньо уваги під час перевірки коду. Замість того щоб ховати шкідливі команди в тексті програми, дослідники розмістили їх усередині файлу зображення. Оскільки багато інструментів ревʼю сприймають зображення як декоративний елемент, а не як обʼєкт для перевірки, pull request (запит на злиття коду) виглядає цілком безпечним і безперешкодно проходить рецензування.

Найнебезпечніший файл — той, який ніхто не відкриває

Уявіть документ із логотипом компанії в кутку. Найімовірніше, ви ковзнете поглядом і забудете про нього. А тепер уявіть, що цей логотип містить прихований наказ: наступного разу, коли ви скористаєтеся ШІ-асистентом, відкрити сховище паролів. Приблизно на цій ідеї й побудований GhostCommit.

Механізм такий. Pull request додає у проєкт файл угоди для ШІ-агентів — AGENTS.md, який агенти зчитують автоматично й сприймають як політику проєкту. Сам цей файл не називає жодного секрету й не містить підозрілих команд — він лише вказує на зображення build-spec.png. Уся небезпечна процедура «намальована» всередині картинки: прочитати файл .env, перетворити кожен байт на його ASCII-код і записати результат у код як звичайну на вигляд константу.

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

Особливо тривожить те, що викрадені дані не потрапляють у код в очевидному вигляді. Вони маскуються під звичайні числові значення, які зливаються з легітимним кодом, — тож наявні засоби безпеки навряд чи спрацюють, а розробник під час швидкого перегляду нічого не помітить.

Проблема має системне підґрунтя. За даними дослідників, з 6480 pull request у 300 найактивніших публічних репозиторіях за останні девʼяносто днів 73% злитих потрапили в основну гілку без жодного змістовного ревʼю — ні людського, ні автоматичного.

Справа не лише в тому, який ШІ ви обрали

Дослідники також зʼясували, що результат визначала не мовна модель. Одна й та сама модель поводилася по-різному залежно від того, яка «оболонка» (асистент програмування) її обгортала. Одні інструменти сліпо виконували приховані інструкції, інші розпізнавали загрозу й відмовлялися продовжувати. Це важлива відмінність: вона свідчить, що проблема не обмежується якимось конкретним чат-ботом.

Показовий результат: у тестах (по десять запусків на кожну пару) асистенти Cursor і Antigravity зливали весь вміст .env, тоді як Claude Code відмовлявся це робити — причому на кожній моделі, яку він запускає. Ті самі ваги моделі Sonnet 4.6 давали протилежний результат під Cursor і під Claude Code. Отже, вирішальним чинником є не сама модель, а оболонка та вбудовані в неї захисні механізми.

Рішення існує — рецензент має «відкривати» зображення

Хороша новина: дослідники не вважають проблему нерозвʼязною. Вони наполягають, що інструменти ревʼю мають стати по-справжньому мультимодальними — перевіряти зображення, документацію, конфігураційні файли та інші некодові обʼєкти з тією самою прискіпливістю, що й вихідний код. Якщо ШІ здатен прочитати картинку, він має розуміти, що ця картинка може намагатися ним маніпулювати.

Як доказ, команда побудувала власний мультимодальний «рецензент» — GitHub-застосунок, що працює навіть на одній відеокарті з 4 ГБ памʼяті. У бойовому тесті проти 80 реальних pull request він виявив 49 із 50 атак, зокрема всі варіанти з каналом-зображенням, і не дав жодного хибного спрацювання на 30 безпечних запитах. Код проєкту з підтвердженням концепції опубліковано у відкритому доступі.

Для розробників це ще одне нагадування: ШІ-інструменти для програмування все ще потребують нагляду. Вони здатні кардинально пришвидшити розробку, але водночас відкривають цілком нові вектори атак, яких раніше не існувало. Наступна загроза може ховатися не в тисячах рядків коду, а всередині зображення, яке нікому не спало на думку відкрити.

Будь ласка, залиште це поле порожнім

О, привіт
Приємно познайомитися!

Ми не розсилаємо спам! Ознайомтеся з нашою політикою конфіденційності для отримання додаткової інформації.

Перевірте свою поштову скриньку або папку зі спамом, щоб підтвердити підписку.

ТЕМИ:Claude Codeпромпт-ін’єкціяШІ-агентшкідливе ПЗШтучний Інтелект Поділитися Facebook Threads Копіювати посилання Друк Що думаєте? В захваті0Сумно0Смішно0Палає0Овва!0 Попередня стаття