AI-støttet jakt fant RCE-kjede i GitLab

Depthfirst har publisert en detaljert analyse av en sårbarhetskjede som traff GitLab via en Ruby-avhengighet. Saken er teknisk, men styringspoenget er enkelt: selv språk som oppfattes som minnesikre kan trekke inn native C-kode som ligger dypt i leverandørkjeden. Når den koden blir tilgjengelig fra en vanlig webfunksjon, kan risikoen bli kritisk.

Ifølge Depthfirst analyserte selskapets system Ruby-gemmen Oj, en rask JSON-parser med mye C-kode. Systemet løftet frem 18 prioriterte sårbarheter, hvorav sju var minnesikkerhetsfeil. To av dem ble satt sammen til en kjede: en out-of-bounds write og en heap-pointer-lekkasje. Kombinert med GitLabs bruk av Oj i notebook-diff kunne dette gi remote code execution på en standard GitLab-installasjon.

Depthfirst oppgir at kjeden påvirket GitLab CE og EE i versjonene 15.2.0 til 18.10.7, 18.11.0 til 18.11.4 og 19.0.0 til 19.0.1, og at GitLab publiserte patcher etter rapportering. Detaljene er en nyttig påminnelse for CISO-er: angrepsflaten er ikke bare applikasjonskoden dere eier. Den ligger også i parsere, biblioteker, native extensions og funksjoner som sjelden regnes som sikkerhetskritiske.

Kjernen i saken er Jupyter Notebook-diff. En .ipynb-fil er JSON, og GitLab gjør den mer lesbar i code review. For å vise forskjeller mellom to notebook-versjoner må GitLab parse innholdet. Det er denne parseveien Depthfirst fulgte fra GitLab-funksjonen og ned til Oj. En tilsynelatende uskyldig diffvisning ble dermed inngangen til lavnivårisiko.

For norske virksomheter som bruker GitLab selvhostet eller i regulerte miljøer, er første læring operasjonell: patch raskt, og behandle utviklerplattformen som kritisk infrastruktur. GitLab er ofte koblet til kildekode, hemmeligheter, CI/CD, deploynøkler og interne systemer. Et hull i utviklerplattformen kan bli et hull i hele endringskjeden.

Den andre læringen handler om AI i sikkerhetsarbeid. Depthfirst fremstiller funnet som resultat av et AI-støttet system som prioriterer og kobler funn mot reell produktpåvirkning. Det er mer interessant enn enda en påstand om at AI finner bugs. Verdien ligger i å gå fra statisk funn til utnyttbar vei i et faktisk produkt. Det er der mange vanlige skannere fortsatt feiler.

Samtidig bør ledere lese saken nøkternt. Dette betyr ikke at AI nå kan erstatte sikkerhetsteamet. Det betyr at sikkerhetsteamet får nye verktøy som kan grave dypere og raskere i avhengigheter, native kode og sjeldne kjøreveier. Men funnene må fortsatt valideres, prioriteres, rapporteres og omsettes i patch, deteksjon og risikobeslutninger.

For styret er dette et godt eksempel på hvorfor software supply chain-risiko ikke kan reduseres til en SBOM-fil i en mappe. SBOM er startpunktet. Virksomheten må vite hvilke avhengigheter som faktisk er reachable, hvilke som kjører i privilegerte prosesser, hvilke inputflater som treffer dem, og hvordan en kritisk patch rulles ut uten å stoppe utviklingen.

Praktisk bør CISO be om tre ting etter en slik sak. Først en oversikt over selvhostede GitLab-installasjoner og patchstatus. Deretter en vurdering av native extensions i kritiske applikasjoner, særlig parsere og filformatbehandling. Til slutt en plan for AI-støttet sårbarhetsjakt som supplement til SAST, DAST og dependency scanning.

Saken viser hvor neste bølge av sikkerhetskonkurranse kommer. Angripere og forsvarere får bedre verktøy til å finne dype feil. Forskjellen blir ikke hvem som har en scanner, men hvem som klarer å koble funn til produktpåvirkning, patchtempo og kontroll på utviklerplattformen.

Kilder og medier

Kilde: Depthfirst, "Going depthfirst: Achieving GitLab RCE via Two Ruby Memory Corruption Vulnerabilities", publisert 24. juli 2026. Primærkilde: https://depthfirst.com/research/going-depthfirst-achieving-gitlab-rce-via-two-ruby-memory-corruption-vulnerabilities Kildekreditering: Depthfirst beskriver egen forskning, rapportering til GitLab og den tekniske kjeden via Oj og notebook-diff. Versjonsangivelsene er hentet fra samme primærkilde. Thumbnail: OpenAI Image 2 / hogby.ai