В Gogs обнаружили критическую zero-day уязвимость Gogs, которая позволяет получить удалённое выполнение кода на внешних Git-инстансах. Для русскоязычных команд, которые держат self-hosted Git у себя, новость неприятная по простой причине: при конфигурации по умолчанию атака упирается не в сложный взлом, а в обычную регистрацию нового пользователя.
Об инциденте сообщает BleepingComputer. По данным издания, проблема затрагивает актуальные версии Gogs 0.14.2 и 0.15.0+dev, пока не имеет CVE-идентификатора и остаётся без исправления. Уязвимость нашёл старший исследователь Rapid7 Джона Бёрджесс: он сообщил о ней разработчикам 17 марта 2026 года, 28 марта получил подтверждение, что отчёт принят, но к 28 мая патча так и не было.
Технически речь идёт об argument injection в процессе слияния через режим Rebase before merging. Сценарий выглядит так: атакующий регистрирует учётную запись, создаёт свой репозиторий, включает rebase-слияние в настройках и отправляет pull request с вредоносным именем ветки. Это имя подсовывает флаг --exec в команду git rebase, после чего сервер выполняет произвольный код от имени процесса Gogs. Админские права для этого не нужны.
Самый неприятный кусок истории в том, что exploit chain завязан не на экзотическую конфигурацию, а на дефолтные настройки. У Gogs по умолчанию открыта регистрация пользователей (DISABLE_REGISTRATION = false), а число создаваемых репозиториев не ограничено (MAX_CREATION_LIMIT = -1). То есть на публично доступном сервере злоумышленнику достаточно завести аккаунт и собственный репозиторий, чтобы пройти почти весь путь до RCE без участия других пользователей. Для self-hosted Git это уже не «теоретическая поверхность атаки», а очень практический сценарий.
Последствия у такой уязвимости вполне приземлённые и для разработчиков, и для бизнеса. Получив кодовое выполнение на сервере, атакующий может читать все репозитории на инстансе, включая чужие приватные проекты, вытаскивать хеши паролей, API-токены, SSH-ключи и секреты двухфакторной аутентификации, менять код в размещённых репозиториях и двигаться дальше по сети к другим доступным системам. Если на таком Gogs лежат внутренние библиотеки, CI-скрипты, инфраструктурный код или обвязка деплоя, история быстро превращается из «проблемы одного сервиса» в цепочку компрометации.
Отдельно настораживает не только сама ошибка, но и её родословная. Бёрджесс прямо сравнивает находку с несколькими прошлыми уязвимостями класса argument injection, которые в Gogs уже закрывали в последние годы: CVE-2024-39933, CVE-2024-39932, CVE-2026-26194 и CVE-2024-39930. По его словам, нынешняя дыра живёт в другом участке кода, в функции Merge(), который раньше не починили. Иными словами, проблема выглядит не как единичный промах, а как системный дефект в обработке аргументов Git-команд.
Масштаб потенциальной поверхности тоже не выглядит символическим. Shadowserver отслеживает более 2400 Gogs-серверов, доступных из интернета: 1894 из них находятся в Азии, ещё 319 в Европе. По данным Shodan, в сети видны чуть больше 1000 IP-адресов с отпечатком Gogs. Цифры отличаются, но вывод один: публичных инстансов достаточно много, и это не редкий софт, который забыли в лаборатории. Для небольших компаний, подрядчиков, аутсорс-команд и стартапов Gogs как раз и привлекателен своей простотой, лёгкостью и self-hosted-моделью. За это теперь, похоже, приходится доплачивать вниманием к настройкам безопасности.
Контекст у истории особенно неприятный, потому что это уже не первый тревожный звонок. В начале декабря команда Gogs закрыла другую RCE-уязвимость, CVE-2025-8110, которую эксплуатировали как zero-day и через которую скомпрометировали сотни серверов. Исследователи Wiz тогда тоже указывали на открытую регистрацию как на фактор, который резко расширяет поверхность атаки. Их отчёт отправили разработчикам 17 июля, подтверждение пришло только 30 октября, а патчи выпустили в начале января. Уже 12 января 2026 года CISA подтвердила, что CVE-2025-8110 эксплуатируется в реальных атаках, добавила её в каталог активно используемых уязвимостей и потребовала от федеральных гражданских агентств США закрыть проблему до 2 февраля.
Для инженеров и ИТ-руководителей отсюда следует довольно прозаичный вывод. Если Gogs у вас смотрит в интернет, считать «нужна аутентификация» достаточной защитой уже нельзя. При дефолтной конфигурации аутентификация фактически сводится к саморегистрации. Пока исправления нет, минимальный набор здравого смысла выглядит так: закрыть открытую регистрацию, ограничить создание репозиториев, выключить или жёстко контролировать сценарии rebase-слияния, увести интерфейс за VPN или SSO-шлюз и проверить, нет ли на сервере подозрительных pull request и необычных запусков Git-процессов. Это не серебряная пуля, но лучше, чем ждать следующего отчёта о «массовой эксплуатации в дикой природе».
История с Gogs всё хуже маскируется под случайность. Когда self-hosted Git-сервис второй раз за короткий промежуток времени приходит к RCE через похожий класс ошибок, вопрос уже не только в одном баге без патча, а в том, насколько команда сопровождения успевает за рисками продукта, который продолжает торчать в интернете у тысяч организаций.