Критическая уязвимость в Gitea позволяет выполнить код через подмену Git-хуков в bare-клоне

Gitea устранила критическую уязвимость удалённого выполнения кода (CVE-2026-60004, CVSS 9.8), позволяющую пользователю с правами записи в репозиторий внедрить исполняемый Git-хук через API-эндпоинт diffpatch и выполнить произвольные команды от имени сервисной учётной записи Gitea. Уязвимость затрагивает все версии начиная с 1.17 до 1.27.1. Исправление доступно в версии 1.27.1. Публичный код эксплойта (PoC) уже доступен, хотя на момент публикации подтверждённых случаев эксплуатации в реальных атаках не зафиксировано. Всем администраторам self-hosted инсталляций Gitea необходимо обновиться немедленно.

Механизм эксплуатации

Уязвимый эндпоинт POST /api/v1/repos/{owner}/{repo}/diffpatch применяет пользовательский патч внутри общего bare временного клона репозитория. Согласно официальному advisory Gitea, уязвимые сборки вызывают git apply с флагами --index, --recount, --cached и --binary. При наличии Git версии 2.32 и выше дополнительно активируется флаг -3 (three-way merge fallback).

Атака строится на следующей цепочке:

1. Атакующий отправляет один и тот же патч дважды, создавая коллизию типа add/add.
2. Механизм three-way fallback извлекает проиндексированный путь в рабочее дерево, несмотря на использование --cached.
3. Поскольку временный клон является bare-репозиторием, его корневая директория совпадает с $GIT_DIR. Исполняемый файл, размещённый по пути hooks/post-index-change, попадает непосредственно в директорию хуков Git.
4. Git автоматически выполняет хук post-index-change при обновлении индекса — атакующий получает выполнение произвольного кода.

PoC демонстрирует полный цикл атаки без необходимости обратного соединения: хук сохраняет вывод команд в Git-объекты, создаёт ветку с результатом, и атакующий забирает данные через аутентифицированный Smart HTTP.

Условия эксплуатации и поверхность атаки

Формально эндпоинт требует аутентификации и прав записи в репозиторий — маршрут вызывает reqToken(), отклоняющий неавторизованные запросы. Однако конфигурация Gitea по умолчанию оставляет регистрацию открытой, не требует подтверждения email или ручного одобрения, не помечает новых пользователей как ограниченных и не устанавливает лимит на создание репозиториев. На неизменённой инсталляции внешний посетитель может самостоятельно зарегистрироваться, создать репозиторий и получить необходимые права записи.

Полный набор условий для эксплуатации:

• Права записи в репозиторий (достижимы через открытую регистрацию)
• Git версии 2.32 или выше на сервере
• Включённый маршрут diffpatch
• Записываемая и исполняемая временная файловая система

Последствия компрометации

Успешная эксплуатация предоставляет атакующему привилегии операционной системной учётной записи, под которой работает Gitea. Согласно advisory, в зависимости от степени изоляции инстанса это может привести к раскрытию:

• Секретов приложения и переменных окружения
• Смонтированных репозиториев
• Учётных данных и содержимого базы данных
• OAuth-токенов
• Доступных внутренних сервисов в сети

Учитывая, что Gitea часто развёртывается как центральный узел для хранения исходного кода организации, компрометация инстанса может стать точкой входа для атак на цепочку поставок.

Особенности раскрытия и исправления

Хронология событий заслуживает отдельного внимания. Исправление было смержено и бэкпортировано 26 июля 2026 года. Версия 1.27.1 вышла 27 июля, а security advisory опубликован 28 июля. При этом в release notes исправление указано в разделе MISC как «refactor: git patch apply», а не в разделе SECURITY. Такая маркировка может привести к тому, что администраторы, отслеживающие только секьюрити-фиксы, пропустят критическое обновление.

Суть исправления — изменение типа временного клона с bare на non-bare. Комментарий в коде коммита явно предупреждает, что команды Git с флагом --index могут оперировать рабочим деревом. В non-bare клоне корневая директория больше не совпадает с $GIT_DIR, что разрывает цепочку внедрения хука.

Уязвимость обнаружена исследователем безопасности Shai Rod (NightRang3r), который указан как автор находки в advisory Gitea. Помимо RCE, в версии 1.27.1 также исправлена проблема включения файлов в рендерере Org-mode: директивы #+INCLUDE теперь возвращаются как обычный текст вместо чтения файлов с серверной файловой системы. Отдельный advisory или CVE для этой проблемы Gitea не публиковала.

Рекомендации

• Немедленно обновите все self-hosted инсталляции Gitea до версии 1.27.1. По данным Gitea, облачные инстансы Gitea Cloud обновляются автоматически.
• Отключите открытую регистрацию как временную меру на период обновления. Это устраняет путь атаки для внешних неаутентифицированных пользователей, но не защищает от существующих пользователей с правами записи.
• Проверьте версию Git на сервере: эксплуатация требует Git 2.32+. Если по каким-то причинам обновление Gitea невозможно немедленно, понижение версии Git ниже 2.32 может служить временным обходным решением (с учётом возможных побочных эффектов).
• Проведите аудит логов на предмет подозрительных вызовов эндпоинта /api/v1/repos/{owner}/{repo}/diffpatch, особенно повторных запросов с идентичным содержимым патча.
• Проверьте изоляцию сервисной учётной записи Gitea: ограничьте доступ к секретам, базам данных и внутренним сервисам по принципу минимальных привилегий.

Сочетание CVSS 9.8, публичного PoC, открытой регистрации по умолчанию и неочевидной маркировки исправления в changelog делает CVE-2026-60004 одной из наиболее опасных уязвимостей в экосистеме self-hosted Git-платформ за последнее время. Единственное надёжное действие — обновление до Gitea 1.27.1 с последующей ревизией конфигурации регистрации и изоляции инстанса. Запись в NVD подтверждает критический уровень серьёзности уязвимости.