Alpine Linux заново развернула свой GitLab-сервер и сбросила пароли пользователей после попытки эксплуатации критической уязвимости CVE-2026-97229. Атака на GitLab затронула инфраструктуру, где хранятся репозитории, код-ревью и CI-задачи дистрибутива, а значит потенциально могла стать входной точкой в цепочку поставки для множества контейнерных окружений.
Попытки взлома происходили 20–21 октября и вызвали восемь падений рабочих процессов GitLab; в четырёх случаях эксплуатация была частично успешной. Как сообщает BleepingComputer, признаков выполнения кода, подмены коммитов, пакетов или релизов команда Alpine Linux не нашла. Но подтвердить, что атакующие точно не получили доступ, тоже не удалось: необходимые логи уже отсутствовали, а данных об исходящих соединениях не оказалось.
Именно эта неопределённость определила реакцию проекта. Вместо точечного восстановления сервисов Alpine Linux выбрала более дорогой и трудоёмкий вариант — полностью пересобрала GitLab-инстанс. Для пользователей это означает обязательную смену паролей. Проект также рекомендует использовать контейнерный образ alpinelinux/gitlab:19.3.6, опубликованный 27 октября и содержащий Ruby 3.3.13 с нужным исправлением.
Уязвимость CVE-2026-97229 получила максимальный уровень критичности. Это integer overflow в компиляторе регулярных выражений Onigmo, который поставляется вместе с Ruby и используется GitLab в механизмах CI/CD. Неаутентифицированный атакующий мог подготовить специальное регулярное выражение в конфигурации пайплайна и при определённых условиях добиться удалённого выполнения произвольного кода на сервере.
В инциденте особенно неприятна не только сама ошибка, но и путь, которым исправление оказалось потеряно по дороге. После публикации патча 12 октября Alpine сначала установила GitLab 19.3.4 вместо исправленной версии 19.3.5. Последующее обновление до 19.3.6 тоже не закрыло дыру полностью: официальный пакет GitLab включал обновлённый Ruby, а в кастомном контейнерном образе Alpine этого изменения не было. Версия приложения сама по себе выглядела актуальной, но фактический состав зависимостей оставался уязвимым.
Для команд, поддерживающих self-hosted GitLab, это хороший антипример проверки патчей по номеру релиза. Если сборка отличается от официальной — используется свой образ, отдельный базовый дистрибутив или переупакованные зависимости, — нужно сверять не только версию GitLab, но и конкретные исправления в поставляемых компонентах. Иначе в отчёте об обновлении появится зелёная галочка, а в CI останется уязвимая библиотека.
Alpine Linux — компактный дистрибутив, который часто используют как основу Docker-образов. Его GitLab хранит, в частности, рецепты сборки aports, из которых создаются пакеты Alpine. Поэтому атака на GitLab в данном случае интересна не только как попытка получить доступ к одному серверу: успешная подмена кода или CI-конфигурации могла бы затронуть дальнейшие сборки и пользователей зависимых образов. Команда обнаружила, что злоумышленники скачивали контейнерный образ GitLab Alpine, что похоже на подготовку к более точной атаке.
Сервер GitLab не содержал ключей подписи, поэтому этот наиболее чувствительный актив, по данным проекта, не мог быть раскрыт через инцидент. Однако при успешной эксплуатации под риском могли оказаться данные пользователей, хеши паролей, секреты двухфакторной аутентификации, CI/CD-переменные, учётные данные интеграций и содержимое приватных проектов. Подтверждений утечки нет, но сброс паролей здесь выглядит не перестраховкой, а нормальной реакцией на утраченные следы расследования.
Главный вывод для российских DevOps-команд прост: атака на GitLab перестаёт быть проблемой только тогда, когда вы можете это доказать логами, сетевой телеметрией и воспроизводимой сборкой. Когда доказательств нет, пересборка инфраструктуры и ротация секретов часто обходятся дешевле, чем попытка угадать, успел ли атакующий сделать следующий шаг.
