GitLab-fejl får maksimal score – selvhostede servere skal opdateres nu

Ifølge GitLabs patchmeddelelse udgav selskabet 12. oktober 2026 versionerne 19.2.8, 19.3.5 og 19.4.2 til Community Edition (CE) og Enterprise Edition (EE) for at rette blandt andet CVE-2026-97229, der har den maksimale CVSS-score på 10,0. Fejlen kan under bestemte betingelser give en uvedkommende mulighed for at køre kode på en selvhostet GitLab-server. GitLab anbefaler øjeblikkelig opdatering af berørte installationer, som organisationer selv driver; GitLab.com er allerede rettet, og GitLab Dedicated kræver ingen lokal patch.

For administratorer er det afgørende at kende både den kørende version og betingelserne for angrebet. I Rapid7s reproduktion krævede angrebet, at en skadelig CI/CD-konfiguration og en sti med UTF-8-tegn kunne lægges i et offentligt projekt. Rapid7 fik kode til at køre på et upatchet CE-image med version 19.4.1, mens samme input ikke virkede på det rettede 19.4.2-image. En almindelig konto kan opfylde forudsætningen på en instans, der tillader selvregistrering og oprettelse af offentlige projekter; udløsningen kræver ikke login.

CI/CD-konfigurationen kan føre til kodekørsel på serveren

Fejlen ligger i kompileringen af regulære udtryk fra en CI/CD-konfiguration. Det særligt udformede udtryk passerer først valideringen, men bliver kompileret igen, når det møder en gyldig sti med en anden tegnkodning. Et heltalsoverløb i beregningen af programmets størrelse kan da danne ugyldige instruktioner i Ruby-processen. I den demonstrerede angrebskæde ender det med, at en kommando kører som GitLabs git-bruger på selve applikationsserveren.

Det forklarer forskellen mellem sårbarhedens score og den adgang, som en angriber skal skaffe i praksis. Den demonstrerede vej kræver mulighed for at skrive den skadelige konfiguration til et offentligt projekt, men den mulighed kan være åben for nyoprettede konti. Begrænsning af selvregistrering og skriverettigheder til offentlige projekter kan indsnævre denne vej, mens opdateringen planlægges. Den ændrer ikke den sårbare kode på serveren.

Versionsmatrix: 19.3.4 er stadig berørt

Impress Watchs gennemgang opregner de berørte versionsintervaller og beskriver en udgivelse med i alt 24 sikkerhedsrettelser. For den kritiske kodekørselsfejl gælder denne matrix for både CE og EE:

• 19.2-grenen: 19.2.0 til 19.2.7 er berørt; 19.2.8 er rettet.
• 19.3-grenen: 19.3.0 til 19.3.4 er berørt; 19.3.5 er rettet.
• 19.4-grenen: 19.4.0 og 19.4.1 er berørt; 19.4.2 er rettet.

Versionsgrænsen gælder uanset, om den selvhostede instans er installeret fra en Linux-pakke, som container eller med Helm. Det er GitLab-versionen på installationen, der skal sammenholdes med matrixen. Ældre grene er ikke opført som berørt af netop denne CVE, men flere af udgivelsens øvrige rettelser omfatter versioner, der ligger før de viste intervaller. En ældre installation bør derfor vurderes mod hele sikkerhedsudgivelsen og sin opgraderingssti.

19.3.5 er målet for 19.3-grenen. GitLabs oversigt regner også 19.3.4 med blandt de berørte versioner. Derudover havde 19.3.4 en særskilt fejl, som påvirkede sider med merge requests, når Ona-integrationen var slået til; den fejl er rettet i 19.3.5. Har en administrator allerede installeret 19.3.4 efter den første omtale af patchen, er det derfor den faktisk kørende version, der skal kontrolleres, før opdateringen afsluttes.

Enkeltserver og klynge kræver forskellige opgraderingsforløb

Rettelsen skal installeres med den metode, der passer til den eksisterende GitLab-installation. Udgivelsen indeholder databasemigreringer. På en enkeltserver medfører de nedetid under opgraderingen, fordi migreringerne skal være færdige, før GitLab kan starte. I en installation med flere noder kan en procedure uden nedetid bruges, hvis miljøet opfylder kravene til load balancering og høj tilgængelighed.

1. Find den version, der faktisk kører, og vælg den rettede udgivelse i den relevante gren. Skal installationen flyttes mellem grene, må planen også omfatte de nødvendige mellemtrin og afsluttede baggrundsmigreringer.
2. Tag en brugbar backup eller et passende snapshot, og sørg for, at konfiguration og hemmeligheder kan gendannes sammen med data. Afsæt et servicevindue til en enkeltserver, så databasemigreringer og kontrol efter genstart kan gennemføres.
3. Opgrader efter installationsmetoden, og kontrollér derefter den kørende version og tjenestens tilgængelighed. I en klynge opgraderes komponenter og noder i den dokumenterede rækkefølge, så migreringerne ikke behandles som uafhængige opgraderinger på hver server.

Proceduren uden nedetid gælder ikke automatisk enhver installation med flere noder. Den forudsætter blandt andet, at trafik kan flyttes fra en node, mens den opdateres, og at de relevante komponenter har høj tilgængelighed. Version 19.3.5 indeholder desuden migreringer, som kan fortsætte efter udrulningen. Deres status er vigtig, hvis installationen efterfølgende skal videre til en anden versionsgren.

GitLab.com og Dedicated kræver ingen lokal patch

Forskellen er, hvem der driver installationen. GitLab.com kører allerede en rettet version, og GitLab Dedicated-kunder skal ikke selv installere denne patch. En virksomhed med sin egen CE- eller EE-instans har derimod fortsat opdateringsansvaret, også når serveren kører hos en ekstern cloududbyder. Her er det den selvhostede GitLab-installation, ikke placeringen af hardwaren, der afgør behovet for handling.

For den administrator, der driver en berørt instans, er arbejdet først afsluttet, når den rettede version kører på de relevante noder, tjenesten er tilgængelig, og de nødvendige migreringer er gennemført.

Læs også:

• Tag backup af GitLab – objektlageret følger ikke altid med arkivet
• Californien forbyder robotfyringer – et menneske skal levere beviset
• Kritisk Atlassian-fejl rammer otte Data Center-produkter – Cloud er lappet