Популярный сервис для самостоятельного хостинга Git‑репозиториев Gogs, написанный на Go и используемый как легковесная альтернатива GitLab и GitHub Enterprise, оказался под прицелом масштабной кибератаки. Исследователи выявили нулевую уязвимость CVE-2025-8110, которая позволяет злоумышленникам добиться удалённого выполнения произвольного кода (RCE) и уже привела к компрометации сотен серверов по всему миру.
Критическая уязвимость Gogs: как работает CVE-2025-8110
Идентификатор CVE-2025-8110 присвоен новой критической уязвимости, связанной с path traversal (обходом ограничений на доступ к файловой системе) в API PutContents Gogs. Эта ошибка фактически обходит защитные механизмы, внедрённые ранее для закрытия другой проблемы удалённого выполнения кода – CVE-2024-55947.
Обход патча CVE-2024-55947 через симлинки
После устранения CVE-2024-55947 разработчики Gogs добавили проверки путей файлов, чтобы блокировать попытки directory traversal (переход за пределы допустимых каталогов). Однако, как показал анализ, эти проверки не учитывают символические ссылки (symlinks).
Злоумышленник может создать репозиторий, в котором определены симлинки на критически важные системные файлы за пределами каталога репозитория. Далее через API PutContents он передаёт содержимое для записи «внутри» репозитория, но фактически данные записываются по целевому пути симлинка — то есть в файл за пределами репозитория, к которому у сервера есть права записи.
Ключевой вектор атаки — перезапись конфигурационных файлов Git, в частности параметра sshCommand. Подменяя эту настройку, атакующий вынуждает систему выполнять произвольные команды при запуске определённых Git‑операций, тем самым получая полноценное удалённое выполнение кода на сервере.
Масштаб атаки на Gogs‑серверы и использование Supershell C2
Компрометация более 700 экземпляров Gogs
По данным специалистов компании Wiz, уязвимость CVE-2025-8110 была обнаружена в июле 2025 года при анализе вредоносной активности на одном из клиентских Gogs‑серверов. Дальнейшее сканирование интернета выявило более 1400 публично доступных экземпляров Gogs, причём свыше 700 серверов уже демонстрировали признаки компрометации.
Все взломанные инстансы имеют характерный артефакт: в них обнаружены репозитории со случайными восьмисимвольными названиями, созданные в узком временном окне (июль 2025 года). Такой единый паттерн указывает на то, что за кампанией, вероятнее всего, стоит один и тот же злоумышленник или организованная группа, активно использующая автоматизированные средства сканирования и эксплуатации.
Отдельно подчеркивается роль настройки Open Registration, которая во многих инсталляциях Gogs остаётся включённой по умолчанию. Это позволяет любому пользователю свободно зарегистрировать учётную запись, создать репозиторий и дальше эксплуатировать уязвимость без предварительного доступа к административным аккаунтам, резко увеличивая площадь атаки.
Malware на базе Supershell и инфраструктура управления
В ходе расследования эксперты Wiz установили, что вредоносное ПО, развёрнутое на скомпрометированных Gogs‑серверах, создано с использованием опенсорсного C2‑фреймворка Supershell. Этот инструмент позволяет разворачивать обратные SSH‑шеллы через веб‑сервисы и использовать их как удобный канал удалённого управления.
Анализ сетевого трафика показал, что установленная малварь связывается с управляющим сервером по адресу 119.45.176[.]196. Такая централизованная инфраструктура управления характерна для целевых и массовых кампаний, где атакующие стремятся удерживать длительный контроль над скомпрометированными системами и при необходимости разворачивать дополнительный набор инструментов.
Риски для организаций и практические рекомендации по защите Gogs
Что сделать администраторам Gogs прямо сейчас
Исследователи уведомили мейнтейнеров Gogs о CVE-2025-8110 17 июля 2025 года. 30 октября команда проекта подтвердила уязвимость и объявила о работе над патчем. Однако, согласно временной шкале Wiz, вторая волна атак началась уже 1 ноября 2025 года, то есть до выхода официального исправления. Это ставит администраторов перед задачей немедленного применения компенсирующих мер.
Рекомендуемые шаги для владельцев Gogs‑инсталляций:
1. Отключить Open Registration. Если публичная регистрация не является критичной для бизнес‑процессов, её следует немедленно выключить и перейти на модель учётных записей, создаваемых вручную или через проверенные SSO/LDAP‑механизмы.
2. Ограничить сетевой доступ. По возможности стоит закрыть публичный доступ к Gogs, оставив его только во внутренней сети, через VPN или Zero Trust‑решения. Публичный доступ к административным интерфейсам должен быть минимизирован.
3. Проверить признаки компрометации. Администраторам рекомендуется:
- проанализировать логи на предмет подозрительных запросов к API PutContents;
- поискать репозитории со случайными восьмисимвольными именами, созданными в аномально короткие интервалы времени;
- проверить конфигурационные файлы Git (в частности, параметры sshCommand) на наличие несанкционированных изменений;
- контролировать исходящие SSH‑подключения и HTTP(S)‑трафик к неизвестным адресам, включая 119.45.176[.]196.
4. Планировать обновление и проводитe регулярный аудит. После выхода официального патча крайне важно незамедлительно обновить Gogs до защищённой версии. Кроме того, регулярный аудит настроек (отключение ненужных функций по умолчанию, принцип наименьших привилегий, контроль доступа к репозиториям) остаётся одной из ключевых практик снижения риска.
Ситуация с CVE-2025-8110 демонстрирует, насколько опасными могут быть уязвимости в системах контроля версий, являющихся ядром процессов разработки и DevOps. Организациям, использующим Gogs или аналогичные self‑hosted решения, имеет смысл пересмотреть свою модель угроз, проанализировать открытые к интернету сервисы и внедрить базовые меры кибергигиены: жёсткую сегментацию сетей, минимизацию экспонированных сервисов, своевременное обновление и постоянный мониторинг аномальной активности. Чем раньше подобные механизмы будут встроены в ежедневную практику эксплуатации, тем ниже вероятность, что следующая кампания по эксплуатации нулевой уязвимости приведёт к устойчивому компрометированию инфраструктуры разработки.
