Критическая уязвимость GitLab CVE-2026-85706: риски утечки учётных данных бизнеса

Что случилось: уязвимость GitLab CVE-2026-85706

14 сентября 2026 года стало известно о критической уязвимости GitLab: ей присвоили идентификатор CVE-2026-85706, а оценка по шкале CVSS достигла максимума — 10 из 10 баллов. Причина — ошибка типа path traversal в API, который отвечает за работу с коммитами репозитория: проверка запрошенных путей реализована неверно, а аутентификация вовсе не требуется, так что получить содержимое произвольных файлов на сервере — логов, конфигурационных файлов, учётных данных и токенов доступа — способен любой посторонний без логина и пароля. Для атаки достаточно одного условия: на инстансе должен быть хотя бы один общедоступный проект, а такая настройка встречается очень часто — даже там, где платформу используют почти исключительно для внутренней разработки.

Помимо этой проблемы специалисты обнаружили ещё одну — CVE-2026-87719 с оценкой 9,9 балла. Причина здесь другая: небезопасная десериализация в механизме подписок GraphQL, а затрагивает она только редакцию EE. Обе проблемы отнесены к критическим: для эксплуатации CVE-2026-85706 не нужна ни аутентификация, ни какие-либо действия жертвы, а CVE-2026-87719 доступна аутентифицированному пользователю с доступом к Duo Chat — тем не менее обе оценены как критические, и риск автоматизированных атак на такие бреши по-прежнему велик.

Технические детали: почему оценка CVSS так близка к максимуму

CVE-2026-85706 и CVE-2026-87719 относятся к разным техническим классам, но их оценки CVSS, близкие к предельным, не случайны. Первая — это path traversal: ошибка в обработке путей к файлам, из-за которой API коммитов не проверяет, остаётся ли запрошенный путь в границах разрешённой директории проекта. Добавив в запрос служебные символы вида «../», атакующий выходит за пределы репозитория и читает произвольный файл на сервере — вплоть до системных конфигураций и данных для авторизации.

Вторая проблема, CVE-2026-87719, устроена иначе — это небезопасная десериализация в сервисе подписок GraphQL, который есть только в редакции EE. Эксплуатация требует аутентифицированного доступа к Duo Chat, а её результат — получение настроек Advanced Search и учётных данных. Поскольку затронута лишь редакция EE, пользователям CE достаточно закрыть CVE-2026-85706, а компаниям на EE нужно устранить обе бреши.

Итоговый балл CVSS складывается не из одного показателя, а из набора базовых метрик — вектора атаки (возможна ли эксплуатация удалённо по сети), сложности эксплуатации, требуемого уровня привилегий, необходимости действий пользователя и итогового влияния на конфиденциальность, целостность и доступность системы. Оценка, близкая к 10 баллам, означает, что по всем метрикам сошлись самые опасные значения одновременно: доступ возможен удалённо, без учётной записи, без сложных условий и без участия жертвы, а итог — чтение файлов на сервере. Специалисты по информационной безопасности обычно классифицируют такие случаи как внеплановые: патч нужно ставить сразу, а не по графику.

Какие версии GitLab нужно обновить

CVE-2026-85706 затрагивает три линейки релизов — и CE, и EE. Исправленные сборки уже выпущены, поэтому обновляться стоит независимо от того, открыт ли сейчас публичный доступ к репозиториям: настройки видимости проектов меняются со временем, и закрытый сегодня проект завтра может стать общедоступным.

Если поставить обновление мгновенно не получается — например, требуется цикл тестирования перед выкладкой на прод, — временной мерой защиты станет отключение публичного доступа к инстансу: все проекты переводятся в приватный режим до момента установки патча.

Зафиксирована ли активная эксплуатация этой бреши

Исследователи из компании watchTowr зафиксировали попытки сканирования и эксплуатации CVE-2026-85706 начиная с 11 сентября 2026 года. Это подтверждает то, что проблемы с оценкой около предельных 10 баллов, да ещё не требующие аутентификации, как правило, попадают в поле зрения автоматических сканеров и ботов уже в первые дни после публикации технических подробностей — быстрее, чем компании успевают развернуть обновления.

