Критична RCE вразливість у Gogs: експлуатація через git rebase без офіційного патча

У Gogs — популярному рішенні для самостійного хостингу Git-репозиторіїв — виявлено критичну вразливість віддаленого виконання коду (RCE) з оцінкою CVSS 9.4, за даними дослідників Rapid7. Вразливість дає змогу будь-якому автентифікованому користувачу виконати довільні команди на сервері через створення pull request зі шкідливою назвою гілки. Патч на момент публікації відсутній, а публічний модуль Metasploit уже автоматизує повний ланцюжок експлуатації. Адміністраторам інстансів Gogs необхідно негайно застосувати обхідні заходи захисту — вимкнути реєстрацію, обмежити створення репозиторіїв і провести аудит налаштувань rebase перед злиттям.

Механізм експлуатації: інʼєкція аргументів у git rebase

Суть вразливості полягає в недостатній санітизації назв гілок під час виконання операції «Rebase before merging». Як повідомляє дослідник Джона Берджесс із Rapid7, зловмисник створює pull request із назвою гілки, що містить прапорець --exec, який інʼєктується в команду git rebase. Згідно з офіційною документацією Git, параметр --exec приймає довільну shell-команду, яка виконується після застосування кожного коміту в процесі rebase.

Ключова особливість вразливості — вкрай низький поріг входу для зловмисника. За даними дослідників, для експлуатації не потрібні привілеї адміністратора й взаємодія з іншими користувачами. На інстансі Gogs з конфігурацією за замовчуванням ланцюжок атаки виглядає так:

• Зловмисник реєструє обліковий запис на цільовому інстансі
• Створює власний репозиторій (автор автоматично стає власником)
• Умикає опцію rebase перед злиттям — це єдиний перемикач у налаштуваннях
• Створює pull request зі шкідливою назвою гілки, що містить інʼєкцію --exec
• Під час виконання rebase перед злиттям довільна команда виконується на сервері

В альтернативному сценарії, якщо створення репозиторіїв обмежено, зловмиснику достатньо мати доступ на запис до будь-якого репозиторію, у якому вже увімкнено rebase перед злиттям. Вразливість, як повідомляється, зачіпає всі підтримувані платформи: Windows, Linux і macOS.

Відсутність патча та доступність експлойта

За даними Rapid7, про вразливість було повідомлено мейнтейнеру проєкту 17 березня 2026 року, однак на момент розкриття інформації виправлення відсутнє. Вразливості не присвоєно ідентифікатор CVE, що ускладнює її відстеження через стандартні бази даних. Оцінка CVSS 9.4 надана Rapid7 і не підтверджена вендором або NVD.

Ситуацію погіршує наявність публічного модуля Metasploit, який автоматизує весь ланцюжок експлуатації для Linux і Windows. Модуль підтримує два режими роботи:

• Режим за замовчуванням: створюється тимчасовий репозиторій під обліковим записом зловмисника, виконується експлойт, репозиторій видаляється. Єдиний слід — запис HTTP 500 у серверних логах.
• Цільовий режим: експлуатація наявного репозиторію, до якого зловмисник має доступ на запис і злиття. У цьому разі залишається більше артефактів.

Мінімальний слід у логах під час використання першого режиму значно ускладнює виявлення атаки для команд реагування на інциденти.

Оцінка впливу

Успішна експлуатація вразливості, за даними дослідників, може призвести до таких наслідків:

• Повна компрометація сервера з доступом до всіх репозиторіїв на інстансі
• Отримання облікових даних і секретів із сховищ
• Латеральне переміщення до інших систем, доступних у мережі
• Модифікація коду в будь-якому розміщеному репозиторії — потенційний вектор атаки на ланцюг постачання
• Міжкористувацький витік даних: читання приватних репозиторіїв інших користувачів на тому ж сервері

Останній пункт особливо критичний для організацій, які використовують спільний інстанс Gogs для кількох команд або проєктів. Компрометація одного облікового запису з мінімальними привілеями потенційно відкриває весь масив розміщеного коду.

Рекомендації щодо захисту

За відсутності офіційного патча необхідно негайно застосувати такі заходи:

• Вимкнути відкриту реєстрацію: встановити DISABLE_REGISTRATION = true у файлі app.ini, щоб запобігти створенню облікових записів недовіреними користувачами
• Обмежити створення репозиторіїв: встановити MAX_CREATION_LIMIT = 0 у app.ini, щоб користувачі не могли самостійно створювати репозиторії
• Провести аудит налаштувань rebase перед злиттям: перевірити всі репозиторії на наявність увімкненої опції «Rebase before merging» і вимкнути її там, де вона не є необхідною
• Перевірити серверні логи: звернути увагу на записи HTTP 500, які можуть свідчити про спроби експлуатації
• Розглянути міграцію: для організацій із високими вимогами до безпеки — оцінити перехід на активно підтримувані альтернативи, такі як Gitea (форк Gogs із більш активним циклом оновлень безпеки)

Поєднання відсутності патча, публічно доступного модуля Metasploit і низького порога експлуатації створює період підвищеного ризику для всіх інстансів Gogs. Пріоритетна дія — вимкнення реєстрації та rebase перед злиттям на всіх інстансах, доступних з інтернету або з недовірених сегментів мережі, до виходу офіційного виправлення від мейнтейнера проєкту.