Атака на GitLab Alpine Linux через CVE-2026-97229: чому оновлення GitLab не усунуло вразливість

Критична вразливість CVE-2026-97229 (CVSS 10.0) у рушії регулярних виразів Onigmo, вбудованому в Ruby, була використана для атаки на GitLab-сервер проєкту Alpine Linux. За даними Alpine Linux, 20–21 жовтня 2026 року новостворений обліковий запис надсилав спеціально сформовані конфігурації CI на сервер gitlab.alpinelinux.org. Ключова проблема: оновлення GitLab до версії 19.3.6 не усунуло вразливість, оскільки образ Alpine використовував стандартний Ruby, а не пропатчений Ruby з офіційних пакетів GitLab. Адміністраторам інсталяцій GitLab, зібраних самостійно, та користувацьких контейнерних образів необхідно оновити і GitLab, і Ruby до версій 3.3.13, 3.4.12 або 4.0.9. Вразливість додано до каталогу CISA KEV 29 жовтня 2026 року. Ми вже писали про цю вразливість раніше.

Суть вразливості

Згідно із записом CVE, CVE-2026-97229 — це переповнення цілого типу (CWE-190) у компіляторі регулярних виразів Onigmo, який Ruby використовує для обробки regex. GitLab компілює регулярні вирази з конфігурацій CI/CD за допомогою Ruby, що дає змогу зловмиснику досягти виконання довільного коду на сервері через спеціально сформований регулярний вираз у файлі .gitlab-ci.yml.

Вразливість зачіпає GitLab CE/EE версій:

• 19.2 до 19.2.8
• 19.3 до 19.3.5
• 19.4 до 19.4.2

Rapid7 відтворила повний ланцюжок експлуатації на офіційному образі GitLab 19.4.1 CE, отримавши виконання команд від імені системного користувача git. На пропатченому образі 19.4.2 той самий вхідний набір не спрацював. Важлива деталь: у протестованому Rapid7 шляху зловмиснику спочатку потрібно розмістити шкідливу конфігурацію CI та файл із символами UTF-8 у шляху в публічному проєкті — лише фінальний запит CI lint є неавтентифікованим. Це обмеження знімається на серверах, де нові користувачі можуть самостійно реєструватися та створювати проєкти.

Хронологія атаки на Alpine Linux

За даними Alpine Linux, події розвивалися так:

• 13 жовтня — Alpine оновила сервер до GitLab 19.3.4 замість 19.3.5 (помилка під час оновлення). Сервер залишився без виправлення, випущеного 12 жовтня.
• 20–21 жовтня — новостворений обліковий запис надіслав спеціально сформовані конфігурації CI, спричинивши 8 аварійних завершень робочих процесів GitLab. У 4 із них зловмисник частково просунувся ланцюжком експлуатації, але не виконав наступний крок. Атака 21 жовтня також викликала помилки 502 та збої завдань CI.
• 22 жовтня — Alpine оновила сервер до GitLab 19.3.6, але вразливість залишилася (стандартний Ruby не було оновлено).
• 23 жовтня — обліковий запис зловмисника заблоковано.
• 25–26 жовтня — зловмисник спробував відновити доступ, але безуспішно.
• 26 жовтня — Alpine виявила, що сервер усе ще є вразливим після оновлення GitLab.
• 27 жовтня — сервер закрили для всіх, окрім розробників і серверів збірки.
• 28 жовтня — сервер повністю перескладено з нуля з Ruby 3.3.13, усі секретні ключі замінено, паролі всіх облікових записів скинуто.

Alpine також зафіксувала, що зловмисник завантажив контейнерний образ GitLab-проєкту, що, на думку Alpine, вказує на підготовку експлойта під конкретну збірку.

Чому оновлення GitLab не допомогло

Це головний урок інциденту. Виправлення GitLab від 12 жовтня включало пропатчений Ruby всередині офіційних Linux-пакетів і контейнерних образів GitLab. Однак Alpine використовувала власний образ із системним Ruby, а не Ruby з пакетів GitLab. Оновлення GitLab не зачіпає окремо встановлений Ruby — вразливий компілятор регулярних виразів Onigmo залишається на місці.

