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

Если коротко: при определённом стечении обстоятельств посторонний может запустить свой код на вашем сервере GitLab. Удалённо. Без аккаунта.

А в конце октября стало понятно, что это уже не теория. Alpine Linux написали, что их GitLab реально пытались атаковать через одну из этих уязвимостей.

Так что, если GitLab у вас стоит на своём сервере, мы бы проверили его сегодня, а не «когда руки дойдут».

[1] Обновились, а сервер всё равно уязвим

Историю из Alpine мы перечитали два раза. Сама атака там, честно говоря, не самое интересное.

20 и 21 октября кто-то долбился в их GitLab через CVE-2026-97229, серверные процессы несколько раз падали. Ребята сделали ровно то, что сделал бы любой из нас, и поставили исправленную версию 19.3.6. Потом проверили ещё раз. Сервер всё ещё был уязвим.

Причина нашлась в Ruby. GitLab у Alpine собран своими силами и работает на отдельной версии Ruby, в ней дыра и осталась, потому что обновление GitLab до этого компонента просто не добралось.

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

[2] Чем это грозит бизнесу

Есть соблазн решить, что GitLab это забота программистов. Ну код, ну репозитории. Украдут исходники, неприятно, но не смертельно.

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

Например, возьмём магазин с парой личных кабинетов, один GitLab на всё и автоматический деплой. Кто получил в этом GitLab достаточно прав, может забрать код, а может пойти дальше, к сохранённым доступам. Или влезть в выкладку, и тогда проблема будет уже у покупателей, а не у разработчиков.

Сработает ли такой сценарий у вас, зависит от того, как настроены права и инфраструктура. Поэтому мы бы смотрели на всё, куда GitLab может дотянуться, а не на него одного.

[3] Какие версии под угрозой и что делать

Уязвимостей две:

  • CVE-2026-97229 закрыли 12 октября,
  • CVE-2026-110264 — 21-го октября.

Вторая задевает GitLab CE и ее начиная аж с 7ой версии, так что старые инсталляции тоже в зоне риска.

Версии с исправлениями от 21 октября: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 и 19.5.1.

Мы рекомендуем идти следующим путем. Сначала посмотреть, какая версия реально стоит, и если сборка нестандартная, как у Alpine, отдельно проверить Ruby и прочие зависимости. Потом бэкап. Только после него обновление, причём заранее прикинуть, не отвалятся ли интеграции и CI/CD.

После обновления стоит залезть в логи: подозрительные запросы, падения процессов, пайплайны, которые никто из команды не запускал. И напоследок доступы. Проверить, не утекли ли токены и SSH-ключи, и заодно урезать права тем пользователям и сервисам, у которых их явно больше, чем нужно (это вообще полезно делать время от времени, без всяких CVE).

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

[4] Поможем проверить и обновить GitLab

Если не знаете, какая версия у вас стоит, или не уверены, что октябрьские дыры закрыты, можем подключиться. В SAGIROV.com мы разрабатываем и сопровождаем сайты и веб-сервисы вместе с инфраструктурой вокруг них.

Посмотрим версию и конфигурацию, оценим, насколько всё серьёзно, подготовим и поставим обновление. Потом проверим, что репозитории на месте, сборки собираются и деплой работает. Нужно глубже — разберём доступы, интеграции и логи на предмет следов атаки.

Пишите на hello@sagirov.com с темой «Проверка GitLab» или оставьте заявку на сайте SAGIROV.com.