Легковажне ставлення до захисту систем контролю версій перетворюється на критичний ризик: популярний self-hosted сервіс для Git‑репозиторіїв Gogs, написаний мовою Go та позиціонований як компактна альтернатива GitLab і GitHub Enterprise, опинився в центрі масштабної кампанії атак. Нова вразливість CVE-2025-8110 дозволяє remote code execution (RCE) і вже використана для компрометації сотень інсталяцій у різних країнах.
Вразливість Gogs CVE-2025-8110: path traversal в API PutContents
Ідентифікатор CVE-2025-8110 отримала критична вразливість, пов’язана з path traversal у API PutContents. Цей API використовується для запису вмісту файлів у репозиторій через HTTP‑запит. Помилка фактично дозволяє обійти захист, доданий раніше для закриття іншої RCE‑проблеми — CVE-2024-55947.
Після виправлення CVE-2024-55947 розробники Gogs посилили перевірку шляхів файлів, щоб блокувати класичний directory traversal — спроби вийти за межі дозволеного каталогу за допомогою конструкцій на кшталт «../». Однак ці перевірки виявилися недостатніми: вони не враховують символьні посилання (symlinks), які можуть вказувати на файли за межами репозиторію.
Обхід перевірок через symlink і перезапис sshCommand
Зловмисник може створити репозиторій у Gogs, де один із файлів насправді є symlink на критичний системний або конфігураційний файл поза межами репозиторію. Далі, використовуючи API PutContents, він надсилає нібито легітимний запит на оновлення файлу в репозиторії. На практиці ж сервер слідує symlink і перезаписує , до якого має права запису.
Найнебезпечніший сценарій — перезапис конфігурацій Git, зокрема параметра sshCommand. Через модифікацію цього параметра атакувальник може змусити Git виконувати довільні команди під час окремих операцій (наприклад, при роботі з віддаленими репозиторіями), що забезпечує повноцінне віддалене виконання коду (RCE) на сервері Gogs.
Масштаб атак на Gogs: понад 700 скомпрометованих інстансів
Сканування інтернету та характерні артефакти зламу
За даними дослідників компанії Wiz, CVE-2025-8110 було виявлено в липні 2025 року під час аналізу підозрілої активності на одному з клієнтських серверів Gogs. Подальше сканування відкритих хостів показало більш як 1400 публічно доступних інсталяцій Gogs, з яких понад 700 мали ознаки компрометації.
У скомпрометованих інстансах фіксується спільний патерн: наявність репозиторіїв із випадковими восьмисимвольними назвами, створених у дуже вузькому часовому вікні (липень 2025 року). Така уніфікована ознака свідчить про використання автоматизованих інструментів сканування й експлуатації та вказує на єдину групу або координовану кампанію.
Значну роль у масштабуванні атаки відіграє налаштування Open Registration, яке в багатьох розгортаннях Gogs залишається увімкненим за замовчуванням. Відкритий режим реєстрації дозволяє будь-кому створити обліковий запис, ініціювати репозиторій і надалі експлуатувати вразливість без доступу до адміністративних облікових записів, суттєво розширюючи площу атаки.
Malware на базі Supershell C2 та інфраструктура керування
Під час розслідування експерти Wiz встановили, що шкідливе ПЗ на скомпрометованих Gogs‑серверах побудоване з використанням опенсорсного C2‑фреймворку Supershell. Цей інструмент дозволяє розгортати зворотні SSH‑shell через веб‑сервіси й використовувати їх як зручний канал дистанційного адміністрування.
Аналіз мережевого трафіку показав, що встановлена малварь під’єднується до керівного сервера за адресою 119.45.176[.]196. Централізована command-and-control (C2)‑інфраструктура характерна для кампаній, де зловмисники прагнуть утримувати тривалий доступ до скомпрометованих систем, розгортати додаткові інструменти та здійснювати приховане переміщення всередині мережі.
Ризики для організацій і практичні кроки із захисту Gogs
Таймлайн CVE-2025-8110 та чому важливі компенсуючі заходи
Про вразливість CVE-2025-8110 мейнтейнерів Gogs повідомили 17 липня 2025 року. 30 жовтня команда офіційно підтвердила проблему й оголосила про роботу над оновленням. Водночас за даними Wiz, друга хвиля атак стартувала вже 1 листопада 2025 року, тобто до виходу патча. Це типова ситуація «вікна ураженості», коли відомий дефект активно експлуатується раніше, ніж більшість організацій встигають оновитися.
Рекомендації адміністраторам Gogs
Щоб мінімізувати ризики експлуатації вразливості Gogs, власникам інсталяцій доцільно виконати такі дії:
- Вимкнути Open Registration, якщо відкритий прийом реєстрацій не є критичною бізнес‑вимогою. Перейти на модель створення акаунтів вручну, через SSO або LDAP з контрольованою видачею доступів.
- Обмежити мережевий доступ: по можливості перевести Gogs у внутрішній контур, на доступ через VPN або Zero Trust‑рішення. Публічний доступ до адміністративних інтерфейсів має бути максимально звуженим.
- Перевірити ознаки компрометації, зокрема:
- логи на предмет нетипових запитів до API PutContents;
- репозиторії з випадковими восьмисимвольними назвами, створеними в аномально короткі періоди;
- конфігураційні файли Git (особливо параметр sshCommand) на предмет несанкціонованих змін;
- вихідні SSH- та HTTP(S)‑підключення до невідомих адрес, включно з 119.45.176[.]196.
- Планувати оновлення та регулярний аудит: після виходу офіційного патча оперативно оновити Gogs до захищеної версії, впровадити регулярний аудит налаштувань, дотримання принципу найменших привілеїв і обмеження доступу до репозиторіїв.
Інцидент із CVE-2025-8110 показує, наскільки руйнівними можуть бути помилки в системах контролю версій, що лежать в основі DevOps‑процесів. Організаціям, які використовують Gogs або інші self-hosted Git‑рішення, варто переглянути модель загроз, мінімізувати кількість сервісів, відкритих в інтернет, посилити сегментацію мережі, впровадити своєчасне оновлення та постійний моніторинг аномальної активності. Чим раніше такі практики стануть частиною повсякденної експлуатації, тим менша ймовірність, що наступна нульова вразливість уразить серце інфраструктури розробки.
