Hujumchi Alpine Linux’ning GitLab’ini CVSS 10.0 zaiflik orqali ekspluatatsiya qilishga urindi — Ruby ochiq qoldi

Hujumchi Alpine Linux loyihasining o‘z GitLab serverida muhim GitLab zaifligini ekspluatatsiya qilishga urindi — GitLab tuzatishni e’lon qilganidan bir hafta o‘tib, Alpine Linux 28-oktabrda ma’lum qildi.

CVE-2026-97229 (CVSS balli: 10.0) zaifligi hujumchiga CI konfiguratsiyasidagi maxsus tuzilgan muntazam ifoda orqali GitLab serverida kodni bajarishga imkon beradi. Alpine hujum muvaffaqiyatli bo‘lganiga dalil topmadi, lekin buni inkor eta olmaydi, shuning uchun serverni noldan qayta qurdi va har bir hisob parolini qayta o‘rnatdi.

GitLab tuzatishi — GitLab o‘z paketlari va konteyner tasvirlarida yetkazib beradigan Ruby’ga qo‘llaniladigan yamoqlar to‘plami. Alpine’ning GitLab tasviri standart Ruby’dan foydalangan, shuning uchun 22-oktabrda serverni GitLab 19.3.6 ga yangilash zaiflikni tuzatmadi.

O‘z Ruby’sida, manbadan tuzilgan yoki o‘z konteyner tasvirida GitLab ishlatayotgan har kim uchun, “GitLab’ni yangilash yetarli emas”, deb aytdi Alpine. Bu serverlar ham Ruby 3.3.13, 3.4.12, 4.0.9 yoki undan keyingi versiyalarni talab qiladi, Alpine’ning alpinelinux/gitlab tasviri foydalanuvchilari esa 19.3.6 ni qayta yuklab olishlari kerak.

gitlab.alpinelinux.org serveri Alpine paketlari quriladigan aports omborini joylashtiradi. 20-24-oktabr oralig‘ida va 21-oktabr relizlarida qurilgan paketlar GitLab’dan tashqaridagi yozuvlarga nisbatan tekshirilgan aports o‘zgarishlaridan kelgan, Alpine ma’lum qildi.

Bu relizlar rasmiy Alpine Docker tasvirlari quriladigan minirootfs fayllarini o‘z ichiga oladi. Alpine tekshiruvlarni 27-oktabrgacha kengaytirmoqda — o‘sha kuni server yopildi. Paketlar va relizlarni imzolaydigan kalitlar hech qachon GitLab serverida bo‘lmagan.

Hujum qanday rivojlandi

13-oktabrda Alpine serverni GitLab 19.3.4 ga yangiladi — 19.3.5 o‘rniga, bu xato deb ataldi. Server hali shu versiyada, 12-oktabr tuzatishsiz, yangi ro‘yxatdan o‘tgan hisob 20-oktabrda uni tekshira boshlaganida edi.

Hisob 20 va 21-oktabrda serverga maxsus tuzilgan CI konfiguratsiyalarini yubordi. Ular GitLab ishchi jarayonlarini 8 marta ishdan chiqardi, 21-oktabrdagi asosiy hujum esa 502 xatolariga va CI ishlarining muvaffaqiyatsizligiga sabab bo‘ldi.

Bu ishdan chiqishlarning 4 tasida hujumchi ekspluatatsiyaning bir qismini o‘tib, keyingi qadamda muvaffaqiyatsiz bo‘ldi, Alpine ma’lum qildi. Hujumchi Alpine’ning GitLab konteyner tasvirini ham yuklab oldi, Alpine buni “ular ekspluatatsiyani bizning aniq tuzilishimizga moslashtirayotganini ko‘rsatadi” deb aytdi.

Alpine 23-oktabrda hisobni blokladi. Hujumchi 25 va 26-oktabrda qaytib keldi va qayta kirishga urindi, lekin bu urinishlar muvaffaqiyatsiz bo‘ldi, Alpine aytdi.

26-oktabrda Alpine 22-oktabrda 19.3.6 ga yangilanganidan keyin ham server hali zaif ekanligini aniqladi. Ertasi kuni u GitLab’ni faqat ishlab chiquvchilar va qurilish serverlari uchun ochiq qoldirib, hamma uchun yopdi va qayta qurishni boshladi.

