Kritisk hull i GitLab kan gi sletting av prosjekter uten pålogging

GitLab slapp 17. august 2026 en hurtigretting utenom fast utgivelsesplan, med versjonene 19.2.4, 19.1.6, 19.0.8 og 18.11.11 for både Community Edition og Enterprise Edition. Utgivelsen retter to sårbarheter, begge i GitLabs GraphQL-lag. Den alvorligste, CVE-2026-19478, har fått CVSS 9.4 og alvorlighetsgrad kritisk. GitLab ber alle selvdriftede installasjoner oppgradere umiddelbart. GitLab.com og GitLab Dedicated kjører allerede den rettede versjonen.

Hva som skjer teknisk

GraphQL er et spørrespråk der klienten sender én forespørsel som beskriver nøyaktig hvilke data den vil ha, og der forespørselen kan inneholde direktiver, altså instruksjoner som endrer hvordan spørringen behandles. Begge sårbarhetene ligger i dette laget, men i hver sin del av det. Om CVE-2026-19478 skriver GitLab at et forhold under visse betingelser kunne tillate en uinnlogget bruker å endre eller slette offentlige prosjekter og brukerdata gjennom et GraphQL-direktiv. Feilen er klassifisert som CWE-94, kodeinjeksjon, og vektoren CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H uttrykker angrep over nettet, uten rettigheter og uten medvirkning fra en bruker, med stor skade på integritet og tilgjengelighet. Her er det verdt å merke seg et sprik kildene ikke forklarer: tittelen sier kodeinjeksjon, mens vektoren oppgir bare begrenset tap av konfidensialitet. GitLab navngir verken direktivet eller kodeveien, og opplyser at de tekniske sakene først blir offentlige 90 dager etter utgivelsen.

Den andre sårbarheten, CVE-2026-19650, har CVSS 7.1 og alvorlighetsgrad høy. Den ligger i håndteringen av såkalte multiplex-spørringer, altså flere GraphQL-spørringer pakket i én forespørsel. GitLab skriver at mangelfull validering av forespørselen under visse betingelser kunne tillate en uinnlogget bruker å utføre mutasjoner gjennom GET-forespørsler. En mutasjon er den delen av GraphQL som endrer data, og GET er metoden alle ledd i kjeden behandler som ufarlig. Nettlesere, mellomtjenere og forhåndsvisning av lenker henter GET-adresser fritt, nettopp fordi de ikke skal endre noe. Feilen er klassifisert som CWE-352, forfalskede forespørsler på tvers av nettsteder, og vektoren krever medvirkning fra en bruker. Begge feilene ble meldt gjennom GitLabs program hos HackerOne, av hiimguardian og kreep. Ingen av kildene nevner utnyttelse, og CVE-postene inneholder en vurdering fra CISA som sier at utnyttelse ikke er observert. Det finnes ingen midlertidige tiltak, bare oppgradering.

Hva det betyr for deg som drifter GitLab selv

Skillet i denne saken går mellom deg og dem som bruker GitLab.com. Er dere på den skyleverte tjenesten, er dette allerede håndtert uten at du gjorde noe. Drifter du GitLab selv, er det motsatt: ingen har oppgradert for deg, og det finnes ingen omgåelse du kan sette inn mens du venter. Vår vurdering er at hastverket her ikke kommer fra observert utnyttelse, for den finnes ikke i noen kilde. Det kommer fra at rettingen er offentlig. Fra det øyeblikket en retting er ute, kan hvem som helst sammenligne koden før og etter og finne veien inn selv. GitLab har lagt inn 90 dagers utsettelse på de tekniske detaljene nettopp av den grunn, men koden er ikke hemmelig.

Tenk et øyeblikk på hva en GitLab-installasjon faktisk inneholder. Der ligger kildekoden, byggejobbene, tokenene til produksjonsmiljøet og historikken til alt dere har laget. En feil som kan endre eller slette offentlige prosjekter uten pålogging, treffer altså både tilgjengeligheten til arbeidet og tilliten til at koden er den samme i dag som i går. Er virksomheten din omfattet av NIS2, hører en kodeplattform hjemme blant systemene der du må kunne vise både at oppdateringer settes inn raskt og at endringer i koden kan spores. Har du sikkerhetskopier av GitLab-installasjonen, er dette en god anledning til å bekrefte at de faktisk lar seg lese tilbake, og ikke bare at jobben kjørte.

Berigo anbefaler

• Oppgrader til 19.2.4, 19.1.6, 19.0.8 eller 18.11.11, avhengig av hvilken versjonslinje dere kjører. GitLab oppgir ingen midlertidige tiltak.
• Oppgraderingen krever ingen databasemigrasjoner og skal ifølge GitLab ikke kreve nedetid for installasjoner med flere noder. Bruk det som argument mot å utsette den.
• Sjekk om GitLab-grensesnittet er nåbart fra internett, og begrens det til de nettene som faktisk trenger tilgang.
• Gå gjennom hva som er merket som offentlige prosjekter i installasjonen. Den alvorligste feilen rammer nettopp dem.
• Bekreft at sikkerhetskopien av installasjonen kan leses tilbake, og ikke bare at jobben kjørte uten feil.