Атакуващ се е опитал да експлоатира критична уязвимост в GitLab на собствения GitLab сървър на проекта Alpine Linux седмица след като GitLab пусна корекция, съобщиха от Alpine Linux на 28 октомври.
Уязвимостта, CVE-2026-97229 (оценка по CVSS: 10.0), може да позволи на атакуващ да изпълни код на GitLab сървър чрез специално модифициран регулярен израз в конфигурация за CI. От Alpine не са открили доказателства атаката да е била успешна, но не могат да изключат тази възможност, поради което са преизградили сървъра от нулата и са нулирали паролите на всички акаунти.
Корекцията от GitLab представлява пакет от кръпки за Ruby, което GitLab предоставя в собствените си пакети и контейнерни изображения. Контейнерното изображение на GitLab за Alpine използва стандартно Ruby, така че надграждането на сървъра до GitLab 19.3.6 на 22 октомври не е отстранило уязвимостта.
За всеки, който изпълнява GitLab със собствена инсталация на Ruby, компилирана от изходен код или в собствено контейнерно изображение, „надграждането на GitLab не е достатъчно“, посочват от Alpine. Тези сървъри се нуждаят и от Ruby 3.3.13, 3.4.12, 4.0.9 или по-нова версия, а потребителите на изображението alpinelinux/gitlab на Alpine трябва да изтеглят 19.3.6 отново.
Сървърът gitlab.alpinelinux.org хоства aports — хранилището, от което се изграждат пакетите на Alpine. Пакетите, изградени между 20 и 24 октомври, както и рилийзите от 21 октомври, са създадени от промени в aports, проверени спрямо записи извън GitLab, съобщават от Alpine.
Тези издания включват файловете minirootfs, от които се изграждат официалните Docker изображения на Alpine. Alpine разширява проверките до 27 октомври, когато сървърът е бил спрян. Ключовете, с които се подписват пакетите и изданията, никога не са се намирали на сървъра на GitLab.
Как се разви атаката
На 13 октомври Alpine надгради сървъра до GitLab 19.3.4 вместо до 19.3.5, което определя като грешка. Сървърът все още е бил на тази версия, без корекцията от 12 октомври, когато новорегистриран акаунт започва да го сондира на 20 октомври.
Акаунтът е изпратил специално модифицирани CI конфигурации към сървъра на 20 и 21 октомври. Те са сринали работните процеси на GitLab (worker processes) 8 пъти, а основната атака на 21 октомври също така е предизвикала грешки 502 и е довела до провал на CI задачи.
При 4 от тези сривове атакуващият е стигнал до междинен етап на експлоатацията и се е провалил на следващата стъпка, според Alpine. Атакуващият също така е изтеглил контейнерното изображение на GitLab за Alpine, което според Alpine: „подсказва, че са настройвали експлойта спрямо нашата точна компилация“.
Alpine блокира акаунта на 23 октомври. Атакуващият се е върнал на 25 и 26 октомври и се е опитал да проникне отново, но тези опити са били неуспешни, заявяват от Alpine.
На 26 октомври от Alpine установяват, че сървърът все още е уязвим след надграждането му до 19.3.6 на 22 октомври. На следващия ден достъпът до GitLab е спрян за всички с изключение на разработчиците и сървърите за изграждане (build servers), и започва повторното му изграждане.
Преизграждането приключи на 28 октомври. Alpine също така замени секретните ключове на GitLab, а възстановеният сървър работи с Ruby 3.3.13 или по-нова версия, съдържаща корекцията. От Alpine извършват тестове, преди да го отворят отново за публичен достъп.
Какво Alpine може и не може да изключи
От Alpine не откриха индикации кодът на атакуващия да е бил изпълнен на сървъра. Времевите проверки (timing probes) не показаха забавяния; нямаше неочаквани файлове, ключове, куки (hooks) или процеси; и никакви поверителни данни не са били върнати обратно към атакуващия чрез видими за Alpine уеб или API заявки.
Въпреки това пълна сигурност няма. „Успешна експлоатация не би оставила срив или следа в уеб логовете“, заявяват от Alpine. Някои регистрационни файлове (logs) от деня на атаката липсват, включително логовете за фонови задачи и файловата система на стария контейнер, като нито Alpine, нито хостинг доставчикът са записвали изходящите мрежови връзки.
Тъй като доказателствата, необходими за потвърждаване на изпълнението на код, вече не съществуват, Alpine третира сървъра като компрометиран и го преизгради напълно, за да премахне всякакви опорни точки (foothold), които евентуален успешен експлойт би могъл да остави.
Ако атаката е била успешна, на риск може да са били изложени:
- Имейл адреси, имена и IP адреси на всички потребители
- Хешове на пароли
- Секрети за двуфакторна автентикация (2FA), променливи за CI/CD и токени за runner-и
- Идентификационни данни за webhook, интеграции и огледални хранилища (push mirrors)
- Токени за личен достъп (personal access tokens), които се съхраняват като хешове
- Частни хранилища, както и конфиденциални задачи (issues) и заявки за сливане (merge requests)
Освен нулирането на паролите и новите секретни ключове, Alpine не съобщава дали токените за runner-и, CI/CD променливите, токените за достъп или данните за интеграция, съхранявани на сървъра, са били подменени.
За да провери пакетите си, Alpine потвърди, че всяка промяна в aports, добавена между 20 и 22 октомври, е постъпила чрез регистриран push от известен разработчик. Това беше сверено спрямо записи, за които се твърди, че са били недостъпни за атакуващия: копие от хранилището на разработчик и всички 45 сървъра за изграждане. Всеки пакет, компилиран между 20 и 24 октомври, произхожда от промени в aports, както са публикувани на git.alpinelinux.org.
Защо надграждането на GitLab не отстрани проблема
GitLab компилира регулярните изрази в CI конфигурациите чрез Ruby, а дефектът, стоящ зад CVE-2026-97229, се намира в Onigmo — модулът за регулярни изрази, вграден в Ruby.
Изданието на GitLab от 12 октомври отстрани уязвимостта чрез инсталиране на корекции за Ruby вътре в пакета за Linux и контейнерните изображения на GitLab. Собствените коригирани версии на Ruby бяха пуснати на 22 и 23 октомври.
Надграждането на GitLab не променя собственото Ruby на даден сървър, така че инсталация на GitLab със стандартно Ruby остава уязвима, докато самото Ruby не бъде обновено до коригирана версия, както установиха от Alpine.
Коригираните Linux пакети на GitLab и официалните му контейнерни изображения съдържат обновеното Ruby. Инсталация, компилирана от изходен код, или контейнерно изображение, което инсталира Ruby отделно, както беше при Alpine, не получават тази корекция.
Към 29 октомври нито една от публикациите за корекциите на GitLab от 12 и 21 октомври не указва на администраторите на самостоятелно компилирани инсталации да обновят Ruby. Ръководството за самостоятелно компилирана инсталация на GitLab все още посочва Ruby 3.2 като минимална версия, а поддръжката на Ruby 3.2 приключи през април (end of life) и няма да получи корекция.
Кои GitLab сървъри са изложени на риск
В бюлетина за сигурност на GitLab се посочва, че „при определени условия“ уязвимостта би могла да позволи на неавтентикиран потребител да изпълни код на сървъра. За GitLab.com и GitLab Dedicated вече са инсталирани корекции за сигурност.
Rapid7 разработи работещ експлойт в лабораторни условия и публикува код за доказване на концепцията (proof-of-concept) на 13 октомври. Експлойтът изпълни команди с правата на потребителя git на GitLab върху некоригирано официално изображение на GitLab 19.4.1, но същите входни данни не сработиха върху обновеното изображение 19.4.2.
Този експлойт изисква първоначален достъп за запис: атакуващият трябва да запише (commit) зловреден файл .gitlab-ci.yml и файлов път с UTF-8 символи в клон на публичен проект. Това изискване не важи за сървъри, където новите потребители могат свободно да се регистрират и да създават проекти.
При тествания от Rapid7 сценарий „само финалната CI lint заявка е неавтентикирана“. Собствените бележки за засичане на GitLab също посочват, че атакуващият първо трябва да създаде този файлов път чрез стандартните API на хранилището. Rapid7 все още не разполага с информация как атаката в първоначалния доклад до GitLab, който все още е поверителен, заобикаля стъпката със запис.
От Alpine не посочват как CI конфигурациите на атакуващия са достигнали до GitLab или дали нови профили са можели да създават публични проекти на сървъра им.
CVE-2026-97229 не фигурира в каталога с известни експлоатирани уязвимости (Known Exploited Vulnerabilities) на CISA към актуализацията на каталога от 28 октомври.
Какво трябва да направят администраторите на GitLab
Версиите на GitLab от 21 октомври са най-новите за всяко от изброените по-долу разклонения и освен това отстраняват CVE-2026-110264 — отделна уязвимост при регулярните изрази.
| Разклонение | Отстранява CVE-2026-97229 според бюлетина за сигурност на GitLab | Най-нова версия (21 октомври) |
|---|---|---|
| 19.5 | Не е посочено като засегнато | 19.5.1 |
| 19.4 | 19.4.2 | 19.4.3 |
| 19.3 | 19.3.5 | 19.3.6 |
| 19.2 | 19.2.8 | 19.2.9 |
| 19.1, 19.0 и 18.11 | Не са посочени като засегнати | 19.1.9, 19.0.10 и 18.11.13 |
Коя версия коригира уязвимостта на даден сървър зависи от начина, по който е инсталиран GitLab:
- Linux пакетът на GitLab или официалните контейнерни изображения: надградете до най-новата версия за вашето разклонение.
- Инсталации, компилирани самостоятелно, или изображения, които инсталират свой собствен Ruby: надградете GitLab и обновете Ruby до 3.3.13, 3.4.12, 4.0.9 или по-нова версия. Ruby 3.2 няма да получи корекция за сигурност, така че сървърите, работещи с 3.2, трябва да надградят до една от тези версии.
В бюлетина за сигурност на GitLab първоначално беше посочена версия 19.3.4 като коригираща за разклонението 19.3 при публикуването му на 12 октомври. Сега в него се посочва 19.3.5, а 19.3.4 е отбелязана като засегната, така че сървърите, които все още използват 19.3.4, следва да преминат към 19.3.6.
Ако даден сървър не може да бъде надграден веднага, от Rapid7 препоръчват да се ограничи анонимният достъп до публични проекти, да се спре възможността ненадеждни потребители да създават или пишат в публични проекти или да се блокира CI lint маршрутът. Тези мерки покриват единствено вектора на експлоатация на Rapid7 и не коригират уязвимия компилатор на регулярни изрази, посочват от компанията.
GitLab публикува шест правила за засичане на опити за експлоатация срещу самостоятелно управлявани сървъри, написани във формата Sigma. Четири от тях, които GitLab определя като експериментални, следят за враждебни модели в предупрежденията за CI регулярни изрази и GraphQL ciLint заявките, необичайно дълги файлови пътища с не-ASCII символи и доклади за сривове в Ruby, сочещи към Onigmo.
Насоките към тези правила предупреждават, че успешната експлоатация може да не остави срив, и дават следните допълнителни стъпки:
- Проверете за файлове, собственост на потребителя git в /tmp, неочаквани дъщерни процеси на Puma или Sidekiq, изходящи връзки и променени crontab записи или SSH ключове за потребителя git.
- Ако има признаци за изпълнение на код, третирайте сървъра като компрометиран и подменете тайните в gitlab-secrets.json, всички CI/CD променливи, всички токени за runner-и и всички токени за достъп.
- Ограничете кръга от лица, които могат да създават профили и персонални токени за достъп на сървъра.
Какво трябва да направят потребителите на Alpine
Притежателите на профили ще трябва да зададат нова парола чрез „Forgot your password?“ на страницата за вход, когато gitlab.alpinelinux.org заработи отново, съобщиха от Alpine. Освен това са забелязани автоматизирани опити за вход в техния GitLab чрез напасване на идентификационни данни, изтекли от други сайтове, и всеки, който е използвал паролата си от gitlab.alpinelinux.org другаде, трябва да я промени и там.
Потребителите на изображението alpinelinux/gitlab трябва да изтеглят отново alpinelinux/gitlab:19.3.6. Изображението, публикувано на 27 октомври, съдържа Ruby 3.3.13, докато всяко изображение 19.3.6, изтеглено преди тази дата, както и всеки по-стар етикет (tag), остават уязвими.
Собствените пакети на Ruby в Alpine вече разполагат с корекцията: Ruby 3.4.12 за Alpine 3.22, 3.23, 3.24 и edge, както и Ruby 3.3.13 за Alpine 3.21. Изпълнението на apk upgrade я инсталира.
Поддържащите Ruby заявяват, че грешката има значение само за програми, които компилират регулярен израз от текст под контрола на атакуващ, и че настройката Regexp.timeout в Ruby не осигурява защита срещу нея.