Een aanvaller probeerde een kritieke GitLab-kwetsbaarheid te misbruiken op de eigen GitLab-server van het Alpine Linux-project, een week nadat GitLab een oplossing uitbracht, aldus Alpine Linux op 28 oktober.
De fout, CVE-2026-97229 (CVSS-score: 10.0), kan een aanvaller in staat stellen code op een GitLab-server uit te voeren via een speciaal samengestelde reguliere expressie in een CI-configuratie. Alpine vond geen bewijs dat de aanval succesvol was, maar kan dat niet uitsluiten; daarom bouwde het de server volledig opnieuw op en heeft het elk accountwachtwoord gereset.
De oplossing van GitLab bestaat uit patches voor de Ruby-versie die GitLab in zijn eigen pakketten en containerafbeeldingen meelevert. De GitLab-image van Alpine gebruikte standaard Ruby, dus het upgraden van de server naar GitLab 19.3.6 op 22 oktober verholp de kwetsbaarheid niet.
Voor iedereen die GitLab draait op een eigen Ruby, die vanuit broncode is gebouwd of in een eigen containerimage, geldt volgens Alpine: “het upgraden van GitLab alleen is niet voldoende.” Die servers hebben ook Ruby 3.3.13, 3.4.12, 4.0.9 of later nodig, en gebruikers van Alpine’s alpinelinux/gitlab-image moeten 19.3.6 opnieuw binnenhalen.
De server gitlab.alpinelinux.org herbergt aports, de repository waaruit Alpine’s pakketten worden gebouwd. Pakketten die zijn gebouwd tussen 20 en 24 oktober, en de releases van 21 oktober, zijn volgens Alpine afkomstig van aports-wijzigingen die zijn geverifieerd aan de hand van records buiten GitLab.
Die releases bevatten de minirootfs-bestanden waaruit de officiële Alpine Docker-images worden opgebouwd. Alpine breidt de controles uit tot 27 oktober, de dag waarop het de server sloot. De sleutels die zijn gebruikt om de pakketten en releases te ondertekenen, hebben nooit op de GitLab-server gestaan.
Hoe de aanval verliep
Op 13 oktober gaf Alpine per vergissing de server de upgrade naar GitLab 19.3.4 in plaats van 19.3.5. De server draaide nog steeds die versie, zonder de fix van 12 oktober, toen een nieuw geregistreerd account op 20 oktober begon te onderzoeken.
Het account stuurde speciaal samengestelde CI-configuraties naar de server op 20 en 21 oktober. Die zorgden acht keer voor het crashen van GitLab-workerprocessen, en de hoofdaanval op 21 oktober veroorzaakte ook 502-fouten en deed CI-jobs mislukken.
Bij vier van die crashes kwam de aanvaller gedeeltelijk door de exploit heen maar faalde bij de volgende stap, aldus Alpine. De aanvaller downloadde ook de GitLab-containerimage van Alpine, wat volgens Alpine “suggereert dat ze de exploit afstemden op onze exacte build.”
Alpine blokkeerde het account op 23 oktober. De aanvaller keerde terug op 25 en 26 oktober en probeerde weer binnen te komen, maar die pogingen mislukten, aldus Alpine.
Op 26 oktober ontdekte Alpine dat de server na de upgrade op 22 oktober naar 19.3.6 nog steeds kwetsbaar was. De dag erna sloot het GitLab voor iedereen behalve zijn ontwikkelaars en build-servers en begon met het herbouwen ervan.
De herbouw was voltooid op 28 oktober. Alpine verving ook de geheime sleutels van GitLab en de nieuw gebouwde server draait Ruby 3.3.13 of later, waarin de fix is opgenomen. Alpine test de server voordat deze weer publiekelijk wordt geopend.
Wat Alpine wel en niet kan uitsluiten
Alpine vond geen aanwijzingen dat de code van de aanvaller op de server is uitgevoerd. Tijdsmetingen toonden geen vertragingen; er waren geen onverwachte bestanden, sleutels, hooks of processen; en er werden geen privégegevens teruggestuurd naar de aanvaller via enige web- of API-aanvraag die Alpine kan zien.
Het kan het echter niet met zekerheid uitsluiten. “Een succesvolle exploit zou geen crash en geen spoor in de weblogs achterlaten,” zei Alpine. Sommige logs van de dag van de aanval ontbreken, waaronder achtergrondjoblogs en het oude containerbestandssysteem, en noch Alpine noch zijn hostingprovider registreerden uitgaande netwerkverbindingen.
Omdat het bewijs dat nodig is om code-executie te bevestigen niet langer bestaat, behandelde Alpine de server als gecompromitteerd en heeft het deze opnieuw opgebouwd om elk mogelijk achtergebleven aanknopingspunt van een succesvolle exploit te verwijderen.
Als de aanval wél succes had gehad, hadden de volgende gegevens mogelijk kunnen worden gelekt:
- E-mailadressen, namen en IP-adressen van alle gebruikers
- Wachtwoord-hashes
- 2FA-secrets, CI/CD-variabelen en runner-tokens
- Webhook-, integratie- en push-mirror-gegevens
- Persoonlijke toegangstokens, die als hashes zijn opgeslagen
- Privé-repositories, en vertrouwelijke issues en merge requests
Naast het resetten van wachtwoorden en de nieuwe geheime sleutels heeft Alpine niet gezegd of runner-tokens, CI/CD-variabelen, toegangstokens of integratiegegevens die op de server waren opgeslagen zijn vervangen.
Om zijn pakketten te controleren bevestigde Alpine dat elke aports-wijziging die van 20 tot 22 oktober is toegevoegd, via een vastgelegde push door een bekende ontwikkelaar binnenkwam. Het verifieerde dit aan de hand van records waarvan het zegt dat de aanvaller daar geen toegang toe had: een ontwikkelaarskopie van de repository en alle 45 build-servers. Elk pakket dat tussen 20 en 24 oktober werd gebouwd, kwam van aports-wijzigingen zoals gepubliceerd op git.alpinelinux.org.
Waarom de GitLab-upgrade het niet repareerde
GitLab compileert de reguliere expressies in CI-configuraties met Ruby, en de bug achter CVE-2026-97229 zit in Onigmo, de reguliere-expressie-engine die in Ruby is ingebouwd.
De release van GitLab op 12 oktober verhelpt het probleem door de Ruby die in GitLab’s Linux-pakket en containerimages zit te patchen. De officieel gepatchte Ruby-versies verschenen op 22 en 23 oktober.
Een GitLab-upgrade verandert de Ruby van een server niet, dus een GitLab-installatie op standaard Ruby behoudt de kwetsbaarheid totdat Ruby zelf is geüpdatet naar een gepatchte versie, zoals Alpine ontdekte.
De gepatchte Linux-pakketten van GitLab en de officiële containerimages bevatten de aangepaste Ruby. Een zelf-gecompileerde installatie, of een containerimage die Ruby apart installeert zoals die van Alpine, krijgt die patch niet automatisch.
Op 29 oktober geeft geen van GitLab’s patch release-berichten van 12 en 21 oktober aan dat beheerders van zelf-gecompileerde installs Ruby moeten bijwerken. GitLab’s handleiding voor zelf-gecompileerde installatie vermeldt nog steeds Ruby 3.2 als minimale versie, en Ruby 3.2 bereikte in april end of life en krijgt geen fixes meer.
Welke GitLab-servers zijn blootgesteld
GitLab’s advies zegt dat, “onder bepaalde omstandigheden”, de fout een niet-geauthenticeerde gebruiker in staat had kunnen stellen code op de server uit te voeren. GitLab.com en GitLab Dedicated zijn al gepatcht.
Rapid7 bouwde op 13 oktober een werkende exploit in een labo en publiceerde proof-of-concept-code. De exploit voerde commando’s uit als GitLab’s git-gebruiker op een niet-gepatchte officiële GitLab 19.4.1-image, maar dezelfde invoer werkte niet op de gepatchte 19.4.2-image.
Die exploit vereist eerst schrijf-toegang: de aanvaller moet een kwaadaardig .gitlab-ci.yml-bestand en een bestandspad met UTF-8-tekens naar een branch van een openbaar project committen. Die eis geldt niet op servers waar nieuwe gebruikers zich kunnen registreren en projecten kunnen aanmaken.
In Rapid7’s geteste route is “alleen het laatste CI lint-verzoek niet-geauthenticeerd.” De detectienotities van GitLab zelf zeggen ook dat de aanvaller dat bestandspad eerst moet aanmaken via gewone repository-API’s. Rapid7 weet nog niet hoe de aanval in het oorspronkelijke rapport aan GitLab, dat nog privé is, de schrijfstap vermijdt.
Alpine heeft niet gezegd hoe de CI-configuraties van zijn aanvaller GitLab bereikten, of of nieuwe accounts op zijn server publieke projecten konden aanmaken.
CVE-2026-97229 stond niet in de Known Exploited Vulnerabilities-catalogus van CISA in de update van die catalogus op 28 oktober.
Wat GitLab-beheerders moeten doen
GitLab’s releases van 21 oktober zijn de nieuwste op elke hieronder genoemde branch en verhelpen ook CVE-2026-110264, een aparte regex-fout.
| Branch | Lost CVE-2026-97229 op, volgens GitLab-advies | Nieuwste release (21 oktober) |
|---|---|---|
| 19.5 | Niet als aangetast vermeld | 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 en 18.11 | Niet als aangetast vermeld | 19.1.9, 19.0.10 en 18.11.13 |
Welke release een server repareert, hangt ervan af hoe GitLab is geïnstalleerd:
- GitLab’s Linux-pakket of officiële containerimages: upgrade naar de nieuwste release voor jouw branch.
- Zelf-gecompileerde installs, of images die hun eigen Ruby installeren: upgrade GitLab en werk Ruby bij naar 3.3.13, 3.4.12, 4.0.9 of later. Ruby 3.2 ontvangt de fix niet, dus servers die 3.2 draaien moeten upgraden naar één van die versies.
Toen het advies van GitLab op 12 oktober werd gepubliceerd, noemde het 19.3.4 als de gefixte versie voor de 19.3-branch. Het noemt nu 19.3.5 en vermeldt 19.3.4 als aangetast, dus servers die nog op 19.3.4 draaien moeten naar 19.3.6.
Als een server niet direct kan worden geüpgraded, stelt Rapid7 voor anonieme toegang tot publieke projecten te beperken, te voorkomen dat onbetrouwbare gebruikers publieke projecten kunnen aanmaken of schrijven, of de CI lint-route te blokkeren. Die stappen bestrijken alleen Rapid7’s exploit-route en repareren de kwetsbare reguliere-expressiecompiler niet, aldus het bedrijf.
GitLab heeft zes detectieregels gepubliceerd voor exploitatiepogingen tegen zelf-beheerde servers, geschreven in het Sigma-formaat. Vier daarvan, die GitLab als experimenteel bestempelt, zoeken naar kwaadwillende patronen in CI-regexp-waarschuwingen en GraphQL ciLint-verzoeken, ongewoon lange bestandsnamen met niet-ASCII-tekens, en Ruby-crashrapporten die naar Onigmo wijzen.
De begeleiding bij die regels waarschuwt dat een succesvolle exploit geen crash kan achterlaten, en geeft deze verdere stappen:
- Zoek naar bestanden die eigendom zijn van de git-gebruiker in /tmp, onverwachte child-processen van Puma of Sidekiq, uitgaande verbindingen, en gewijzigde crontabs of SSH-sleutels voor de git-gebruiker.
- Als er tekenen zijn van code-executie, behandel de server dan als gecompromitteerd en roteer de geheimen in gitlab-secrets.json, alle CI/CD-variabelen, alle runner-tokens en alle toegangstokens.
- Beperk wie accounts en persoonlijke toegangstokens op de server kan aanmaken.
Wat Alpine-gebruikers moeten doen
Accounthouders moeten een nieuw wachtwoord instellen via “Forgot your password?” op de aanmeldpagina wanneer gitlab.alpinelinux.org weer opent, aldus Alpine. Het heeft ook geautomatiseerde inlogpogingen tegen zijn GitLab gezien met wachtwoorden die van andere sites zijn gelekt, en iedereen die hetzelfde wachtwoord op gitlab.alpinelinux.org gebruikte als elders, moet dat daar wijzigen.
Gebruikers van de alpinelinux/gitlab-image moeten alpinelinux/gitlab:19.3.6 opnieuw binnenhalen. De image die op 27 oktober is gepubliceerd bevat Ruby 3.3.13, terwijl elke 19.3.6-image die vóór die datum is binnengehaald, en alle oudere tags, kwetsbaar zijn.
De eigen Ruby-pakketten van Alpine hebben de fix al: Ruby 3.4.12 op Alpine 3.22, 3.23, 3.24 en edge, en Ruby 3.3.13 op Alpine 3.21. Het uitvoeren van apk upgrade installeert deze updates.
De beheerders van Ruby zeggen dat de bug alleen relevant is voor programma’s die een reguliere expressie compileren uit tekst die een aanvaller kan controleren, en dat Ruby’s Regexp.timeout-instelling er niet tegen beschermt.