Qayta qurish 28-oktabrda tugadi. Alpine GitLab’ning maxfiy kalitlarini ham almashtirdi, qayta qurilgan server esa tuzatish o‘rnatilgan Ruby 3.3.13 yoki undan yuqori versiyada ishlaydi. Alpine uni jamoatchilikka qayta ochishdan oldin sinovdan o‘tkazmoqda.

Alpine nimani inkor eta oladi va nimani inkor eta olmaydi

Alpine hujumchining kodi serverda bajarilganiga hech qanday belgi topmadi. Vaqt tekshiruvlari hech qanday kechikish ko‘rsatmadi; kutilmagan fayllar, kalitlar, ilgaklar yoki jarayonlar yo‘q edi; va Alpine ko‘ra oladigan hech qanday veb yoki API so‘rovi orqali hujumchiga shaxsiy ma’lumotlar qaytarilmagan.

Lekin u ishonch hosil qila olmaydi. “Muvaffaqiyatli ekspluatatsiya hech qanday ishdan chiqish va veb jurnallarida hech qanday iz qoldirmaydi”, deb aytdi Alpine. Hujum kunidagi ba’zi jurnallar, jumladan fon ish jurnallari va eski konteynerning fayl tizimi yo‘qolgan, Alpine ham, uning hosting provayderi ham chiquvchi tarmoq ulanishlarini qayd etmagan.

Kod bajarilishini tasdiqlash uchun zarur dalillar endi mavjud emasligi sababli, Alpine serverni buzilgan deb hisoblab, muvaffaqiyatli ekspluatatsiya qoldirishi mumkin bo‘lgan har qanday izni yo‘q qilish uchun uni qayta qurdi.

Agar hujum muvaffaqiyatli bo‘lgan bo‘lsa, quyidagilar ochilishi mumkin edi:

• Barcha foydalanuvchilarning elektron pochta manzillari, ismlari va IP manzillari
• Parol xeshlari
• 2FA sirlari, CI/CD o‘zgaruvchilari va runner tokenlari
• Webhook, integratsiya va push mirror ma’lumotlari
• Shaxsiy kirish tokenlari, ular xesh sifatida saqlanadi
• Shaxsiy omborlar, maxfiy masalalar va birlashtirish so‘rovlari

Parolni qayta o‘rnatish va yangi maxfiy kalitlardan tashqari, Alpine serverda saqlangan runner tokenlari, CI/CD o‘zgaruvchilari, kirish tokenlari yoki integratsiya ma’lumotlari almashtirilganmi yoki yo‘qligini aytmadi.

Paketlarini tekshirish uchun Alpine 20-22-oktabr oralig‘ida qo‘shilgan har bir aports o‘zgarishi ma’lum ishlab chiquvchining yozilgan push’i orqali kelganini tasdiqladi. U buni hujumchi yetib bora olmaydigan yozuvlarga nisbatan tekshirdi: ishlab chiquvchining ombor nusxasi va barcha 45 qurilish serverlari. 20-24-oktabr oralig‘ida qurilgan har bir paket gitlab.alpinelinux.org’da e’lon qilingan aports o‘zgarishlaridan kelgan.

Nima uchun GitLab yangilanishi uni tuzatmadi

GitLab CI konfiguratsiyalaridagi muntazam ifodalarni Ruby bilan kompilyatsiya qiladi, CVE-2026-97229 ortidagi xato esa Ruby ichiga o‘rnatilgan muntazam ifoda dvigateli Onigmo’dadir.

GitLab’ning 12-oktabr relizi uni GitLab’ning Linux paketi va konteyner tasvirlari ichidagi Ruby’ni yamash orqali tuzatdi. Ruby’ning o‘z tuzatilgan versiyalari 22 va 23-oktabrda chiqdi.

GitLab yangilanishi serverning o‘z Ruby’sini o‘zgartirmaydi, shuning uchun standart Ruby’da GitLab o‘rnatilishi Ruby o‘zi tuzatilgan versiyaga yangilanmaguncha zaif qoladi, Alpine aniqlaganidek.

