Если ваша компания запускает GitLab на собственном сервере, обновите его сегодня. 12 октября 2026 года GitLab выпустила критический патч безопасности, устраняющий 24 уязвимости. Самая опасная из них, CVE-2026-97229, получила максимально возможную оценку критичности: 10 из 10. Она позволяет человеку без учётной записи на вашем сервере запускать на нём собственный код. Затронут каждый сервер с версией 19.2 до 19.2.8, версией 19.3 до 19.3.5 или версией 19.4 до 19.4.2. Единственное исправление, которое называет GitLab, — обновление до 19.4.2, 19.3.5 или 19.2.8. Если вы пользуетесь облачным сервисом GitLab.com, ничего делать не нужно.

Что такое GitLab и почему это должно волновать владельца бизнеса?

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

Что именно объявила GitLab?

Согласно официальному объявлению GitLab о выпуске патча, уязвимость находится в компоненте, который обрабатывает регулярные выражения в настройках конвейеров сборки и развёртывания (CI/CD). Регулярное выражение — это короткий фрагмент текста, описывающий шаблон поиска. В объявлении говорится, что из-за недостаточной проверки таких выражений уязвимость может позволить неаутентифицированному пользователю выполнить произвольный код на сервере GitLab с помощью специально составленного регулярного выражения. Исследователь сообщил о ней через программу вознаграждений за ошибки GitLab на HackerOne.

В объявлении не сказано, что уязвимость уже эксплуатировалась. Но оценка 10 означает, что её можно эксплуатировать через интернет, без пароля и без помощи кого-либо из сотрудников. Злоумышленники обычно начинают искать такие уязвимости в течение нескольких дней после публикации исправления, потому что само исправление указывает, где находится слабое место.

Что ещё входит в патч?

Тот же патч устраняет ещё 23 уязвимости, пять из которых имеют высокий уровень опасности:

  • Внедрение вредоносного скрипта (XSS) в подсветке синтаксиса, оценка 8.7.
  • Уязвимость авторизации при создании конвейеров, оценка 8.5.
  • Слишком разрешительное регулярное выражение, влияющее на доступ к файлам, оценка 8.2.
  • Уязвимость авторизации в политиках выполнения конвейеров в платной редакции, оценка 7.7.
  • Уязвимость внедрения промптов (prompt injection) в ИИ-агенте GitLab Duo в платной редакции, оценка 7.3.

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

Кому нужно действовать?

  • Пользователям облачного GitLab.com: ничего делать не нужно; GitLab сообщает, что сервис уже работает на исправленной версии.
  • Клиентам GitLab Dedicated: согласно объявлению, им тоже ничего делать не нужно.
  • Всем, кто запускает GitLab на собственном сервере: обновитесь немедленно. Это прямая рекомендация GitLab для каждой самоуправляемой установки.
  • Всем, кто не уверен, где работает их GitLab: спросите сегодня свою команду или подрядчика, который создавал ваши системы. Многие внутренние серверы были настроены бывшим подрядчиком, а затем забыты.

Практические шаги на эту неделю

  1. Узнайте версию: попросите технического руководителя открыть страницу справки (Help) в GitLab, прочитать указанный там номер версии и сравнить его с приведёнными выше номерами.
  2. Запланируйте обновление на сегодня, а не на конец месяца: согласно объявлению GitLab, сервер с одним узлом недоступен во время установки патча, пока не завершатся миграции базы данных, а многоузловые конфигурации можно обновить без простоя при соблюдении соответствующей процедуры обновления без простоя. Час простоя в нерабочее время обходится гораздо дешевле, чем взломанный сервер.
  3. Если у вас 19.3: переходите сразу на 19.3.5, а не на 19.3.4. В объявлении отмечается, что в 19.3.4 была ошибка, затрагивавшая страницы запросов на слияние (merge request) при включённой интеграции Ona, исправленная в 19.3.5.
  4. Сократите доступность из интернета: если никому за пределами компании не нужен доступ к вашему серверу GitLab, настройте его так, чтобы он принимал подключения только из корпоративной сети или через VPN. Это не заменяет установку патчей, но сужает дверь в следующий раз.
  5. Проверьте всё после установки патча: просмотрите недавно созданных пользователей, ключи и токены доступа. Если появилось что-то, чего никто не узнаёт, смените пароли и ключи, хранящиеся на сервере.

Шаги обновления для каждого способа установки приведены в официальном руководстве GitLab по обновлению.

Мнение Origami

Мы пользуемся GitLab каждый день, поскольку там хранятся наши репозитории, поэтому следим за его объявлениями о безопасности так же внимательно, как за своими счетами. Урок шире, чем GitLab: каждая система, которую вы запускаете сами, чтобы держать данные внутри компании, несёт обязанность устанавливать исправления в тот же день, когда они выходят. Чаще всего мы видим проблему не в самом этом решении, а в отсутствии имени ответственного за обновления. Сервер, который подрядчик настроил три года назад и о котором никто не знает, кто его обслуживает, — первое, что ищет злоумышленник. То же самое мы говорили об уязвимости в магазинах Magento: одного патча недостаточно, если он приходит с опозданием. Если вам нужен кто-то, кто проверит ваши серверы или возьмёт на себя их обновление, свяжитесь с нами.

Источники