Уязвимость GitLab CVE-2026-85706 получила максимальные 10 баллов из 10 по CVSS и уже используется злоумышленниками против self-hosted-инсталляций. Для русскоязычных команд это не абстрактная новость из чужого SOC: если GitLab живет внутри компании и хранит код, CI/CD-секреты и конфиги, проблема быстро превращается в риск для всей цепочки поставки ПО.
По данным Dark Reading, GitLab раскрыла и закрыла CVE-2026-85706 10 сентября 2026 года. Уязвимость затрагивает GitLab Community Edition и Enterprise Edition и относится к path traversal: из-за некорректного ограничения путей и отсутствующих проверок аутентификации в API repository commits неавторизованный пользователь мог читать произвольные файлы с сервера GitLab. Звучит как скучный баг в обработке путей, но оценка CVSS 10/10 намекает: тут не тот случай, где можно отложить патч до спокойной пятницы.
Ключевая опасность в том, что доступ формально «только на чтение» не делает атаку безобидной. На GitLab-серверах часто лежит именно то, что нужно атакующему для следующего шага: конфигурационные файлы, секреты CI/CD, токены, SSH-настройки, иногда следы интеграций с облаками, реестрами контейнеров и внутренними сервисами. Если такие данные утекли, взлом GitLab может стать не финалом атаки, а дверью в разработческую инфраструктуру, продакшен-пайплайны и зависимые системы.
CISA уже добавила CVE-2026-85706 в каталог Known Exploited Vulnerabilities и потребовала от федеральных агентств США исправить или отключить self-managed GitLab-инстансы до 14 сентября. Для частного сектора это не юридический дедлайн, но хороший индикатор приоритета: регулятор не заносит каждую неприятную CVE в список активно эксплуатируемых уязвимостей просто для красоты таблицы.
Исследователи watchTowr сначала увидели поведенческие пробы на своих honeypot-сетях, а затем, по словам руководителя threat intelligence Джейка Нотта, активность быстро перешла к полноценной эксплуатации и выгрузке чувствительных файлов. Отдельно он указал на дампы конфигов с секретами и системных SSH-конфигураций. В практическом переводе для инфраструктурных команд: после патча стоит не только поставить галочку в трекере, но и проверить, не успели ли унести данные, которые теперь надо считать скомпрометированными.
Есть важное условие эксплуатации: по оценке watchTowr, у целевой организации должен быть хотя бы один публичный проект на GitLab-сервере. Утешение так себе. Публичные проекты в self-hosted GitLab — довольно распространенная конфигурация, причем не всегда осознанная. Команда может считать проект «внутренним», потому что сам GitLab стоит за корпоративным периметром, но отдельные настройки видимости при этом открывают больше, чем ожидали разработчики или администраторы.
GitLab рекомендует обновить self-hosted GitLab CE и EE до версий 19.3.2, 19.2.6 или 19.1.8. Если обновление прямо сейчас невозможно, временная мера — немедленно убрать публичный доступ к инстансам. Клиентам GitLab Dedicated, согласно сообщению GitLab, дополнительных действий предпринимать не нужно; облачная платформа GitLab.com уже получила исправление. Командам безопасности также стоит просмотреть логи доступа к repository commits API и искать подозрительные неаутентифицированные запросы, похожие на сканирование или эксплуатацию.
Эта уязвимость GitLab неприятна еще и потому, что она ложится в уже знакомый тренд: атакующие все чаще идут не в конечное приложение, а в инструменты, где это приложение собирается, подписывается, тестируется и выкатывается. В августе, как напоминает watchTowr, злоумышленники уже эксплуатировали другую критическую дыру в GitLab — CVE-2026-19478, связанную с GraphQL code injection, вскоре после публичного раскрытия. Окно между advisory и рабочими атаками снова сжимается до дней, а иногда и часов.
Для разработчиков вывод простой и неприятный: DevOps-инфраструктура больше не может жить в режиме «починим после релиза». GitLab, CI/CD, секрет-хранилища, registry и build runners должны попадать в тот же срочный контур реагирования, что VPN, identity provider и публичные API. Бизнесу же пора считать цепочку поставки ПО не вспомогательной IT-кухней, а частью операционного риска: если сборочная линия компрометирована, красивый продуктовый roadmap уже никого не спасает.