GitLab’ning tuzatilgan Linux paketlari va rasmiy konteyner tasvirlari yamalgan Ruby’ni o‘z ichiga oladi. O‘z-o‘zidan kompilyatsiya qilingan o‘rnatish yoki Alpine’nikidek Ruby’ni alohida o‘rnatadigan konteyner tasviri buni olmaydi.

29-oktabr holatiga ko‘ra, GitLab’ning 12 va 21-oktabr yamoq relizlari postlarining hech biri o‘z-o‘zidan kompilyatsiya qilingan o‘rnatish ma’murlariga Ruby’ni yangilashni aytmaydi. GitLab’ning o‘z-o‘zidan kompilyatsiya qilish qo‘llanmasi hali ham Ruby 3.2 ni minimal versiya sifatida ko‘rsatadi, Ruby 3.2 esa aprel oyida hayot tsikli tugagan va tuzatish olmaydi.

Qaysi GitLab serverlari ochiq

GitLab’ning maslahatida aytilishicha, “ma’lum sharoitlarda” zaiflik autentifikatsiyalanmagan foydalanuvchiga serverda kodni bajarishga imkon berishi mumkin. GitLab.com va GitLab Dedicated allaqachon yamalgan.

Rapid7 laboratoriyada ishlaydigan ekspluatatsiya yaratdi va 13-oktabrda isbot-kodini e’lon qildi. Ekspluatatsiya yamalanmagan rasmiy GitLab 19.4.1 tasvirida GitLab’ning git foydalanuvchisi sifatida buyruqlarni bajardi, lekin xuddi shu kiritish yamalgan 19.4.2 tasvirida ishlamadi.

Bu ekspluatatsiya avval yozish huquqini talab qiladi: hujumchi ommaviy loyihaning bir shoxasiga zararli .gitlab-ci.yml faylini va UTF-8 belgilar bilan fayl yo‘lini commit qilishi kerak. Bu talab yangi foydalanuvchilar o‘zlarini ro‘yxatdan o‘tkazib, loyihalar yaratishi mumkin bo‘lgan serverlarda qo‘llanilmaydi.

Rapid7 sinovdan o‘tgan yo‘lda “faqat yakuniy CI lint so‘rovi autentifikatsiyalanmagan”. GitLab’ning o‘z aniqlash qaydlari ham hujumchi avval oddiy ombor API’lari orqali shu fayl yo‘lini yaratishi kerakligini aytadi. Rapid7 hali GitLab’ga berilgan asl hisobotdagi hujum yozish qadamini qanday chetlab o‘tganini bilmaydi, bu hisobot hali ham maxfiy.

Alpine hujumchining CI konfiguratsiyalari GitLab’ga qanday yetib kelganini, yoki yangi hisoblar uning serverida ommaviy loyihalar yaratishi mumkinligini aytmadi.

CVE-2026-97229 28-oktabr yangilanishi holatiga ko‘ra CISA’ning Ma’lum Ekspluatatsiya Qilingan Zaifliklar katalogida yo‘q edi.

GitLab ma’murlari nima qilishi kerak

GitLab’ning 21-oktabr relizlari quyida keltirilgan har bir shoxadagi eng yangi versiyalar bo‘lib, ular alohida regex zaifligi CVE-2026-110264 ni ham tuzatadi.

Serverni qanday o‘rnatilganiga qarab qaysi reliz tuzatadi:

• GitLab’ning Linux paketi yoki rasmiy konteyner tasvirlari: shoxangiz uchun eng yangi relizga yangilang.
• O‘z-o‘zidan kompilyatsiya qilingan o‘rnatishlar yoki o‘z Ruby’sini o‘rnatadigan tasvirlar: GitLab’ni yangilang va Ruby’ni 3.3.13, 3.4.12, 4.0.9 yoki undan yuqori versiyaga yangilang. Ruby 3.2 tuzatish olmaydi, shuning uchun 3.2 ishlatayotgan serverlar shu versiyalardan biriga o‘tishi kerak.

