Если ваша компания запускает 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: спросите сегодня свою команду или подрядчика, который создавал ваши системы. Многие внутренние серверы были настроены бывшим подрядчиком, а затем забыты.
Практические шаги на эту неделю
- Узнайте версию: попросите технического руководителя открыть страницу справки (Help) в GitLab, прочитать указанный там номер версии и сравнить его с приведёнными выше номерами.
- Запланируйте обновление на сегодня, а не на конец месяца: согласно объявлению GitLab, сервер с одним узлом недоступен во время установки патча, пока не завершатся миграции базы данных, а многоузловые конфигурации можно обновить без простоя при соблюдении соответствующей процедуры обновления без простоя. Час простоя в нерабочее время обходится гораздо дешевле, чем взломанный сервер.
- Если у вас 19.3: переходите сразу на 19.3.5, а не на 19.3.4. В объявлении отмечается, что в 19.3.4 была ошибка, затрагивавшая страницы запросов на слияние (merge request) при включённой интеграции Ona, исправленная в 19.3.5.
- Сократите доступность из интернета: если никому за пределами компании не нужен доступ к вашему серверу GitLab, настройте его так, чтобы он принимал подключения только из корпоративной сети или через VPN. Это не заменяет установку патчей, но сужает дверь в следующий раз.
- Проверьте всё после установки патча: просмотрите недавно созданных пользователей, ключи и токены доступа. Если появилось что-то, чего никто не узнаёт, смените пароли и ключи, хранящиеся на сервере.
Шаги обновления для каждого способа установки приведены в официальном руководстве GitLab по обновлению.
Мнение Origami
Мы пользуемся GitLab каждый день, поскольку там хранятся наши репозитории, поэтому следим за его объявлениями о безопасности так же внимательно, как за своими счетами. Урок шире, чем GitLab: каждая система, которую вы запускаете сами, чтобы держать данные внутри компании, несёт обязанность устанавливать исправления в тот же день, когда они выходят. Чаще всего мы видим проблему не в самом этом решении, а в отсутствии имени ответственного за обновления. Сервер, который подрядчик настроил три года назад и о котором никто не знает, кто его обслуживает, — первое, что ищет злоумышленник. То же самое мы говорили об уязвимости в магазинах Magento: одного патча недостаточно, если он приходит с опозданием. Если вам нужен кто-то, кто проверит ваши серверы или возьмёт на себя их обновление, свяжитесь с нами.
Источники
Частые вопросы
Затрагивает ли мою компанию новая уязвимость GitLab CVE-2026-97229?
Да, если вы запускаете GitLab на собственном сервере на версии 19.2 до 19.2.8, версии 19.3 до 19.3.5 или версии 19.4 до 19.4.2. По словам GitLab, пользователям облачного GitLab.com и клиентам GitLab Dedicated ничего делать не нужно.
До какой версии обновляться?
До 19.4.2, 19.3.5 или 19.2.8 — версий, которые GitLab выпустил 12 октября 2026 года. Если у вас 19.3, переходите сразу на 19.3.5, потому что в 19.3.4 была ошибка, исправленная в 19.3.5.
Останавливается ли GitLab во время обновления?
Сервер с одним узлом недоступен во время установки патча, пока не завершатся миграции базы данных, а многоузловые установки можно обновить без простоя, следуя документированной процедуре GitLab для обновления без простоя. Запланируйте обновление на нерабочее время в тот же день.
На нашем сервере версия старше 19.2. Мы в безопасности?
Эта конкретная критическая уязвимость вас не затрагивает, но политика GitLab ограничивает исправления безопасности текущим выпуском и двумя предыдущими ежемесячными выпусками, поэтому более старая версия больше не получает никаких исправлений безопасности и требует обновления.
