GitLab lappet kritisk GraphQL-hull, selvhostede servere må oppdatere selv

GitLab.com og GitLab Dedicated kjører allerede den rettede versjonen. Kjører du GitLab på egen server, gjør du ikke det. Ifølge The Hacker News slapp GitLab 17. august en hastepatch for CVE-2026-19478, som selskapet selv rangerer som kritisk med CVSS-score 9,4.

Hullet lar en angriper uten innlogging endre eller slette offentlige prosjekter og brukerdata via et GraphQL-direktiv, over nettverk og uten at noen trenger å klikke på noe. GitLab har verken navngitt direktivet eller forklart hvilke betingelser som må være oppfylt. Utgivelsen kom utenom den vanlige planen med patcher andre og fjerde onsdag i måneden, fem dager etter en rutinepatch uten kritiske saker.

«GitLab.com og GitLab Dedicated kjører allerede den rettede versjonen. Kunder på GitLab.com og GitLab Dedicated trenger ikke gjøre noe» — GitLab, i sikkerhetsvarselet

Rettelsene ligger i 19.2.4, 19.1.6, 19.0.8 og 18.11.11. Alt fra 18.2 til og med 18.11.10 er rammet, det samme er 19.0 før 19.0.8, 19.1 før 19.1.6 og 19.2 før 19.2.4. Grenene fra 18.2 til 18.10 får ingen fiks selv om de ligger innenfor det rammede området. Samme utgivelse retter CVE-2026-19650, en CSRF-svakhet med score 7,1 i GraphQLs multiplex-håndtering, som til forskjell krever at brukeren gjør noe.

Hva bør du gjøre?

Oppgrader selvhostet GitLab til 19.2.4, 19.1.6, 19.0.8 eller 18.11.11. Oppdateringen innfører ingen nye migrasjoner, og GitLab venter ikke at den krever nedetid på flernode-oppsett. Ligger du på en gren mellom 18.2 og 18.10, finnes det ingen patch for deg i det hele tatt, og eneste vei ut er å hoppe til 18.11.11 eller nyere.

Forspranget er tidsbegrenset. GitLab publiserer de tekniske detaljene 90 dager etter utgivelsen, altså rundt midten av november, og da er oppskriften offentlig. Verken utnyttelse i praksis eller offentlig exploit-kode var kjent per 18. august, så vinduet for å oppdatere i ro og mak er nå.