GitLab’ning maslahati 12-oktabrda e’lon qilinganida 19.3 shoxasi uchun tuzatilgan versiya sifatida 19.3.4 ni ko‘rsatgan edi. Endi u 19.3.5 ni ko‘rsatadi va 19.3.4 ni ta’sirlangan deb ro‘yxatga oladi, shuning uchun hali 19.3.4 da bo‘lgan serverlar 19.3.6 ga o‘tishi kerak.

Agar server darhol yangilana olmasa, Rapid7 ommaviy loyihalarga anonim kirishni cheklash, ishonchsiz foydalanuvchilarning ommaviy loyihalarni yaratishi yoki yozishini to‘xtatish, yoki CI lint yo‘lini bloklashni taklif qiladi. Bu qadamlar faqat Rapid7’ning ekspluatatsiya yo‘lini qamrab oladi va zaif muntazam ifoda kompilyatorini tuzatmaydi, deb aytdi kompaniya.

GitLab o‘z-o‘zini boshqaradigan serverlar uchun ekspluatatsiya urinishlarini aniqlash uchun Sigma formatida yozilgan oltita aniqlash qoidasini e’lon qildi. GitLab eksperimental deb belgilagan to‘rttasi CI regexp ogohlantirishlari va GraphQL ciLint so‘rovlari, ASCII bo‘lmagan belgilar bilan g‘ayrioddiy uzun fayl yo‘llari, va Onigmo’ga ishora qiladigan Ruby ishdan chiqish hisobotlaridagi dushman naqshlarini qidiradi.

Bu qoidalar bilan berilgan yo‘riqnoma muvaffaqiyatli ekspluatatsiya hech qanday ishdan chiqish qoldirmasligi mumkinligini ogohlantiradi va quyidagi qo‘shimcha qadamlarni beradi:

• /tmp da git foydalanuvchisi egalik qiladigan fayllarni, Puma yoki Sidekiq’ning kutilmagan bola jarayonlarini, chiquvchi ulanishlarni, va git foydalanuvchisi uchun o‘zgartirilgan crontab yoki SSH kalitlarini qidiring.
• Agar kod bajarilishi belgilari bo‘lsa, serverni buzilgan deb hisoblang va gitlab-secrets.json’dagi sirlarni, barcha CI/CD o‘zgaruvchilarini, barcha runner tokenlarini va barcha kirish tokenlarini aylantiring.
• Serverda kim hisob va shaxsiy kirish tokenlarini yaratishi mumkinligini cheklang.

Alpine foydalanuvchilari nima qilishi kerak

Hisob egalari gitlab.alpinelinux.org qayta ochilganda kirish sahifasida “Parolni unutdingizmi?” orqali yangi parol o‘rnatishlari kerak bo‘ladi, Alpine aytdi. U shuningdek, boshqa saytlardan sizib chiqqan parollar yordamida Alpine GitLab’iga avtomatlashtirilgan kirish urinishlarini ko‘rgan va gitlab.alpinelinux.org parolini boshqa joyda ishlatgan har kim uni o‘sha yerda ham o‘zgartirishi kerak.

alpinelinux/gitlab tasviri foydalanuvchilari alpinelinux/gitlab:19.3.6 ni qayta yuklab olishlari kerak. 27-oktabrda e’lon qilingan tasvir Ruby 3.3.13 ni o‘z ichiga oladi, undan oldin yuklab olingan har qanday 19.3.6 tasviri va har bir eski teg zaif.

Alpine’ning o‘z Ruby paketlari allaqachon tuzatishni o‘z ichiga oladi: Alpine 3.22, 3.23, 3.24 va edge’da Ruby 3.4.12, Alpine 3.21’da esa Ruby 3.3.13. apk upgrade ishga tushirish uni o‘rnatadi.

Ruby’ning ishlab chiquvchilari xato faqat hujumchi nazorat qiladigan matndan muntazam ifoda kompilyatsiya qiladigan dasturlar uchun muhim ekanligini va Ruby’ning Regexp.timeout sozlamasi undan himoya qilmasligini aytadi.

An attacker tried to exploit a critical GitLab vulnerability on the Alpine Linux project's own GitLab server a week after GitLab released a fix, Alpine Linux said on 28 October.

