Прихований git hook у фальшивому проєкті запускав код на комп'ютері розробника

Фальшиве замовлення і прихований .git

Засновник компанії розробки REVSYS і член Django Steering Council Френк Уайлс (Frank Wiles) 2 жовтня 2026 року опублікував у блозі історію про цілеспрямовану атаку на себе. Все почалося зі звичайного замовлення: незнайомець зв'язався й зацікавився, чи доступна його команда для роботи над вебдодатком у сфері Ed Tech. Уайлс запропонував зустріч.

«Клієнт» попросив ознайомитися з описом проєкту та підписати NDA перед зустріччю, а потім поділився папкою в Dropbox, де знаходилися Markdown-файли та нечітка, але переконлива специфікація. Уайлс одразу не помітив, що там також була прихована директорія .git.

«Гілка NDA» і post-checkout hook

Коли Уайлс не зміг знайти NDA і попросив надіслати її електронною поштою, він отримав відповідь: документ зберігається в «гілці NDA» і достатньо перемкнутися на неї, заповнити та повернути перед зустріччю. Саме тоді він зрозумів, що проєкт несправжній. У папці .git/hooks він виявив серед стандартних .example hook-файлів один справжній post-checkout hook.

Такі hook-файли на практиці майже ніхто не використовує, тому Уайлс обережно його відкрив. Hook використовував додаток Vercel як канал керування: при перемиканні гілок завантажував бінарний файл для конкретної операційної системи, робив його виконуваним, запускав і потім самознищувався. Git post-checkout hook виконується автоматично при перемиканні гілок, тому виконання звичайної інструкції щодо переходу на «гілку NDA» означало запуск чужого коду на комп'ютері розробника.

Уайлс одразу повідомив служби безпеки Dropbox та Vercel, щоб ті заблокували акаунти до того, як шахраї знайшли інші жертви. За його словами, шахраї також використовували ім'я власника невідомої компанії-розробника. Сам Уайлс не постраждав.

Чому це небезпечно для розробників

Hook-файли — звичайна частина git, але вони виконуються автоматично, без додаткового підтвердження. Папка .git легко залишається непоміченою, оскільки багато інструментів не показують її у списку файлів. Достатньо, щоб стороння людина надіслала репозиторій і перемкнула гілку, щоб шкідливий код з'явився на комп'ютері розробника. Мета ж цінна: акаунти GitHub, ключі SSH, токени API та доступ до систем клієнтів.

Уайлс закликає колег з обережністю ставитися до сторонніх «ідеальних замовлень», які вимагають конкретних кроків із репозиторієм, перевіряти hook-файли перед запуском коду та використовувати ізольоване середовище.