Alpine Linux heeft op 28 oktober gemeld dat een aanvaller heeft geprobeerd de eigen GitLab-server te kraken via CVE-2026-97229, een kritieke kwetsbaarheid met de maximale CVSS-score van 10,0 die deze site al eerder behandelde toen GitLab de patch uitbracht. De fout zit in de regex-compiler die GitLab gebruikt om CI/CD-configuraties te verwerken, een integer overflow in Onigmo, de regex-engine die in Ruby is ingebouwd. Een niet-geauthenticeerde aanvaller kan daarmee onder bepaalde voorwaarden code op de server uitvoeren.
Een nieuw geregistreerd account stuurde op 20 en 21 oktober kwaadaardige CI-configuraties naar gitlab.alpinelinux.org, dat nog op GitLab 19.3.4 draaide, zonder de fix die GitLab op 12 oktober had uitgebracht. De pogingen lieten GitLab-workerprocessen acht keer crashen; de hoofdaanval op 21 oktober veroorzaakte ook 502-foutmeldingen en mislukte CI-taken. In vier crashes kwam de aanvaller een stap verder in de exploitketen, maar struikelde telkens bij de volgende stap. Opvallend: de aanvaller downloadde ook Alpine’s eigen GitLab-containerimage, wat erop wijst dat de exploit specifiek op die build was afgestemd. Alpine blokkeerde het account op 23 oktober; nieuwe pogingen op 25 en 26 oktober mislukten.
Dat de aanval niet slaagde, kwam niet doordat Alpine snel had gepatcht. Het tegenovergestelde is waar: Alpine gebruikte op de server de Ruby-versie die standaard met het besturingssysteem meekomt, in plaats van de Ruby die GitLab zelf in zijn Linux-pakketten en containerimages meelevert. GitLab’s fix van 12 oktober zat in die eigen, meegeleverde Ruby, niet in de GitLab-code zelf. Een upgrade naar GitLab 19.3.6 op 22 oktober loste daardoor niets op, want de kwetsbare systeem-Ruby bleef draaien. Alleen toevallig was die systeem-Ruby op dat moment nog te oud om de exploit te laten slagen. Pas op 22 en 23 oktober verschenen gepatchte Ruby-versies: 3.3.13, 3.4.12 en 4.0.9.
Alpine vond geen bewijs dat de aanvaller code heeft uitgevoerd, maar kan dat niet uitsluiten: een geslaagde exploit laat geen crash en nauwelijks sporen in de weblogs achter, en een deel van de logs is verloren gegaan. Het project behandelt de server daarom voor de zekerheid als gecompromitteerd, heeft hem opnieuw opgebouwd en alle wachtwoorden gereset. De sleutels waarmee Alpine-pakketten worden ondertekend, stonden nooit op de GitLab-server.
Beveiligingsbedrijf Rapid7 publiceerde op 13 oktober al een werkend proof-of-concept voor deze kwetsbaarheid, dat werkte tegen een ongepatchte GitLab 19.4.1-installatie.
Voor beheerders van zelfgehoste GitLab-omgevingen is dit een goede reden om niet alleen de GitLab-versie te controleren, maar ook de onderliggende Ruby-installatie, zeker bij zelfgecompileerde setups of containerimages die Ruby los beheren. Een GitLab-upgrade alleen is onvoldoende als de Ruby-laag niet meegaat.
Update 1 november: Alpine Linux meldt dat de herbouw verder ging dan alleen een reset van wachtwoorden. Het team koos er bewust voor om de GitLab-instantie helemaal opnieuw op te bouwen in plaats van de bestaande server te patchen, omdat de ontbrekende logs geen uitsluitsel gaven over wat de aanvaller precies had bereikt. Een controle van de aports-repository, de pakketten en de releases tot en met 27 oktober leverde geen sporen van manipulatie op. Dezelfde dag verscheen een nieuwe containerimage, alpinelinux/gitlab:19.3.6, nu met de gepatchte Ruby 3.3.13 erin verwerkt, de maatregel die bij de eerdere upgrade naar GitLab 19.3.6 nog ontbrak.
Bron: The Hacker News, BleepingComputer
Zelfde kwetsbaarheid
Blijf op de hoogte
Meld je aan voor de nieuwsbrief: spoedalerts bij kritieke dreigingen en een wekelijks overzicht. Geen mail achterlaten? Volg ons dan via RSS.