Требования

• Docker и docker compose, python3, git, curl на хосте.
• ~8 ГБ свободной ОЗУ (два экземпляра GitLab, ~4 ГБ каждый) и ~10 ГБ на диске. Первый запуск: 4–8 минут на экземпляр.
• Запускайте только против этих локальных лабораторных экземпляров. Авторизованное/защитное тестирование программного обеспечения, которым вы управляете.

Запуск

Ожидаемый результат:

Другие подкоманды:

Как работает оракул (без обмана через HTTP-200)

И уязвимый, и пропатченный серверы отвечают на вредоносную публикацию HTTP 200 {"status":"processing"} — файл записывается позже, в финализирующем воркере. Поэтому HTTP-статус не является оракулом. Вместо этого exploit/poc.py --verify-docker <container> опрашивает внутри контейнера наличие управляемого файла по пути обхода и сравнивает его SHA-1:

• уязвимый → появляется /var/tmp/CVE_2026_10053_PROOF-1.0.0.tgz (владелец git:git, наши байты) → exit 0.
• пропатченный → файл не появляется; воркер пишет в лог Gitlab::PathTraversal::PathTraversalAttackError: Invalid path → exit 2.

Сам эксплойт — это не более чем аутентифицированный запрос PUT …/packages/npm/:pkg; обход пути целиком находится в JSON-теле name (file_name = "#{name}-#{version}.tgz", проверяется только на пустоту). Вызовы docker exec — это проверка и настройка, они никогда не входят в возможности атакующего.

Область действия

• Доказано: аутентифицированный пользователь (роль Developer+ может публиковать пакеты; в этой лаборатории для удобства настройки используется root-PAT) записывает управляемые атакующим байты в любой путь, доступный для записи пользователю git. Файлы создаются с правами 0644.
• Здесь не доказано: RCE. Сохраняемое имя файла принудительно заканчивается на -<semver>.tgz (NUL отклоняется ядром, перевод строки не обрезает имя), поэтому нельзя перезаписать ни одну цель с точным именем (secrets.yml, authorized_keys, .rb-файл, бинарники gitaly). Единственный механизм выполнения, не зависящий от имени файла, custom_hooks/<hook>.d/, запускает любой файл, но только если он исполняемый, — а эта запись даёт 0644. Перезапись существующего файла с правами 0755 не помогает: хранилище заменяет inode, сбрасывая права обратно на 0644. Таким образом, для RCE нужен отдельный примитив установки бита исполнения / запуска, который данный PoC не предоставляет.

./run.sh rce-gate честно демонстрирует именно это: он размещает хук pre-receive.d через обход пути, делает push и показывает, что хук с правами 0644 не выполняется. ./rce_gate_demo.sh --illustrate-gate дополнительно устанавливает +x через docker exec chmod (внешнее действие docker-root, не возможность атакующего) исключительно для демонстрации того, что gitaly запустил бы его, — подчёркивая, что недостающим рычагом является бит исполнения.

Причина и исправление

Полный анализ см. в ANALYSIS.md. Коротко: app/uploaders/gitlab_uploader.rb проверял путь сохранения только в before :cache; в before :store значение file_name, полученное из модели (контролируемое атакующим и не прошедшее проверку), записывалось как есть. Исправление добавляет before :store, :protect_from_path_traversal!.

Файлы