ШІ-помічники для програмування, такі як Claude Code, Cursor та Grok Build, можуть виконувати довільні команди в той самий момент, коли розробник відкриває недовірений репозиторій, без будь-яких кліків чи запитів. Помилка виникає через те, як ці інструменти використовують функцію Git core.fsmonitor для сканування файлів проєкту.

Чому це важливо саме зараз

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

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

Як відбувається атака

  1. Підготовка – Зловмисник створює репозиторій, у .git/config якого є рядок на кшталт core.fsmonitor = /path/to/malicious/script.
  2. Доставка – Репозиторій передається у вигляді zip-архіву, копіюється з USB-накопичувача, синхронізується через спільний диск або іншим чином розміщується на машині жертви з уже наявною папкою .git.
  3. Спрацювання – Розробник відкриває папку в IDE з підтримкою ШІ. Помічник запускає git status, щоб зібрати контекст. Git зчитує локальну конфігурацію, виконує команду core.fsmonitor, і шкідливий скрипт запускається негайно.

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

Що під загрозою

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

Оскільки шкідлива команда успадковує права користувача, вона може змінити будь-який файл, до якого має доступ розробник, включаючи SSH-ключі, скрипти збірки або облікові дані для розгортання.

Кроки для захисту, які розробники можуть зробити вже сьогодні

  • Не довіряйте локальним налаштуванням Git. Конфігурація репозиторію перезаписує глобальні значення щоразу, коли ШІ-помічник робить запит до проєкту.

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

    git config --get core.fsmonitor

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

  • Видаліть запис за допомогою: 

    git config --local --unset core.fsmonitor

  • Перевірте інші ризиковані ключі, які Git може виконувати: hooksPath, sshCommand, pager, editor, filter. Використовуйте той самий шаблон git config --get, щоб переконатися, що вони порожні.

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

Хто несе відповідальність

Вразливість не є помилкою в мовних моделях, які забезпечують роботу Claude Code, Cursor або Grok Build; це наслідок того, як ці інструменти збирають інформацію про файли. Деякі постачальники почали суворіше ізолювати (sandbox) виклики Git, але поведінка за замовчуванням все ще довіряє локальним налаштуванням репозиторію. Доки галузь не прийме стандарт, який видаляє або ігнорує потенційно небезпечні записи конфігурації під час сканування робочого простору ШІ-агентом, розробники мають залишатися останнім рубежем оборони.

За чим варто стежити далі

  • Оновлення інструментів, які явно очищують конфігурацію Git перед викликом git status.
  • Рекомендації спільноти щодо безпечної розробки за допомогою ШІ, які, ймовірно, включатимуть рекомендовані попередні перевірки.
  • Дослідження безпеки, які можуть виявити додаткові ключі конфігурації Git, здатні до виконання коду, розширюючи контрольний список за межі п'яти виділених вище.

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