Службам информационной безопасности стоит расценивать это как подтверждение того, что действовать нужно без промедления: патч ставится немедленно, а анализ логов идёт параллельно. Тем более что для реализации атаки не нужны ни фишинговые письма, ни приёмы социальной инженерии — хватает сетевого доступа к открытому инстансу с хотя бы одним общедоступным проектом.

Чем эта уязвимость грозит бизнесу

Для служб ИБ и ИТ-директоров ценность этой истории не в самом факте бреши, а в её типичных последствиях — краже данных из систем разработки. В репозиториях и конфигурациях GitLab нередко хранятся переменные окружения, ключи API, токены CI/CD и пароли сервисных учётных записей. Получив всё это без какой-либо авторизации, злоумышленник фактически перескакивает привычный барьер входа: подбирать пароль ему уже не нужно — похищенные привилегированные данные можно немедленно применить для проникновения в другие корпоративные системы.

Схема развития атаки здесь типовая: сначала брешь во внешнем сервисе, затем компрометация учётных данных, а после — перемещение по внутренней инфраструктуре с помощью украденных привилегий. Поэтому контроль привилегированного доступа и наблюдение за действиями администраторов важны даже после установки патча: если пароли или токены были похищены до обновления, самого патча недостаточно — их нужно отзывать и выпускать новые.

Как проверить, была ли атака на ваш GitLab

Перед тем как исключить инцидент, стоит поднять журналы веб-сервера и приложения GitLab за весь период с момента раскрытия проблемы и изучить их на признаки эксплуатации. Обратить внимание нужно на следующее:

• Запросы к API коммитов и репозиториев, где в параметрах пути встречаются последовательности «../», «%2e%2e%2f» или их закодированные аналоги.
• Ответы со статусом HTTP 200 на обращения к файлам за пределами структуры репозитория — например, к системным конфигурациям или файлам с переменными окружения.
• Заметный рост запросов к API публичных проектов с новых, ранее не встречавшихся IP-адресов или незнакомых диапазонов.
• В редакции EE — сбои, разрывы соединений или нетипичное поведение сервиса подписок GraphQL: возможный признак попыток использовать CVE-2026-87719.
• Появление корпоративных токенов, ключей API или фрагментов конфигурации в открытых источниках, пастбинах или на теневых форумах — косвенный, но серьёзный сигнал уже случившейся утечки.

Если такие следы обнаружены, ситуацию правильнее сразу считать подтверждённым инцидентом: запускать расследование, подключать ответственных за реагирование и без задержки менять все потенциально скомпрометированные учётные данные — независимо от того, установлен ли к этому моменту патч.

Что делать: чек-лист защиты от уязвимости GitLab

Компаниям с self-hosted GitLab CE или EE стоит как можно быстрее пройти следующие шаги.

1. Обновиться до версии 19.3.2, 19.2.6 или 19.1.8 — в зависимости от используемой линейки.
2. Если немедленное обновление невозможно — временно закрыть публичный доступ к инстансу и проектам.
3. Изучить логи веб-сервера и приложения на предмет подозрительных POST-запросов к API коммитов за весь период до установки патча.
4. Сменить токены доступа, пароли сервисных учётных записей и ключи API, которые теоретически мог прочитать злоумышленник через эту брешь.
5. Проверить активность администраторов и других привилегированных пользователей за последние недели: не встречались ли нетипичные входы или операции с чужих учётных записей.
6. Усилить контроль доступа к ключевым системам разработки: многофакторная аутентификация при входе и раздельный учёт привилегированных сессий уменьшают ущерб, даже если пароль или токен всё-таки были украдены.

Общие рекомендации по харденингу GitLab

Кроме срочного устранения конкретной проблемы, история с CVE-2026-85706 — хороший повод пересмотреть базовую защиту инфраструктуры разработки в целом. Некоторые практики снижают риск не только для этого случая, но и для будущих проблем платформы:

