GitLab призывает срочно обновиться: критическая CVE-2026-85706 с рейтингом 10.0 уже эксплуатируется

Если у вас собственный GitLab, откладывать обновление уже опасно. GitLab выпустила критические патчи для CVE-2026-85706 — уязвимости в repository commits API, которая при определённых условиях позволяет неавторизованному пользователю читать произвольные файлы с сервера. Оценка CVSS — максимальные 10.0, а GitLab подтверждает, что CVE уже добавлена в каталог Known Exploited Vulnerabilities CISA.

Риск особенно неприятен для DevOps-инфраструктуры: файл, который «просто прочитали», может содержать конфигурацию, токен, ключ или другой секрет, открывающий следующий этап атаки. Поэтому правильная реакция — не только поставить патч, но и оценить, не могли ли секреты быть скомпрометированы раньше.

Что известно о CVE-2026-85706

По официальному advisory GitLab, проблема связана с improper path confinement и отсутствующим enforcement аутентификации в repository commits API. При определённых условиях удалённый пользователь без аутентификации мог читать произвольные файлы с GitLab-сервера.

CVSS-вектор показывает крайне опасное сочетание для интернет-сервиса: атака сетевая, низкой сложности, не требует учётной записи и взаимодействия жертвы. Поэтому базовый балл — 10.0.

Какие версии GitLab уязвимы

Официальная матрица: GitLab CE/EE от 18.7 до версий перед 19.1.8; ветка 19.2 до 19.2.6; ветка 19.3 до 19.3.2. Исправления вышли в 19.1.8, 19.2.6 и 19.3.2. GitLab рекомендует self-managed инсталляциям обновиться немедленно.

Для GitLab.com и GitLab Dedicated ситуация другая: управляемая GitLab инфраструктура уже исправлена, и клиентам этих сервисов отдельно действовать не нужно.

Почему arbitrary file read может превратиться в большой инцидент

Название «чтение файлов» звучит менее драматично, чем remote code execution, но для GitLab это крайне серьёзный класс проблемы. DevOps-сервер часто находится в центре supply chain: он видит приватный код, CI/CD, deployment-конфигурацию и интеграции. Доступ к чувствительному локальному файлу может дать атакующему материал для дальнейшего проникновения.

Поэтому после патча стоит думать не только «уязвимость закрыта». Если инстанс был доступен из интернета в период риска, администратору нужно проверить признаки эксплуатации и определить, какие секреты потенциально могли быть прочитаны.

GitLab уже дала три detection-сценария

В patch release GitLab перечисляет три threat detections для self-managed клиентов: попытку LFI с чтением gitlab.yml, LFI через параметр metadata.path и попытку LFI с file path. Это даёт администраторам направление для hunting, а не только номер исправленной версии.

Что делать администратору сейчас

Первое — обновиться. Оставаться на уязвимой версии после появления KEV — неоправданный риск. Выберите актуальный поддерживаемый релиз своей ветки, не ниже 19.1.8, 19.2.6 или 19.3.2 соответственно.

Второе — проверить журналы и detection rules. Успешный upgrade не отвечает на вопрос, был ли доступ к файлам раньше.

Третье — рассмотреть ротацию секретов, если есть подозрение на компрометацию. Приоритет — credentials и токены, которые могли храниться в файлах, доступных процессу GitLab, а также ключи к CI/CD, облаку и production.

Четвёртое — учесть процедуру обновления. GitLab предупреждает, что patch release содержит database migrations. Для single-node возможен downtime; multi-node можно обновлять по zero-downtime процедуре.

Почему эта CVE важна для украинского IT

GitLab широко используют команды разработки, интеграторы, продуктовые компании и внутренние IT-службы. В Украине self-hosted инфраструктура особенно актуальна там, где код и deployment не хотят переносить во внешний SaaS. Именно такие инсталляции требуют внимания.

Это хороший повод проверить базовую гигиену: действительно ли GitLab должен быть открыт всему интернету, как быстро команда устанавливает critical patches, где лежат секреты и есть ли план их ротации после возможной утечки.

Что ещё исправлено в этом релизе

Пакет 19.3.2/19.2.6/19.1.8 содержит не одну CVE. GitLab также описывает критическую CVE-2026-87719 с оценкой 9.9 в GraphQL subscription serializer для GitLab EE и ряд других проблем. Поэтому откладывать этот patch release не стоит даже тем, кто считает, что конкретный commits API у него используется редко.