GitLab выпустил патчи, закрывающие несколько уязвимостей, и главная из них — CVE-2026-85706 с максимальной оценкой CVSS 10.0. Это path traversal в API коммитов репозитория: при определённых условиях неаутентифицированный пользователь может прочитать произвольные файлы на сервере GitLab. Как сообщили в компании, причина — «неправильное ограничение пути и отсутствие проверки аутентификации в repository commits API».
Попытки эксплуатации начались почти сразу после раскрытия: по данным компании watchTowr, занимающейся preemptive exposure management, сканирования в интернете фиксировались с 06:00 UTC 11 сентября 2026 года. Это уже не первый критический случай у GitLab за последние недели — уязвимость CVE-2026-19478 в GraphQL эксплуатировали почти сразу после публикации патча.
Кто уязвим и как обновиться
Проблема затрагивает GitLab Community Edition (CE) и Enterprise Edition (EE) в следующих версиях:
- все версии с 18.7 до 19.1.8;
- все версии с 19.2 до 19.2.6;
- все версии с 19.3 до 19.3.2.
Исправления вышли в версиях 19.3.2, 19.2.6 и 19.1.8. Организациям, которые держат self-managed GitLab с доступом из интернета, нужно установить патчи как можно скорее либо ограничить публичный доступ, если он не требуется.
Что именно утекает
По оценке watchTowr, эксплуатация позволяет внешнему атакующему прочитать лог-файлы и конфигурационные файлы самого GitLab — то есть добраться до учётных данных, секретов и другой чувствительной информации. Для атаки нужно всего одно условие: в инстансе должен существовать хотя бы один публичный проект.
«Это второй случай критической уязвимости GitLab за последние недели — после предыдущей инъекции кода в GraphQL (CVE-2026-19478), которую почти сразу начали активно эксплуатировать, — заявил Джейк Нотт, руководитель направления threat intelligence в watchTowr. — Привлекательность GitLab для атакующих очевидна: несанкционированный доступ даёт исходный код, секреты CI/CD, учётные данные и возможность внедрять код в сборочные конвейеры, получая доступ или отравляя всё, что находится дальше по цепочке».
Вторая уязвимость: десериализация в GitLab EE
В тех же версиях — 19.3.2, 19.2.6 и 19.1.8 — закрыта критическая ошибка небезопасной десериализации в GitLab EE (CVE-2026-87719, CVSS 9.9), которая может привести к раскрытию информации. Аутентифицированный пользователь с доступом к Duo Chat мог с помощью специально сформированного аргумента GraphQL-подписки обойти сериализацию и выполнить поиск серверных объектов, получив конфигурации Advanced Search и чувствительные учётные данные. Похожий класс ошибок — небезопасная работа с библиотекой-парсером — ранее приводил к удалённому выполнению кода в GitLab через Oj.
Как искать следы эксплуатации
Нотт рекомендует не ограничиваться обновлением: «Судя по истории, переход этой уязвимости к массовой неизбирательной эксплуатации, вероятно, не за горами, и у защитников мало времени. Где возможно, организациям стоит проверить лог-файлы на HTTP POST-запросы к URI вида /api/v4/projects/{id}/repository/commits/, содержащие параметры file.Path, чтобы выявить попытки эксплуатации».
Практический порядок действий для администратора: определить свою версию GitLab, обновиться до 19.3.2, 19.2.6 или 19.1.8, затем просмотреть журналы веб-сервера и самого GitLab на подозрительные POST-запросы к API коммитов. Если обновление откладывается, доступ к веб-интерфейсу со стороны интернета стоит закрыть или ограничить по IP. В качестве ориентира при разборе инцидентов пригодится разбор критической уязвимости в Ruby on Rails Active Storage, где чтение файлов и выполнение кода шли рука об руку.
Что это значит для российских команд
GitLab широко используется в российской разработке, в том числе в виде self-managed инсталляций, развёрнутых на собственных серверах и VDS. Именно такие установки с публичным доступом и оказываются в зоне риска: сканирования идут по всему интернету и не разбирают, кому принадлежит инстанс. Отдельно стоит помнить, что уязвимость в repository commits API не зависит от того, где размещён сервер, — важно лишь, открыт ли он наружу и есть ли в нём хотя бы один публичный проект.
Частые вопросы
Кого касается CVE-2026-85706?
Всех, кто использует GitLab CE или EE версий с 18.7 до 19.1.8, с 19.2 до 19.2.6 и с 19.3 до 19.3.2. Особенно срочно — тех, чьи self-managed инстансы доступны из интернета.
Что может сделать атакующий?
Без аутентификации прочитать произвольные файлы на сервере GitLab. По данным watchTowr, речь прежде всего о лог-файлах и конфигурационных файлах GitLab, откуда извлекаются учётные данные и секреты.
Нужен ли публичный проект для атаки?
Да. По словам Джейка Нотта из watchTowr, эксплуатация требует всего одного условия — наличия хотя бы одного публичного проекта в инстансе.
До какой версии обновляться?
До 19.3.2, 19.2.6 или 19.1.8 — в зависимости от вашей ветки. Патчи закрывают и CVE-2026-85706, и CVE-2026-87719.
Что делать, если обновиться прямо сейчас нельзя?
Ограничить публичный доступ к инстансу, если он не требуется для работы. Это снижает вероятность того, что сканирование из интернета дойдёт до уязвимого API.
Как проверить, не эксплуатировали ли уязвимость?
Искать в логах HTTP POST-запросы к URI вида /api/v4/projects/{id}/repository/commits/ с параметрами file.Path. Такую проверку рекомендует watchTowr.
Чем опасна вторая уязвимость, CVE-2026-87719?
Это небезопасная десериализация в GitLab EE (CVSS 9.9). Аутентифицированный пользователь с доступом к Duo Chat мог через специально сформированный аргумент GraphQL-подписки получить конфигурации Advanced Search и чувствительные учётные данные.
Насколько срочно нужно патчиться?
Сканирования начались уже через несколько часов после раскрытия — с 06:00 UTC 11 сентября 2026 года. По оценке watchTowr, массовая неизбирательная эксплуатация может начаться в ближайшее время.
Источник: thehackernews.com