• Без необходимости не открывать административную панель и API GitLab во внешний доступ — ограничивать вход по IP, через VPN или отдельный защищённый сетевой сегмент.
• Держать количество публичных проектов на минимуме и регулярно пересматривать их перечень: именно наличие общедоступного проекта было условием для эксплуатации CVE-2026-85706.
• Хранить секреты, токены и ключи API отдельно от репозиториев — в специализированном хранилище, а не в конфигурационных файлах или переменных CI/CD, видимых при просмотре кода.
• Подписаться на security-рассылку и release-notes GitLab, чтобы узнавать о критических обновлениях сразу, а не спустя недели.
• Внедрить многофакторную аутентификацию для входа во все системы разработки и администрирования: саму брешь она не устраняет, но заметно осложняет использование украденных паролей и токенов после возможной утечки.
• Разграничить и протоколировать привилегированный доступ администраторов GitLab, чтобы служба ИБ могла быстро восстановить хронологию событий при подозрении на инцидент.

Частые вопросы

Что такое уязвимость GitLab CVE-2026-85706?

Это критическая брешь класса path traversal в API коммитов GitLab с максимальной оценкой CVSS — 10 из 10. Она позволяет неаутентифицированному злоумышленнику читать произвольные файлы на сервере, включая учётные данные и токены, при условии, что на инстансе есть хотя бы один общедоступный проект.

Какие версии GitLab нужно обновить?

Под угрозой линейки 18.7–19.1.7, 19.2–19.2.5 и 19.3–19.3.1. Исправления вошли в сборки 19.1.8, 19.2.6 и 19.3.2 — до одной из них стоит обновиться.

Нужна ли злоумышленнику учётная запись для атаки?

Нет — и в этом основная опасность: для эксплуатации не нужна ни аутентификация, ни какие-либо права в системе, достаточно наличия публичного проекта на инстансе GitLab.

Что делать, если обновить GitLab сразу нельзя?

Временной мерой стоит перевести все проекты в приватный режим, закрыть публичный доступ к инстансу до установки патча и усилить наблюдение за логами на признаки эксплуатации.

Достаточно ли просто установить патч?

Патч закрывает саму брешь, но не отменяет утечку данных, если она произошла раньше обновления. Дополнительно нужно сменить токены и пароли, а также проверить журналы на признаки несанкционированного доступа.

Чем CVE-2026-87719 отличается от CVE-2026-85706?

CVE-2026-87719 — отдельная проблема класса небезопасной десериализации в сервисе подписок GraphQL с оценкой CVSS 9,9. В отличие от CVE-2026-85706, для её эксплуатации нужен аутентифицированный доступ к Duo Chat, а результат атаки — получение настроек Advanced Search и учётных данных; проблема касается только редакции EE и не связана с чтением файлов через API коммитов, но также считается критической и требует обновления.

Зафиксированы ли реальные атаки с использованием этой бреши?

Да — исследователи из компании watchTowr зафиксировали попытки сканирования и эксплуатации CVE-2026-85706 начиная с 11 сентября 2026 года. Это подтверждает, что проблемы с такой оценкой и без требования аутентификации быстро попадают в поле зрения автоматизированных сканеров, поэтому обновляться нужно без промедления.

Как понять, что через эту брешь уже читали файлы на нашем сервере?

Стоит проверить логи веб-сервера и приложения на запросы к API коммитов с признаками path traversal в параметрах пути, а также на нетипичные успешные ответы на такие запросы, и дополнительно следить за появлением корпоративных токенов или данных конфигурации в открытых источниках.

Вывод: как снизить риск подобных инцидентов

История с CVE-2026-85706 в очередной раз показывает: даже проверенный внутренний инструмент разработки способен стать точкой входа для атаки, если администрирование отстаёт от темпа выхода патчей. Компаниям стоит не ограничиваться устранением одной конкретной проблемы, а системно пересмотреть защиту привилегированных учётных записей и токенов доступа во всех сервисах разработки и ИТ-инфраструктуры.

В Контур.Эгиде — партнёре СКБ Контур — мы решаем именно эту задачу: помогаем внедрять многофакторную аутентификацию для входа в критичные системы, разграничивать и контролировать привилегированный доступ администраторов, а также следить за действиями сотрудников, чтобы утечка одного токена или пароля не переросла в полноценный инцидент с потерей данных. Это не заменяет своевременную установку патчей вроде обновления GitLab, но заметно снижает ущерб, если брешь всё-таки будет эксплуатироваться до момента исправления.