Alpine Linux перестроила GitLab после попытки атаки через CVE-2026-97229
Alpine Linux перестроила с нуля свой сервер gitlab.alpinelinux.org, сбросила пароли всех учётных записей и заменила секретные ключи GitLab после попытки эксплуатации CVE-2026-97229 с оценкой CVSS 10.0. Атакующий отправлял подготовленные CI-конфигурации 20 и 21 октября; Alpine не нашла доказательств выполнения кода, но не смогла полностью исключить компрометацию.
Проблема затрагивает обработку регулярных выражений в CI-конфигурациях GitLab. Через специально сформированное выражение злоумышленник при определённых условиях может выполнить код на сервере. Критической деталью инцидента стало то, что обновление GitLab само по себе не всегда устраняет риск.
Почему обновления GitLab оказалось недостаточно
Ошибка находится в Onigmo — движке регулярных выражений, встроенном в Ruby. GitLab исправила уязвимость в своих Linux-пакетах и официальных контейнерах, добавив патч в поставляемый Ruby. Однако образ Alpine использовал стандартный Ruby, поэтому переход сервера на GitLab 19.3.6 22 октября не закрыл уязвимость.
Alpine обнаружила это 26 октября, ограничила доступ к GitLab для разработчиков и серверов сборки, а затем завершила восстановление 28 октября. В перестроенной системе используется Ruby 3.3.13 или новее. Для самостоятельных установок и образов, где Ruby устанавливается отдельно, необходимы GitLab с актуальными исправлениями и Ruby 3.3.13, 3.4.12, 4.0.9 либо более новая версия.
Что известно о попытке эксплуатации
На момент атаки сервер Alpine оставался на GitLab 19.3.4: 13 октября проект обновил его до этой версии вместо 19.3.5. Новая учётная запись начала проверять сервер 20 октября. Её запросы восемь раз аварийно завершали рабочие процессы GitLab, а основная попытка 21 октября вызвала ошибки 502 и сбои CI-задач.
По оценке Alpine, в четырёх случаях атакующий прошёл часть цепочки эксплуатации, но не выполнил следующий шаг. Он также скачал контейнерный образ Alpine GitLab, что, по мнению проекта, указывает на настройку атаки под конкретную сборку. Учётную запись заблокировали 23 октября; попытки вернуться 25 и 26 октября не удались.
Проверка не выявила необычных файлов, ключей, хуков, процессов, задержек в ответах или передачи закрытых данных через доступные веб- и API-журналы. Но часть журналов фоновых задач и файловая система старого контейнера не сохранились, а исходящие сетевые соединения не логировались. Alpine поэтому исходила из сценария возможной компрометации.
Какие действия нужны администраторам
Для Linux-пакетов GitLab и официальных контейнеров следует установить новейший выпуск поддерживаемой ветки. Для самостоятельной сборки или собственного контейнера требуется дополнительно обновить Ruby. Ruby 3.2 уже снят с поддержки и исправления для этой версии не получит.
GitLab опубликовала шесть правил Sigma для поиска попыток эксплуатации на self-managed серверах. Среди признаков — подозрительные предупреждения о регулярных выражениях в CI, запросы GraphQL ciLint, длинные пути с не-ASCII символами и аварийные отчёты Ruby, связанные с Onigmo. При признаках выполнения кода GitLab рекомендует считать сервер скомпрометированным и ротировать секреты из gitlab-secrets.json, переменные CI/CD, токены runner и токены доступа.
Для бизнеса практический вывод заключается в проверке не только версии прикладной платформы, но и зависимостей, встроенных в собственные образы. Если GitLab развернут не из официального пакета или контейнера, мы бы сопоставили версию Ruby с перечнем исправленных релизов, проверили журналы и заранее определили порядок ротации учётных данных и CI-секретов.