В GitLab раскрыта критическая уязвимость path traversalобход пути: атакующий подставляет в путь к файлу конструкции вида `../`, чтобы выйти за пределы разрешённого каталога CVE-2026-85706идентификатор уязвимости в каталоге общедоступных CVE. Она позволяет неаутентифицированному удалённому атакующему читать произвольные файлы с сервера GitLab. Уязвимость затрагивает self-managedэкземпляр GitLab, развёрнутый и обслуживаемый самой организацией, а не в облаке GitLab.com GitLab CE/EE и получила оценку CVSSшкала оценки критичности уязвимостей от 0 до 10 10.0.
Патч выпущен 11 сентября, а через несколько часов после раскрытия, по отчёту security-фирмы watchTowr, атакующие уже проводили пробы в реальных условиях. Позднее CISA добавила уязвимость в каталог Known Exploited Vulnerabilities (KEV).
Что именно изменилось
Уязвимы self-managed GitLab CE/EEразвёрнутые на собственных серверах компании редакции GitLab Community Edition и Enterprise Edition. Исправления содержатся в версиях 19.3.2, 19.2.6 и 19.1.8 — на них и нужно обновляться в зависимости от применимости.
Через две недели после первоначального выпуска исправления GitLab backportперенос исправления на более старые ветки, которые уже не развиваются фикс в версии 19.0.9 и 18.11.12 CE/EE, хотя обе версии достигли end-of-lifeсостояние, когда вендор прекращает выпускать обновления и исправления безопасности для версии и уже не поддерживаются.
Как работает уязвимость
Причина — неправильное ограничение пути и отсутствие проверки аутентификации в repository commits APIпрограммном интерфейсе GitLab, через который клиенты запрашивают сведения о коммитах репозитория. При определённых условиях неаутентифицированный пользователь мог читать произвольные файлы с сервера GitLab.
Предусловие для эксплуатации минимально: на экземпляре должен существовать хотя бы один публичный проект. После этого шага аутентификация не требуется. Среди файлов, которые может похитить атакующий, — CI/CD-переменныезначения, которые подставляются в сборочные задания и часто содержат пароли и ключи доступа, runner-токеныучётные данные, по которым сборщик заданий подключается к GitLab, SSH-ключиключи для беспарольного входа на серверы и то, что попало в логи. Это позволяет компрометировать CI/CD-конвейеры и потенциально получить доступ к другим системам, к которым имеет доступ GitLab.
Почему это сделали
Уязвимость обнаружил Mohamed Abdelaiz (S3ntago), и GitLab оперативно выпустил патч 11 сентября. Jake Knott из watchTowr сформулировал предусловие прямо: достаточно одного публичного проекта, после чего аутентификация не нужна. Parker Brisette отметил, что требования для эксплуатации минимальны.
Что это меняет на практике
Обновление закрывает саму возможность новых чтений, но не отзывает учётные данные, которые атакующий мог уже скопировать. Christopher Houser предупредил: патч останавливает новые чтения, но не отзывает deploy-токеныучётные данные для развёртывания, которыми внешние системы получают доступ к проекту, CI-переменныепеременные, которые передаются в задания конвейера CI/CD и SSH-ключи, уже скопированные атакующим. Поэтому после обновления нужно:
- заменить deploy-токены, CI-переменные и SSH-ключи на новые, а старые отозвать — просто удалить или сменить пароль недостаточно, потому что атакующий уже держит у себя копию этих данных и она продолжит работать;
- проверить, какие пакеты и образы вытягивали сборки, пока старые учётные данные оставались действительными;
- ограничить доступ из интернета и заменить затронутые секреты вместе с патчингом.
Для выявления попыток эксплуатации защитникам рекомендуется искать в логах HTTP POST-запросы к URI вида /api/v4/projects/{id}/repository/commits/ с параметрами file.path. Именно POST с этим параметром считается признаком атаки: уязвимость вызвана неправильным ограничением пути и отсутствием проверки аутентификации в API коммитов репозитория, поэтому запрос на создание коммита с указанием пути к файлу позволяет неаутентифицированному пользователю прочитать произвольный файл на сервере.
Ограничения и открытые вопросы
Авторы прямо признают: патчинг — лишь часть истории. Установка исправления сама по себе не устраняет последствия эксплуатации, поскольку уже скопированные секреты остаются действительными. Полная реакция включает обновление, ротацию скомпрометированных учётных данных, проверку того, что успели вытянуть сборки, и ограничение интернет-доступа. Конкретных замеров или статистики по количеству реальных атак не приводится — есть только подтверждение, что пробы начались в течение нескольких часов после раскрытия и что уязвимость внесена в KEV-каталог CISAсписок уязвимостей, которые, по данным CISA, уже эксплуатируются злоумышленниками в реальных атаках; попадание в него служит для организаций сигналом к обязательной приоритетной проверке и устранению такой уязвимости.
