GitLab закрыл уязвимость CVE-2026-85706 максимальной опасности — CVSS 10. Это path traversal в API коммитов репозитория, позволяющий прочитать произвольные файлы на сервере одним HTTP-запросом, без аутентификации. Проблема затронула GitLab Community Edition (CE) и Enterprise Edition (EE), и её уже пытаются эксплуатировать.
Причина — некорректная изоляция путей и отсутствие проверки аутентификации в API коммитов репозитория. При определённых условиях злоумышленник читает файлы с конфигурацией, секретами и учётными данными прямо с уязвимого сервера. GitLab уже выпустил исправление и советует владельцам публично доступных self-hosted инстансов обновиться немедленно либо закрыть доступ извне.
Какие версии уязвимы
Уязвимость затрагивает CE и EE версий:
- 18.7 до 19.1.8;
- 19.2 до 19.2.6;
- 19.3 до 19.3.2.
Ошибку нашли через программу Bug Bounty на HackerOne. Это вторая серьёзная уязвимость GitLab за месяц: в августе вендор закрыл критическую дыру, позволявшую неаутентифицированному пользователю менять содержимое репозиториев и полностью удалять их одним HTTP-запросом. В январе GitLab патчил уязвимость высокого риска, через которую владелец ID аккаунта жертвы мог обойти двухфакторную аутентификацию. Похожие истории с GitLab уже разбирались на нашем сайте: path traversal с CVSS 10 и подтверждение активной эксплуатации от CISA.
CISA добавила в каталог эксплуатируемых, сканеры уже стучатся
Агентство по кибербезопасности и защите инфраструктуры США (CISA) внесло CVE-2026-85706 в каталог Known Exploited Vulnerabilities. Там отметили, что такой тип уязвимости — частый вектор атак и особенно опасен для федеральных организаций. Исследователи watchTowr Intel сообщили, что уже наблюдают попытки эксплуатации, и предупредили: судя по недавним уязвимостям GitLab, массовая эксплуатация не за горами.
Ждать планового цикла обновлений в этом случае нельзя, подчёркивает Сафайят Моахамад, директор по консалтингу Info-Tech Research Group. Уязвимость даёт неаутентифицированный доступ к произвольным файлам на платформе, которая часто стоит в центре работы с исходным кодом, сборкой и развёртыванием.
Как искать попытки эксплуатации
Команда watchTowr Intel советует искать следы атак в логах: HTTP POST-запросы к URI вида /api/v4/projects/{id}/repository/commits/, содержащие параметры file.path. Именно так выглядит обращение к уязвимому API коммитов.
Помимо патча, Моахамад рекомендует проверить, не содержали ли доступные файлы учётные данные и секреты, которые теперь нужно сменить, и провести поиск подозрительной активности вокруг API коммитов репозитория.
Почему это опаснее обычной утечки исходников
По оценке Info-Tech Research Group, платформой GitLab пользуется примерно половина компаний из списка Fortune 100, а число зарегистрированных пользователей превышает 50 миллионов. В типовом предприятии GitLab связан с конвейерами сборки, процессами развёртывания и рабочими процессами безопасности приложений.
«GitLab — это не просто хранилище исходного кода», — отмечает Моахамад. Несанкционированный доступ к конфигурационным файлам, секретам или учётным данным на сервере GitLab может «привести к последствиям далеко за пределами затронутого инстанса».
Что именно получит атакующий, зависит от того, к чему имеет доступ сервис GitLab и что хранится на сервере. Это могут быть конфигурации, секреты, учётные данные и другие чувствительные данные. Если в файлах лежат рабочие токены, ключи или пароли, злоумышленник может попытаться проникнуть в связанную инфраструктуру. Дальше возможны кража учётных данных, горизонтальное перемещение, утечка исходного кода и компрометация цепочки поставок.
Дэвид Шипли из Beauceron Security видит два фактора, которые складываются в «максимальную боль» для пользователей GitLab. Первый — сама уязвимость: «Это 10 по делу: неаутентифицированное чтение исходного кода клиента GitLab». Второй — привычки разработчиков: слишком много кода уходит в релиз или остаётся в продакшене со встроенными SSH-ключами, облачными секретами, токенами и другими ценными данными, которые открывают доступ к инфраструктуре.
Для атакующих это классический набор: вывод данных и шантаж, программы-вымогатели, захват облачных ресурсов под майнинг криптовалют, кража ИИ-токенов и инфраструктуры для другой преступной активности. «Такая уязвимость — это как получить номер кредитки, срок её действия и код безопасности в мире кода и облака», — говорит Шипли. Его совет: убрать секреты из продакшен-кода и перейти на современные практики аутентификации при разработке.
Что делать администратору
В первую очередь обновите self-hosted GitLab CE или EE до версий выше уязвимого диапазона. Если публичный инстанс обновить прямо сейчас нельзя, закройте его от внешнего доступа. Затем проверьте логи на обращения к API коммитов с параметром file.path и оцените, какие файлы могли быть прочитаны. Если среди них были токены, ключи или пароли — смените их. Наконец, ограничьте то, к чему имеет доступ сервис GitLab: исходный код и платформы CI/CD стоит рассматривать как критичную доверенную инфраструктуру, а устойчивость зависит от понимания, где платформа может быть открыта, что она может читать, и от готового процесса расследования и ротации учётных данных. Если в вашей инфраструктуре есть другие сервисы с похожими дырами чтения файлов, полезно свериться с разбором symlink-гонки в Plesk Backup Manager.
Частые вопросы
Кого касается уязвимость CVE-2026-85706?
В первую очередь — владельцев self-managed инстансов GitLab Community Edition и Enterprise Edition уязвимых версий. Особенно тех, чьи серверы доступны из интернета.
Как проверить свою версию GitLab?
Сравните установленную версию с уязвимым диапазоном: 18.7 до 19.1.8, 19.2 до 19.2.6, 19.3 до 19.3.2. Если ваша версия попадает в него, нужно обновиться.
Что делать, если обновиться прямо сейчас нельзя?
GitLab рекомендует убрать публичный доступ к self-hosted инстансу до установки патча. Без внешнего доступа эксплуатация снаружи становится невозможной.
Как понять, что сервер уже пытались взломать?
Ищите в логах HTTP POST-запросы к URI вида /api/v4/projects/{id}/repository/commits/ с параметрами file.path. Это характерный признак обращения к уязвимому API.
Какие данные могли утечь?
Всё, что сервис GitLab может прочитать на сервере: конфигурационные файлы, секреты, учётные данные и другие чувствительные данные. Конкретный список зависит от вашей конфигурации.
Что делать, если в доступных файлах были токены и пароли?
Их нужно немедленно сменить. Если в файлах лежали рабочие ключи или токены, атакующий мог получить доступ к связанной инфраструктуре, поэтому ротация учётных данных обязательна.
Почему уязвимость получила максимальную оценку 10?
Она позволяет читать произвольные файлы без аутентификации, одним HTTP-запросом, на платформе, которая часто связана с исходным кодом, сборкой и развёртыванием. Это сочетание и даёт максимальный балл.
Это первая такая уязвимость в GitLab?
Нет. В августе GitLab закрыл критическую дыру с возможностью менять и удалять репозитории одним запросом, а в январе — уязвимость, позволявшую обойти двухфакторную аутентификацию. Нынешняя — вторая серьёзная проблема за месяц.
Источник: csoonline.com