GitLab 19.3.6 kan tóch kwetsbaar zijn: check je Ruby

Het Alpine Linux-project heeft zijn GitLab-server helemaal opnieuw opgebouwd nadat een aanvaller in oktober probeerde binnen te komen via CVE-2026-97229, het lek met CVSS-score 10,0 in de regex-verwerking van GitLab. Volgens de post-mortem van Alpine kwam die aanval dichtbij. Het leerzaamste deel voor wie GitLab zelf host zit echter niet in de aanval, maar in wat erna gebeurde: Alpine werkte bij naar een versie die de fix hoorde te bevatten, en bleef daarna nog dagen kwetsbaar.

De aanval

Op 20 en 21 oktober stuurde een pas geregistreerd account speciaal vervaardigde CI-configuraties naar de instance, die nog op GitLab 19.3.4 liep en de fix van 12 oktober dus niet had. Acht keer crashte daardoor een GitLab-workerproces; bij vier van die crashes kwam de aanvaller een stap verder in de exploit en strandde hij pas daarna.

De aanvaller downloadde ook het GitLab-containerimage van Alpine zelf, wat erop wijst dat hij de exploit op die exacte build afstemde. Alpine vond geen bewijs dat er code is uitgevoerd, maar kan het niet uitsluiten en behandelde de server daarom als gecompromitteerd. Op 29 oktober ging de herbouwde instance weer open, op versie 19.3.7.

Waarom de upgrade niet hielp

Hier zit de kern van het verhaal. Het lek zit niet in de code van GitLab zelf, maar in Onigmo, de engine voor reguliere expressies die in Ruby zit. GitLab bracht op 12 oktober herstelde versies uit, maar de fix bestaat uit een set patches op de Ruby die GitLab meelevert in zijn eigen pakketten en containerimages. Upstream Ruby kwam pas op 23 oktober met de fix, in 3.3.13, 3.4.12 en 4.0.9.

Het image van Alpine gebruikte standaard Ruby en kreeg die patch dus niet. De upgrade naar GitLab 19.3.6 op 22 oktober sloot het lek niet; pas op 26 oktober ontdekte het team dat de instance nog steeds kwetsbaar was. Het versienummer van GitLab zegt met andere woorden niets zolang je je eigen Ruby meebrengt.

Wat niet te verifiëren was

Gerommel in aports, de pakketten of de releases van 21 oktober vond Alpine niet: elke commit van 20 tot 22 oktober is gecontroleerd tegen bronnen buiten GitLab, namelijk de kloon van een ontwikkelaar en alle 45 buildservers. Ondertekeningssleutels stonden nooit op de GitLab-server.

Zekerheid is er niet, schrijft Alpine, want een geslaagde exploit laat geen spoor in de weblogs achter, een deel van de logs is verdwenen en uitgaande verbindingen werden niet gelogd — ook niet bij de hoster. Was de aanval geslaagd, dan had dit bloot kunnen liggen: namen, e-mailadressen en IP-adressen van alle gebruikers, wachtwoordhashes, 2FA-geheimen, CI/CD-variabelen, runnertokens en privérepository's. Dat Alpine de basis is van talloze Docker-images maakt die onzekerheid extra ongemakkelijk; BleepingComputer noemt de omgeving een aantrekkelijk doelwit voor een supply-chainaanval.

Wat je nu kunt doen

• Draai je GitLab met je eigen Ruby, uit broncode of in een zelfgebouwd containerimage? Dan is GitLab bijwerken niet genoeg. Je hebt ook Ruby 3.3.13, 3.4.12, 4.0.9 of nieuwer nodig.
• Gebruik je het image alpinelinux/gitlab? Haal alpinelinux/gitlab:19.3.6 opnieuw op. Het image van 27 oktober bevat Ruby 3.3.13. Elk 19.3.6-image dat je daarvoor ophaalde, en alle oudere tags, zijn kwetsbaar.
• Had je een account op gitlab.alpinelinux.org? Alle wachtwoorden zijn gereset; stel een nieuw in via "Forgot your password?". Gebruikte je dat wachtwoord ook elders, verander het daar ook: Alpine zag geautomatiseerde inlogpogingen met wachtwoorden die bij andere sites zijn gelekt.
• Denk breder dan GitLab. De bug zit in de regex-engine van Ruby, dus elk programma dat reguliere expressies uit niet-vertrouwde invoer compileert loopt risico. Op Alpine zelf zit de fix al in het ruby-pakket; een apk upgrade is genoeg.