Таким чином, межа виправлення є двовимірною: офіційні пакети GitLab містять пропатчений Ruby, а інсталяції, зібрані самостійно, та користувацькі контейнерні образи потребують окремого оновлення Ruby. Виправлені версії Ruby — 3.3.13, 3.4.12 і 4.0.9 — вийшли 22–23 жовтня. При цьому, станом на 29 жовтня, жоден із бюлетенів GitLab для інсталяцій, зібраних самостійно, не вказував на потребу оновлення Ruby, а посібник зі встановлення з вихідних кодів усе ще зазначав Ruby 3.2 як мінімальну версію. Ruby 3.2 досягла кінця життєвого циклу у квітні 2026 року і не отримає виправлення — користувачам цієї гілки необхідна міграція на підтримувану версію.

Що вдалося і чого не вдалося встановити

Alpine не виявила ознак виконання коду зловмисника: аналіз часових показників не засвідчив затримок, не знайдено сторонніх файлів, ключів, хуків чи процесів. Втім Alpine не може виключити успішну експлуатацію. Як зазначено у звіті проєкту, успішний експлойт не залишає аварійного завершення та слідів у веб-журналах. Частину логів за дні атаки втрачено, включно з логами фонових задач і файловою системою старого контейнера. Ні Alpine, ні її хостинг-провайдер не вели журнал вихідних мережевих з’єднань.

Відсутність вихідної телеметрії та неповнота логів — ключові чинники, які не дали змоги провести повноцінну форензику. Це підвищує значущість шести правил виявлення, опублікованих GitLab для самокерованих інстансів, та хостових перевірок.

Якщо припустити успішну експлуатацію, могли бути скомпрометовані: адреси електронної пошти, імена та IP-адреси користувачів; геші паролів; секрети 2FA; змінні CI/CD і токени раннерів; облікові дані вебхуків, інтеграцій і дзеркал; геші персональних токенів доступу; приватні репозиторії та конфіденційні задачі. Alpine підкреслює, що ключі підпису пакетів і релізів ніколи не зберігалися на GitLab-сервері, а всі зміни в aports за період атаки верифіковано за зовнішніми записами.

Рекомендації

Для адміністраторів GitLab

• Офіційні Linux-пакети або контейнерні образи GitLab: оновіть до останнього релізу для вашої гілки (19.4.2, 19.3.5, 19.2.8 або новіше — релізи від 21 жовтня також закривають окрему вразливість CVE-2026-110264).
• Інсталяції, зібрані самостійно, або образи з власним Ruby: оновіть і GitLab, і Ruby до 3.3.13, 3.4.12 або 4.0.9. Ruby 3.2 виправлення не отримає.
• Тимчасові заходи (за рекомендацією Rapid7): обмежте анонімний доступ до публічних проєктів, забороніть недовіреним користувачам створювати публічні проєкти, заблокуйте маршрут CI lint. Ці кроки закривають лише протестований Rapid7 шлях експлуатації.
• Виявлення: використовуйте шість правил виявлення GitLab у форматі Sigma. Перевірте наявність файлів користувача git у /tmp, неочікуваних дочірніх процесів Puma або Sidekiq, вихідних з’єднань, змінених crontab або SSH-ключів користувача git.
• У разі виявлення ознак виконання коду — вважайте сервер скомпрометованим і проведіть ротацію секретів у gitlab-secrets.json, усіх змінних CI/CD, токенів раннерів і токенів доступу.

Для користувачів Alpine Linux

• Користувачі образу alpinelinux/gitlab мають повторно завантажити тег 19.3.6 — образ від 27 жовтня містить Ruby 3.3.13, попередні завантаження є вразливими.
• Пакети Ruby в Alpine уже виправлено: Ruby 3.4.12 на Alpine 3.22–3.24 та edge, Ruby 3.3.13 на Alpine 3.21. Достатньо виконати apk upgrade.
• Власникам облікових записів на gitlab.alpinelinux.org потрібно буде скинути пароль після повторного відкриття сервера. Якщо пароль використовувався на інших сайтах — його слід змінити і там.

Інцидент Alpine Linux демонструє конкретний і відтворюваний сценарій: оновлення GitLab без оновлення Ruby залишає сервер вразливим до CVE-2026-97229. Адміністраторам інсталяцій GitLab, зібраних самостійно, та користувацьких контейнерних образів необхідно негайно перевірити версію Ruby на своїх серверах і оновити її до 3.3.13, 3.4.12 або 4.0.9 — саме по собі оновлення GitLab цю вразливість не усуває.