• Установленный CISA срок устранения активно эксплуатируемой уязвимости GitLab CVE-2026-85706 истёк 14 сентября
  • Исправление GitLab требует миграций базы данных: на время их выполнения одноузловые установки становятся недоступны, а многоузловые развёртывания при корректном обновлении могут избежать простоя

Факты

Установленный CISA срок устранения CVE-2026-85706 истёк 14 сентября. Эта активно эксплуатируемая уязвимость GitLab при определённых условиях может позволить пользователю без аутентификации читать файлы с сервера. 11 сентября CISA добавило эту уязвимость в свой каталог известных эксплуатируемых уязвимостей. Федеральный срок распространяется на гражданские ведомства США, подпадающие под действие этих требований.

10 сентября GitLab выпустила версии 19.3.2, 19.2.6 и 19.1.8 с исправлением и призвала затронутых клиентов, самостоятельно управляющих своими установками, немедленно обновиться. На GitLab.com исправление уже установлено, а клиентам GitLab Dedicated ничего предпринимать не нужно.

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

Оценка

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

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

Для читателей BTW этот инцидент наглядно показывает операционные издержки инфраструктуры разработки под собственным управлением. Организация отвечает не только за серверы, но и за экстренное окно технических работ. Для клиентов GitLab.com и GitLab Dedicated необходимые работы по безопасности уже выполнены, тогда как администраторам собственных установок приходится встраивать то же исправление в свой календарь релизов и затем штатно восстанавливать работу сервиса.

За чем следить

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