Две критические уязвимости в GitLab дают пользователю с обычной учётной записью выполнить произвольный код на сервере. Ещё девять проблем классом ниже, но часть из них открывает доступ к переменным сборки и закрытым данным проектов. Исправления вышли 23 сентября 2026 года, их получили все поддерживаемые ветки: 19.4.1, 19.3.3 и 19.2.7.
Детали уязвимостей
Обе критические уязвимости связаны с обработкой регулярных выражений, то есть шаблонов поиска по тексту. Первая, CVE-2026-89078, ведёт к двойному освобождению памяти: программа дважды возвращает системе один и тот же участок, и по этому участку может пойти чужой код. Вторая, CVE-2026-93577, вызывает переполнение целого числа при компиляции шаблона. Расчёт размера буфера из-за этого идёт неверно, и данные выходят за его границы. Злоумышленнику достаточно поместить специально составленное выражение в конфигурацию конвейера сборки. После этого он запускает команды от имени сервиса GitLab.
Обе уязвимости оценили в 9,9 балла по шкале CVSS (общая система оценки уязвимостей). Нашёл их исследователь под псевдонимом joaxcar и передал через программу вознаграждений HackerOne. Уровень доступа нужен минимальный: подойдёт любая подтверждённая учётная запись. Именно это и делает проблему тяжёлой. На многих серверах GitLab регистрация открыта для сотрудников, а иногда и для подрядчиков. Каждый такой пользователь получает возможность выполнить код на машине, где лежат исходники компании.
Третья проблема по значимости - межсайтовый скриптинг в просмотрщике изменений запроса на слияние. Уязвимость CVE-2026-84739 получила 8,7 балла. Разбор компонентов пути там устроен плохо, поэтому чужой сценарий выполняется в браузере другого пользователя. Дальше атакующий действует от его имени: читает страницы, меняет настройки, забирает данные. Жертве достаточно открыть страницу с изменениями, никаких дополнительных действий не требуется. Затронуты сборки начиная с 13.11 - самой старой ветки в нынешнем списке.
Далее идут проблемы среднего класса. Одна из них, в функции диагностики заданий Duo AI, позволяет читать значения закрытых переменных из отладочных журналов сборки. Работает она только в корпоративной редакции и оценена в 7,7 балла. Другая связана с проверкой области действия токенов MCP (протокол, через который внешние инструменты подключаются к ИИ-помощнику): обладатель такого токена выходит за рамки выданных прав. Ещё одна даёт подделать авторство запросов на слияние при переносе данных между серверами, и в истории проекта появляются записи от чужих имён.
Отдельная уязвимость в программном интерфейсе эпиков открывает чтение закрытых дочерних задач из недоступных проектов, включая заголовки и описания. Ошибки в управлении правами Duo Workflow и в одном из обработчиков GraphQL разрешают обойти настройки безопасности и прочитать содержимое политик. Здесь уже нужна учётная запись с правами повыше гостевых, но не административная. Поэтому набор доступных злоумышленнику данных шире, чем кажется по формальному уровню доступа.
Самый низкий балл, 3,1, у состояния гонки в поисковом инструменте MCP. Когда два запроса выполняются одновременно, результаты могли вернуться в контексте другого пользователя. Ещё одна уязвимость живёт в интерфейсе журналов заданий GraphQL: она позволяет читать содержимое трассировки сборки без входа в систему, если сложатся редкие условия. В трассировках часто остаются значения секретных переменных, так что и здесь есть риск утечки.
Важнее всего последствия для конвейеров сборки. В переменных CI/CD компании хранят токены, ключи и пароли к внешним сервисам. Утечка одного такого значения открывает доступ к репозиториям, облачным средам, хранилищам артефактов. GitLab используют и небольшие команды, и крупные предприятия, причём часть внутренних установок обновляют редко. Публичные площадки вроде GitLab.com компания обновляет сама, а вот корпоративные серверы остаются на совести их владельцев. Ошибки в проверке прав опасны ещё и тем, что не требуют ни вредоносного файла, ни обхода защиты. Достаточно обычных запросов к интерфейсу.
Исправление доступно. GitLab.com уже работает на пропатченной версии, клиентам GitLab Dedicated обновляться не нужно, сообщила компания. Владельцам собственных установок следует перейти на 19.4.1, 19.3.3 или 19.2.7 - ту ветку, которая ближе к их нынешней. Чем дольше сервер остаётся уязвимым, тем выше шанс, что кто-то успеет воспользоваться ошибкой до обновления.
Через 90 дней после выпуска патчей GitLab публикует подробности каждой уязвимости в своём трекере. Окно между раскрытием деталей и появлением рабочего эксплойта (вредоносного кода, использующего уязвимость) может оказаться коротким, поэтому обновляться лучше не дожидаясь этой даты. Регулярные выражения долго остаются источником тяжёлых ошибок: разбор чужого текста плохо поддаётся проверке на безопасность, а парсеры и компиляторы пишут на языках без защиты от работы с памятью. Конвейеры сборки добавляют к этому свою специфику, ведь они по устройству выполняют код. Разумная мера - пересмотреть, какие токены лежат в переменных CI/CD, урезать их права и срок жизни. Тогда даже при утечке ущерб окажется ограниченным.
Ссылки
