GitHub tettet kritisk RCE etter AI-støttet sårbarhetsfunn

GitHub har offentliggjort en kritisk RCE-sårbarhet i git-push-løpet sitt.

Fakta: GitHub skrev 28. april 2026 at selskapet 4. mars mottok en bug bounty-rapport fra Wiz om CVE-2026-3854. Feilen gjaldt GitHubs interne git-infrastruktur og kunne gi vilkårlig kommandoeksekvering på serveren som håndterte en git push-operasjon. Ifølge GitHub berørte saken GitHub.com, GitHub Enterprise Cloud, Enterprise Cloud med Data Residency, Enterprise Managed Users og GitHub Enterprise Server.

GitHub sier at sikkerhetsteamet reproduserte funnet innen 40 minutter. Da rotårsaken var identifisert klokken 17:45 UTC, ble en fiks for GitHub.com utviklet og rullet ut klokken 19:00 samme dag. Selskapet sier også at den etterfølgende granskingen ikke fant utnyttelse utenfor Wiz-forskernes egen testing, og at ingen kundedata ble hentet ut, endret eller lekket som følge av sårbarheten.

Wiz beskriver funnet hardere: En autentisert bruker kunne utnytte en svakhet i hvordan git push options ble sanitisert, overstyre intern metadata og bryte ut av sandboxing. Forskerne skriver at AI ble brukt i arbeidet med å finne sårbarheten i lukkede binærfiler. Det gjør ikke AI til magi, men det endrer økonomien i sårbarhetsjakt. Flere aktører kan lete raskere i komplekse systemer som tidligere var for dyre å revidere manuelt.

Konsekvensen for norske ledere er praktisk, ikke akademisk. GitHub er ikke bare et utviklerverktøy. For mange virksomheter er det kontrollplanet for kildekode, CI/CD, secrets, pull requests og leverandørtilgang. Når en kritisk feil treffer denne flaten, er spørsmålet ikke bare om GitHub responderte raskt. Spørsmålet er om egen organisasjon vet hvilke GitHub Enterprise Server-instanser som finnes, hvilken versjon de kjører, hvem som har push-tilgang, og hvor raskt en nødpatch faktisk kan rulles ut.

GitHub.com-kunder trenger ifølge GitHub ikke gjøre noe for selve plattformfiksen. GitHub Enterprise Server-kunder må derimot oppgradere til patched supported releases. GitHub lister blant annet 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 eller nyere. Det bør behandles som en prioritet for sikkerhet og drift, ikke som vanlig backlog.

Vurdering: Den viktigste lederlæringen er responstid. GitHub viser en sterk incident-respons med validering, patch og forensics på timer. Samtidig viser saken at lukkede, interne kontrollplan ikke er skjermet fra AI-støttet sikkerhetsanalyse. Det løfter kravene til asset inventory, patch-SLA, logging og leverandørdialog.

Rådet til CIO og CISO: Sjekk GHES-versjoner i dag. Bekreft at push-tilgang er strengt begrenset. Se etter egne avvik fra GitHubs anbefalte logging og review av tilgangslogger. Ta også saken inn i neste leverandørstyringsmøte: Hvor raskt får dere kritiske sikkerhetsvarsler, hvem eier beslutningen, og finnes det en testet nødprosess for utviklerplattformen?

Kilder: GitHub Security Blog, 28. april 2026: https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/. Wiz Research, 28. april 2026: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854.