ШІ-помічники для написання коду можуть бути скомпрометовані через шкідливий запис у .git/config, який експлуатує функцію Git core.fsmonitor. Це дозволяє ненадійному репозиторію виконувати команди на машині розробника в той самий момент, коли помічник сканує файли.

Ця вразливість виявилася в кількох популярних агентах — Claude Code, Cursor, OpenAI Codex, Goose, Qwen Code, Grok Build та Hermes. У виправлених агентах експлойт більше не працює; інші залишаються вразливими. Для атаки не потрібні додаткові кліки чи підтвердження, а шкідливий код виконується з привілеями самого користувача, поза межами будь-якої «пісочниці», яку може надавати ШІ-агент.

Як атака досягає розробника

  • Підрядник архівує проєкт і надсилає його електронною поштою.
  • Колега ділиться папкою на мережевому диску.
  • Передається USB-накопичувач із кодовою базою.

У кожному випадку репозиторій надходить у вигляді директорії, яка вже містить папку .git. Коли ШІ-помічник відкриває папку, він зазвичай запускає git status у фоновому режимі, щоб побудувати дерево файлів коду. Git прискорює цю операцію за допомогою налаштування core.fsmonitor, яке вказує Git викликати зовнішню програму для відстеження змін у файловій системі. Якщо файл .git/config репозиторію визначає шкідливу команду для core.fsmonitor, Git виконує її автоматично, не запитуючи користувача.

Оскільки команду запускає сам Git, вона успадковує права користувача та обходить будь-яку «пісочницю», яку міг налаштувати ШІ-інструмент. Експлойт не спрацьовує під час звичайних команд git clone, git fetch або git pull; він активується лише тоді, коли репозиторій розпаковується з уже наявними метаданими .git.

Чому це важливо

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

Як виявити отруєний репозиторій

Перед тим як передати репозиторій помічнику, виконайте:

git config --get core.fsmonitor

Якщо вивід не порожній, це означає, що програма налаштована на автоматичний запуск. Щоб провести ширшу перевірку, виведіть список будь-яких підозрілих налаштувань Git:

git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

Якщо ви помітите записи, які не додавали самі, видаліть їх за допомогою:

git config --local --unset core.fsmonitor

Зауважте, що встановлення git config --global core.fsmonitor false не захистить вас. Локальні налаштування репозиторію завжди мають пріоритет над глобальними, тому шкідливий репозиторій може просто ігнорувати глобальне правило.

Поточний стан виправлень

  • Claude Code – виправлено (fsmonitor)
  • Cursor – виправлено
  • OpenAI Codex – виправлено
  • Goose – виправлено
  • Qwen Code – не виправлено
  • Grok Build – не виправлено
  • Hermes – не виправлено

Розробникам, які використовують не виправлені агенти, слід ставитися до будь-якого отриманого репозиторію як до потенційно небезпечного, доки вони не змінять інструменти або не запровадять суворіші локальні політики Git.

Контраргумент спільноти Git

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

На що звернути увагу далі

  • Оновлення від не виправлених ШІ-агентів — особливо будь-які заяви щодо ізоляції (sandboxing) викликів Git.
  • Потенційні зміни в поведінці Git за замовчуванням щодо core.fsmonitor для ненадійних директорій.
  • Сторонні інструменти, які можуть очистити .git/config репозиторію перед тим, як він потрапить до помічника.

Висновок

Один рядок у прихованому конфігураційному файлі може перетворити зручність ШІ на вектор виконання віддаленого коду. Доки вразливі агенти не будуть виправлені, найбезпечнішою практикою є аудит кожного репозиторію, який надходить поза межами стандартного робочого процесу git clone, та видалення будь-яких хуків core.fsmonitor або подібних перед тим, як дозволити ШІ-помічнику працювати з кодом.