GitLab-hullet utnyttes i praksis: watchTowr reproduserte det på minutter

Sikkerhetsselskapet watchTowr forteller The Hacker News at det reproduserte GitLab-sårbarheten CVE-2026-19478 innen minutter etter at den ble offentlig kjent, og at det har observert utnyttelse i praksis mot sitt eget honeypot-nettverk. Hullet har CVSS-score 9,4 og er en kodeinjeksjon som lar en uautentisert angriper endre eller slette offentlig tilgjengelige GitLab-prosjekter og skrive om innholdet i dem, uten legitimasjon, uten at noen trenger å klikke på noe og uten en obskur konfigurasjon.

Skadebildet watchTowr beskriver går lenger enn ordlyden i varselet. En angriper kan slette hele repoer, forfalske merge-poster slik at det ser ut som en fiks landet når den aldri gjorde det, og utestenge vedlikeholderne fra prosjektet. Den midterste er den stygge for deg som bygger: sporet i GitLab kan vise en lukket sårbarhet som fortsatt står åpen i koden din.

GitLab har opplyst at hullet kan utnyttes via et GraphQL-direktiv. Rammet er Community Edition og Enterprise Edition i 18.2 før 18.11.11, 19.0 før 19.0.8, 19.1 før 19.1.6 og 19.2 før 19.2.4. Rettelsene ligger i 19.2.4, 19.1.6, 19.0.8 og 18.11.11.

Det som er nytt her er ikke hullet, men hvor fort avstanden fra publisering til utnyttelse forsvant. watchTowr knytter komprimeringen direkte til angripere som bruker KI, og trekker den praktiske konsekvensen for alle som drifter egne tjenester.

«This is the new reality of vulnerability reproduction and exploitation, where AI-enabled attackers are able to compress the time from disclosure to exploitation and 'waiting until the next patch cycle' is often too late» — Jake Knott, principal security researcher i watchTowr

For deg som kjører GitLab på egen maskin til hobbyprosjekter eller som backend for kodeagenter, er dette forskjellen på et vedlikeholdsvindu og en hendelse. Patchesyklusen til GitLab ligger normalt på andre og fjerde onsdag i måneden, og watchTowr sitt poeng er at den kadensen ikke lenger matcher tempoet på angrepssiden. En instans som står åpent mot internett med offentlige repoer er i den eksponerte enden.

Knott gir også et konkret spor å lete etter i loggene før du rekker å oppgradere.

«Organizations that haven't patched yet should hunt through web logs for requests containing '@gl_introduced,' and look for signs of probes or attempted exploitation» — Jake Knott, watchTowr

Hva bør du gjøre?

1. Oppgrader selvhostet GitLab til 19.2.4, 19.1.6, 19.0.8 eller 18.11.11, og ta instansene som er eksponert mot internett først.
2. Søk i webloggene etter forespørsler som inneholder «@gl_introduced». Treff der betyr probing eller forsøk på utnyttelse, og bør behandles som en hendelse selv om du patcher samme dag.
3. Klarer du ikke å patche med én gang, begrens uautentisert tilgang til /api/graphql eller fjern offentlig repo-tilgang helt til oppgraderingen er på plass.