CVE-2026-52813 — Обход пути в Gogs приводит к удалённому выполнению кода через Git Hooks (анализ для защиты)

Исследование безопасности / writeup для синей команды. Этот репозиторий не содержит weaponized PoC. Исследователям, которым нужно воспроизведение, следует использовать публичный PoC, указанный в официальном advisory.

TL;DR

При создании организации Gogs Web-форма выполняет проверку символов AlphaDashDot и блокирует /, но REST API POST /api/v1/user/orgs — нет. Атакующий отправляет через API имя организации с ../, обходит проверку и попадает прямо в os.MkdirAll(repoutil.UserPath(org.Name), 0777) (internal/database/org.go:165), записывая каталог репозитория в произвольный путь файловой системы. В сочетании с временным рабочим деревом веб-редактора Gogs (local-r/<repo_id>/) это позволяет разместить вредоносный hooks/update в локальном checkout другого репозитория, который автоматически выполняется git → RCE под пользователем git.

Затронутые версии и меры

Обновление — единственное полное исправление:

# Docker
docker pull gogs/gogs:0.14.3
# 或源码
git checkout v0.14.3 && go build

Временные меры (если обновление невозможно):

• Отключите открытую регистрацию (app.ini → [service] DISABLE_REGISTRATION = true), чтобы снизить предварительное условие с «неавторизованно» до «нужна существующая учётная запись»;
• Добавьте на уровне обратного прокси (nginx/Caddy/Traefik) WAF-правило, блокирующее POST /api/v1/user/orgs, POST /api/v1/org/*/repos, если в теле запроса поля username / name содержат .. или / (см. detection/);
• Ограничьте права записи контейнера Gogs за пределами /data/gogs/data/tmp/ (selinux/apparmor).

Анализ первопричины

1. Асимметрия проверки: веб — есть, API — нет

Web-форма (internal/form/org.go, v0.14.2):

type CreateOrg struct {
    OrgName string `binding:"Required;AlphaDashDot;MaxSize(35)"` // 正则 ^[a-zA-Z0-9._-]+$
}

API (internal/route/api/v1/org/org.go, v0.14.2):

// api.CreateOrgOption (go-gogs-client) 的绑定 tag:
type CreateOrgOption struct {
    UserName string `json:"username" binding:"Required"` // ← 没有 AlphaDashDot!
}

→ Поле username в POST /api/v1/user/orgs может содержать произвольные символы и попадать прямо на уровень БД.

2. Уровень БД проверяет только зарезервированные имена, но не набор символов

internal/database/users.go:1532 isNameAllowed перехватывает только зарезервированные имена/префиксы-суффиксы (например, admin, -bot), не проверяя набор символов, поэтому ../ проходит.

3. Sink пути не очищается

internal/repoutil/repoutil.go (v0.14.2):

func UserPath(user string) string {
    return filepath.Join(conf.Repository.Root, strings.ToLower(user)) // ← 直接拼接
}

internal/database/org.go:165:

os.MkdirAll(repoutil.UserPath(org.Name), os.ModePerm) // org.Name 含 ../ → 任意路径写入

4. Использование рабочего дерева local-r для размещения hook

Когда Gogs обрабатывает редактирование файлов через Web/API, он выполняет checkout репозитория в /data/gogs/data/tmp/local-r/<repo_id>/. <repo_id> в точности равен id репозитория в БД. Атакующий:

1. Создаёт личный репозиторий writer, получает id == n;
2. Через API создаёт организацию с обходом пути: username = "../../../../data/gogs/data/tmp/local-r/n/nested" → физический каталог оказывается внутри рабочего дерева writer;
3. Создаёт в этой организации репозиторий rce-x → он оказывается в local-r/n/nested/rce-x.git;
4. Клонирует writer, коммитит и пушит nested/rce-x.git/hooks/update как обычный файл (он оказывается в рабочем дереве writer);
5. Через API вызывает файловые операции для writer → Gogs запускает git в local-r/n/ → git выполняет hooks/update → RCE.

Ключевой момент: вредоносный hook попадает через обычный push как обычное содержимое репозитория, и не требует конфигурации ENABLE_GIT_HOOKS — в этом отличие от «традиционного злоупотребления git hooks».

Подробный анализ диффа патча — в patch/ANALYSIS.md.

Обнаружение

Полные правила — в detection/:

• Sigma-правила: detection/sigma/ — покрывают попытки атаки (API-запросы с ../) и успешную эксплуатацию (размещение в файловой системе)
• SIEM-запросы: detection/queries.md — Splunk / Elastic / Kibana / Loki
• IOCs: detection/iocs.md — следы в файловой системе, сигнатуры логов, особенности имён пользователей

Два самых важных момента:

1. Блокировка на уровне WAF / обратного прокси: в JSON body запросов POST /api/v1/user/orgs и POST /api/v1/org/*/repos поля username/name содержат .. или /.
2. Проверка файловой системы: появление неожиданных подкаталогов в /data/gogs/data/tmp/local-r/*/ (nested/, rce-*.git, hooks/update).

Инструменты для защиты

• tools/check_version.py — неинвазивный сканер версий: через GET /api/v1/version проверяет, находится ли инстанс Gogs на версии < 0.14.3; поддерживает пакетное сканирование и вывод в CSV, подходит для инвентаризации активов.

Этот репозиторий не предоставляет weaponized эксплойтов. Для воспроизведения используйте публичный PoC, указанный в официальном advisory, и только в изолированной среде.

Лабораторная среда

Правила из detection/ нужно проверять на затронутой версии Gogs; lab/docker-compose.yml предоставляет изолированную среду Gogs 0.14.2 для тестирования синей командой срабатывания правил обнаружения. Не открывайте доступ из интернета, только локально.

Хронология

Ссылки

• Официальный advisory: https://github.com/gogs/gogs/security/advisories/GHSA-c39w-43gm-34h5
• Исправляющий PR: https://github.com/gogs/gogs/pull/8334
• OSV: https://osv.dev/vulnerability/CVE-2026-52813
• Релиз Gogs 0.14.3: https://github.com/gogs/gogs/releases/tag/v0.14.3

⚠️ Про неверное утверждение о «gitrebase parameter injection»

В интернете можно встретить описание этого CVE как «Gogs gitrebase: инъекция параметров, удалённое выполнение кода» — это неверно. Данная уязвимость не связана с git rebase / gitrebase; первопричина — обход пути в API. Этот документ написан на основе реального анализа уязвимости.

Лицензия

MIT — см. LICENSE.