The flaw, CVE-2026-97229 (CVSS score: 10.0), can let an attacker run code on a GitLab server through a crafted regular expression in a CI configuration. Alpine found no evidence that the attack worked but cannot rule it out, so it rebuilt the server from scratch and reset every account's password.

GitLab's fix is a set of patches to the Ruby that GitLab ships in its own packages and container images. Alpine's GitLab image used standard Ruby, so upgrading the server to GitLab 19.3.6 on 22 October did not fix the flaw.

For anyone running GitLab on their own Ruby, built from source or in their own container image, "upgrading GitLab is not enough," Alpine said. Those servers also need Ruby 3.3.13, 3.4.12, 4.0.9 or later, and users of Alpine's alpinelinux/gitlab image need to pull 19.3.6 again.

The server gitlab.alpinelinux.org hosts aports, the repository from which Alpine's packages are built. Packages built from 20 to 24 October, and the 21 October releases, came from aports changes verified against records outside GitLab, according to Alpine.

Those releases include the minirootfs files that the official Alpine Docker images are built from. Alpine is extending the checks to 27 October, when it closed the server. The keys that sign its packages and releases have never been on the GitLab server.

How the Attack Unfolded

On 13 October, Alpine upgraded the server to GitLab 19.3.4 instead of 19.3.5, which it calls a mistake. The server was still on that version, without the 12 October fix, when a newly registered account began probing it on 20 October.

The account sent crafted CI configurations to the server on 20 and 21 October. They crashed GitLab worker processes 8 times, and the main attack on 21 October also caused 502 errors and caused CI jobs to fail.

In 4 of those crashes, the attacker got partway through the exploit and failed at the next step, according to Alpine. The attacker also downloaded Alpine's GitLab container image, which Alpine said: "suggests they were tuning the exploit to our exact build."

Alpine blocked the account on 23 October. The attacker came back on 25 and 26 October and tried to get back in, but those attempts failed, Alpine said.

On 26 October, Alpine found that the server was still vulnerable after its 22 October upgrade to 19.3.6. The next day, it closed GitLab to everyone except its developers and build servers and started rebuilding it.

The rebuild finished on 28 October. Alpine also replaced GitLab's secret keys, and the rebuilt server runs Ruby 3.3.13 or later, which has the fix. Alpine is testing it before reopening it to the public.

What Alpine Can and Cannot Rule Out

Alpine found no sign that the attacker's code ran on the server. Timing probes showed no delays;; there were no unexpected files, keys, hooks, or processes; and no private data was sent back to the attacker via any web or API request that Alpine can see.

It cannot be sure, though. "A successful exploit would leave no crash and no trace in the web logs," Alpine said. Some logs from the attack day are gone, including background job logs and the old container's filesystem, and neither Alpine nor its hosting provider logged outbound network connections.

Because the evidence needed to confirm code execution no longer exists, Alpine treated the server as compromised and rebuilt it to remove any foothold a successful exploit could have left.

If the attack succeeded, these could have been exposed:

• Email addresses, names, and IP addresses of all users
• Password hashes
• 2FA secrets, CI/CD variables and runner tokens
• Webhook, integration and push mirror credentials
• Personal access tokens, which are stored as hashes
• Private repositories, and confidential issues and merge requests

Beyond the password reset and the new secret keys, Alpine has not said whether runner tokens, CI/CD variables, access tokens or integration credentials stored on the server have been replaced.

To check its packages, Alpine confirmed that every aports change added from 20 to 22 October arrived through a recorded push by a known developer. It checked this against records it says the attacker could not reach: a developer's copy of the repository and all 45 build servers. Every package built from 20 to 24 October came from aports changes as published on git.alpinelinux.org.

Why the GitLab Upgrade Did Not Fix It

GitLab compiles the regular expressions in CI configurations with Ruby, and the bug behind CVE-2026-97229 is in Onigmo, the regular expression engine built into Ruby.

GitLab's 12 October release fixed it by patching the Ruby inside GitLab's Linux package and container images. Ruby's own fixed versions came out on 22 and 23 October.

A GitLab upgrade does not change a server's own Ruby, so a GitLab install on standard Ruby keeps the flaw until Ruby itself is updated to a fixed version, as Alpine found.

