GitLab: три критические уязвимости за месяц, обновите до 19.5.1

За один месяц GitLab трижды выпускал срочные исправления критических уязвимостей, и все они — в обработке регулярных выражений. Две последние получили максимальные 10,0 балла и позволяют неавторизованному пользователю выполнить код на сервере. Касается это тех, кто держит GitLab у себя (self-managed): GitLab.com и GitLab Dedicated компания исправляет сама. Если ваша команда разворачивает GitLab на своём сервере, обновитесь до последней версии.

Что произошло

Все три уязвимости связаны с тем, как GitLab компилирует или разбирает регулярные выражения, в том числе в конфигурации CI/CD.

Главная проблема в том, что обновление 12 октября не закрыло всё. По данным The Hacker News, уязвимость CVE-2026-110264 затрагивает все версии GitLab начиная с 7.0, и серверы, обновлённые 12 октября до 19.4.2, 19.3.5 или 19.2.8, всё ещё уязвимы. Нужно ставить выпуск от 21 октября.

Кого касается

Компаний, которые держат GitLab на собственном сервере: для внутренней разработки, хранения кода, сборки и выкатки. Именно такие установки нужно обновлять вручную. GitLab.com и GitLab Dedicated компания пропатчила сама.

Уязвимости в обработке регулярных выражений опасны тем, что регулярки встречаются в CI/CD-конфигурации повсюду. А доступ без авторизации означает, что атаковать может любой, кто дотянется до сервера по сети. По данным источников на момент выхода, подтверждённых атак и публичных примеров эксплуатации не было, и в каталог CISA уязвимость не попала, но это не повод медлить.

Что делать

1. Узнайте версию: в интерфейсе GitLab откройте «Справка» или страницу `/help`, версия указана вверху.
2. Обновитесь до выпуска от 21 октября для своей ветки: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 или 18.11.13.
3. Если вы обновлялись 12 октября, этого недостаточно: нужен выпуск 21 октября.
4. После обновления проверьте, что сборки CI/CD и вход работают.
5. Просмотрите журналы на необычные запросы к серверу, особенно если он доступен из интернета.
6. По возможности ограничьте доступ к GitLab из интернета: держите его за VPN или в закрытом сегменте сети.

Наше мнение

Три критических выпуска за месяц в одном компоненте — редкая, но поучительная история. Она показывает, что одно обновление не всегда ставит точку: иногда исправление закрывает конкретный путь, а корневая проблема остаётся, и через неделю выходит новое. Поэтому «мы обновились в начале месяца» — не ответ на вопрос «вы в безопасности».

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

Почему self-managed требует внимания

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

Что ещё стоит проверить на сервере GitLab

Помимо обновления, у self-managed GitLab есть несколько мест, которые часто остаются без внимания:

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

Эти меры не отменяют обновления, но снижают ущерб, если уязвимость всё-таки используют.

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