En regex-kompilator blev en ingång

GitLab åtgärdade den 12 oktober CVE-2026-97229, ett heltalsöverflöd med CVSS 10,0 i kompilatorn som hanterar reguljära uttryck i CI/CD-pipelinekonfiguration. Under vissa förhållanden, säger GitLabs säkerhetsmeddelande, kunde en oautentiserad användare köra godtycklig kod på GitLab-servern via ett särskilt utformat reguljärt uttryck i en CI/CD-konfiguration.

Meddelandet förklarar inte dessa förhållanden, och det gör ingen av de tre rapporter vi läste heller. En forskare med alias joaxcar rapporterade bristen via GitLabs HackerOne-bugbountyprogram. GitLab.com kör redan den åtgärdade versionen och GitLab Dedicated-kunder behöver inte göra något, men administratörer av egenhanterade instanser måste uppdatera direkt. Enligt heise hade GitLab den 13 oktober inte meddelat några attacker.

UtgåvelinjeSårbarÅtgärdad i
GitLab 19.2Före 19.2.819.2.8
GitLab 19.3Före 19.3.519.3.5
GitLab 19.4Före 19.4.219.4.2

Tre brister med hög allvarlighet åtgärdades i samma utgåva. CVE-2026-92883 (8,7) är en cross-site scripting-brist. CVE-2026-16301 (8,5) låter en användare med rollen Developer köra pipelines på skyddade grenar. CVE-2026-14814 (8,2) kan förgifta cachade svar och potentiellt exponera skyddade miljövariabler. Heise räknar fem brister med hög allvarlighet totalt.

Tre kritiska GitLab-brister på några veckor

CVE-2026-97229 är GitLabs tredje kritiska brist de senaste veckorna, och septemberbristen visade hur snabbt angripare rör sig.

CVECVSSKomponentRapporterad konsekvens
CVE-2026-8570610,0GitLab CE och EELäsning av känsliga data som inloggningsuppgifter och hemligheter utan autentisering, med sondering inom timmar efter offentliggörandet och en CISA-listning en dag efter korrigeringen
CVE-2026-909709,9AI GatewayEn autentiserad användare med åtkomst till Duo Agent Platform kunde ta sig ut ur promptmallens sandlåda och köra kommandon
CVE-2026-9722910,0CI/CD-kompilator för reguljära uttryckKodkörning utan autentisering, utan rapporterade attacker den 13 oktober

Efter septemberbristen gav CISA amerikanska federala myndigheter tre dagar att säkra sina system. Den har sedan november 2021 pekat ut fem GitLab-brister som utnyttjats i attacker, en av dem av ransomware-grupper. Den 13 oktober hade inga attacker mot den nya bristen rapporterats, men septembers takt är den man bör planera efter.

Varför en pipelineserver är värd att angripa

En CI/CD-server sitter mellan källkod och produktion, och därför är kodkörning på den mer värd för en angripare än på de flesta affärsservrar.

Den håller vanligtvis de hemligheter som pipelines behöver för att bygga, testa och driftsätta, som åtkomsttokens och driftsättningsnycklar, och den kan ändra vad som levereras till kunderna. GitLab säger att det har mer än 30 miljoner registrerade användare och att mer än 50 procent av Fortune 100 använder det. Egen drift byter bekvämlighet mot kontroll över var din kod och dina data ligger och flyttar patchansvaret till dig. Det kan vara ett medvetet val för team med krav på dataresidens, och det är också varför leverantörens patchdag blir din deadline.

En 72-timmarsplan för egenhanterade team

Behandla det som ett 72-timmarsjobb för varje instans som kan nås från internet och börja med versionskontrollen.

För det första: Läs av din installerade version och jämför den med 19.2.8, 19.3.5 och 19.4.2, bekräfta sedan de exakta byggnumren i GitLabs eget meddelande. För det andra: Planera uppgraderingen inom 72 timmar, med start i varje instans som kan nås från internet. För det tredje: Begränsa tills dess vem som når servern och vem som får ändra CI/CD-konfigurationsfiler.

För det fjärde: Om du inte kan utesluta exponering, rotera de hemligheter som lagrats som pipelinevariabler när patchen är på plats. För det femte: Prenumerera på GitLabs säkerhetsmeddelanden så att nästa når en människa samma dag. De 72 timmarna är vårt föreslagna fönster och ingen deadline från GitLab.