Уязвимость Gogs с оценкой 9,4 из 10 уже больше двух месяцев остается без официального исправления, хотя публичный модуль эксплуатации для нее уже появился. Для компаний, которые держат собственный Git-сервис внутри контура, это не очередная абстрактная CVE-история, а риск полного захвата сервера, кражи учетных данных и незаметных правок в кодовых репозиториях.
О проблеме, как пишет The Register, сообщил исследователь Rapid7 Джона Бёрджесс. По его данным, баг был отправлен сопровождающим Gogs 17 марта 2026 года через GitHub Security Advisory, а 28 марта команда проекта подтвердила получение сообщения. Дальше наступила тишина: по словам Бёрджесса, на запросы о статусе, напоминания о сроках раскрытия и предложение продлить дедлайн на выпуск патча никто не ответил.
Сценарий атаки особенно неприятен тем, что для эксплуатации не нужны права администратора платформы. Достаточно обычной авторизованной учетной записи в дефолтной установке Gogs. Если владелец или администратор репозитория включил опцию Rebase before merging, атакующий может открыть pull request и подставить специально сформированное имя базовой ветки. Дальше срабатывает старая добрая инженерная халатность: имя ветки попадает в команду git rebase без разделителя --, который должен отсекать пользовательский ввод от опций командной строки. В результате Git воспринимает имя ветки не как имя ветки, а как параметр вроде --exec и исполняет полезную нагрузку на сервере.
Именно поэтому история выглядит хуже, чем «еще один баг в self-hosted Git». Речь идет не просто о сбое или обходе ограничений. При успешной атаке злоумышленник может выполнить произвольный код на уязвимом сервере, украсть логины, пароли и секреты многофакторной аутентификации, а затем уже двигаться дальше по инфраструктуре. Отдельный неприятный бонус: если на Gogs хранятся внутренние или клиентские проекты, появляется окно для supply-chain-атаки через незаметное изменение кода в репозиториях. Для DevOps и security-команд это тот случай, когда проблема в сервисе разработки быстро превращается в проблему всей компании.
Rapid7 уточняет, что баг затрагивает все поддерживаемые платформы и способы установки: Windows, Linux и macOS. Для Windows, по словам Бёрджесса, схема доставки нагрузки немного отличается, поэтому он подготовил модуль, который автоматизирует кроссплатформенную эксплуатацию. Появление такого модуля обычно меняет тон разговора. Пока уязвимость живет только в advisory и переписке исследователя с вендором, многие организации откладывают реакцию. Когда под нее выходит готовый инструмент, порог входа для атакующих заметно снижается. Не нужно быть исследователем, который вручную собирает цепочку эксплуатации, достаточно открыть документацию к модулю и иметь доступ к целевой инсталляции.
На момент публикации The Register Бёрджесс говорил, что подтверждений атак «в дикой природе» у Rapid7 нет. Но это слабое утешение. Между «эксплуатации не видим» и «эксплуатации нет» разница примерно как между выключенной камерой и пустой комнатой. Особенно если речь о self-hosted-сервисах, которые часто стоят в закрытых контурах, не светятся в публичных телеметриях и обслуживаются маленькими внутренними командами без круглосуточного мониторинга. Иными словами, отсутствие сигналов пока не повод считать риск теоретическим.
Отдельный сюжет здесь — поведение мейнтейнеров. По словам исследователя, команда Gogs после первичного подтверждения отчета перестала отвечать, а официальный патч так и не появился. Более того, Rapid7 в день публикации материала сама отправила pull request с предложенным исправлением, и он еще ожидал рассмотрения. Для open-source это, увы, уже знакомая развилка: проект может быть популярным и полезным, но его модель сопровождения не выдерживает темп, когда дело доходит до критических security-багов. Спонсор проекта, DigitalOcean, тоже не ответил на запросы издания о сроках выхода исправления.
Практический вывод для команд, у которых Gogs еще работает в проде, довольно приземленный. Первый шаг — закрыть свободную регистрацию пользователей через параметр DISABLE_REGISTRATION = true в app.ini, чтобы исключить самый очевидный путь для злоумышленника. Второй — ограничить создание репозиториев через MAX_CREATION_LIMIT = 0. Это перекрывает наиболее простой сценарий, когда атакующий заводит собственный репозиторий и включает нужные настройки слияния. Но здесь есть важная оговорка: такая мера не спасает, если у пользователя уже есть права записи в существующий репозиторий.
Третий шаг — проверить настройки merge-политик и отключить Rebase before merging в разделе Settings > Advanced. И это тоже не серебряная пуля. Бёрджесс отдельно предупреждает: если злоумышленник владеет репозиторием или имеет в нем админские права, он может снова включить rebase и вернуться к эксплуатации. Глобальной или организационной настройки, которая централизованно запрещала бы такой режим, в Gogs сейчас нет. Для бизнеса это означает неприятную необходимость: пока патча нет, безопасность зависит не только от конфигурации сервера, но и от дисциплины управления правами на уровне конкретных репозиториев.
Для русскоязычной аудитории новость важна еще и потому, что self-hosted Git-сервисы часто выбирают именно ради контроля над кодом, доступами и соответствием внутренним требованиям безопасности. История с Gogs показывает неочевидную сторону такого выбора: контроль над инфраструктурой не равен зрелому процессу реагирования на уязвимости у самого продукта. Если сервис тянут небольшие команды сопровождения, критическая дыра может провисеть месяцами, а затем получить готовый exploit раньше, чем официальный фикс. И тогда вопрос уже не в том, удобен ли ваш Git в повседневной работе, а в том, готовы ли вы быстро ограничить функции, пересмотреть права и, возможно, ускорить миграцию на платформу с более предсказуемым security-процессом. Подробности первичной публикации собраны в материале .