GitLab's fixed Linux packages and its official container images carry the patched Ruby. A self-compiled install, or a container image that installs Ruby separately as Alpine's did, does not get it.

As of 29 October, neither of GitLab's patch release posts for 12 and 21 October tells administrators of self-compiled installs to update Ruby. GitLab's self-compiled installation guide still lists Ruby 3.2 as its minimum version, and Ruby 3.2 reached end of life in April and will get no fix.

Which GitLab Servers Are Exposed

GitLab's advisory says that, "under certain conditions," the flaw could have allowed an unauthenticated user to run code on the server. GitLab.com and GitLab Dedicated are already patched.

Rapid7 built a working exploit in a lab and published proof-of-concept code on 13 October. The exploit ran commands as GitLab's git user on an unpatched official GitLab 19.4.1 image, but the same input did not run on the patched 19.4.2 image.

That exploit needs write access first: the attacker must commit a malicious .gitlab-ci.yml file and a file path with UTF-8 characters to a branch of a public project. That requirement does not apply on servers where new users can register themselves and create projects.

In Rapid7's tested route, "only the final CI lint request is unauthenticated." GitLab's own detection notes also say the attacker must first create that file path through ordinary repository APIs. Rapid7 does not yet know how the attack in the original report to GitLab, which is still private, avoids the write step.

Alpine has not said how its attacker's CI configurations reached GitLab, or whether new accounts could create public projects on its server.

CVE-2026-97229 was not in CISA's Known Exploited Vulnerabilities catalog as of the catalog's 28 October update.

What GitLab Administrators Should Do

GitLab's 21 October releases are the newest on each branch listed below, and they also fix CVE-2026-110264, a separate regex flaw.

Which release fixes a server depends on how GitLab is installed:

• GitLab's Linux package or official container images: upgrade to the newest release for your branch.
• Self-compiled installs, or images that install their own Ruby: upgrade GitLab and update Ruby to 3.3.13, 3.4.12, 4.0.9, or later. Ruby 3.2 will not receive the fix, so servers running 3.2 need to upgrade to one of those versions.

GitLab's advisory named 19.3.4 as the fixed version for the 19.3 branch when it was published on 12 October. It now names 19.3.5 and lists 19.3.4 as affected, so servers still on 19.3.4 should move to 19.3.6.

If a server cannot be upgraded right away, Rapid7 suggests restricting anonymous access to public projects, stopping untrusted users from creating or writing to public projects, or blocking the CI lint route. Those steps cover only Rapid7's exploit route and do not fix the vulnerable regular expression compiler, the company said.

GitLab has published six detection rules for exploitation attempts against self-managed servers, written in the Sigma format. Four of them, which GitLab marks as experimental, look for hostile patterns in CI regexp warnings and GraphQL ciLint requests, unusually long file paths with non-ASCII characters, and Ruby crash reports that point to Onigmo.

The guidance with those rules warns that a successful exploit can leave no crash, and it gives these further steps:

• Look for files owned by the git user in /tmp, unexpected child processes of Puma or Sidekiq, outbound connections, and changed crontabs or SSH keys for the git user.
• If there are signs of code execution, treat the server as compromised and rotate the secrets in gitlab-secrets.json, all CI/CD variables, all runner tokens and all access tokens.
• Limit who can create accounts and personal access tokens on the server.

What Alpine Users Should Do

Account holders will need to set a new password with "Forgot your password?" on the sign-in page when gitlab.alpinelinux.org reopens, Alpine said. It has also seen automated login attempts against its GitLab using passwords leaked from other sites, and anyone who used their gitlab.alpinelinux.org password elsewhere should change it there.

Users of the alpinelinux/gitlab image should pull alpinelinux/gitlab:19.3.6 again. The image published on 27 October contains Ruby 3.3.13, while any 19.3.6 image pulled before then, and every older tag, is vulnerable.

Alpine's own Ruby packages already have the fix: Ruby 3.4.12 on Alpine 3.22, 3.23, 3.24 and edge, and Ruby 3.3.13 on Alpine 3.21. Running apk upgrade installs it.

Ruby's maintainers say the bug matters only for programs that compile a regular expression from text an attacker controls, and that Ruby's Regexp.timeout setting does not protect against it.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.