CVE-2026-58053: Kritisk fejl i Gitea act_runner
Fejl i Gitea act_runner lader brugere med adgang til workflows bryde ud af Docker-containere og overtage hele serveren som administrator.
Hvad er det?
CVE-2026-58053 er en kritisk sårbarhed i Gitea act_runner — det program, der kører automatiske opgaver (workflows) i Docker-containere for Gitea, som er et populært selvhostet alternativ til GitHub.
Fejlen opstår, fordi act_runner overfører indstillinger fra en workflows konfigurationsfil direkte til Docker uden at filtrere farlige parametre. Selvom systemet er sat op til at forbyde privilegeret adgang (privileged: false), kan en bruger stadig smugle farlige Docker-flag med, som giver adgang til serverens underliggende styresystem. Resultatet er, at en uprivilegeret bruger kan eskalere til root-adgang på den server, der kører runner-programmet.
Hvem rammer det?
Sårbarheden rammer alle virksomheder og teams, der:
- Kører en selvhostet Gitea-instans med act_runner og Docker-backend
- Bruger CI/CD-pipelines (automatiske byg- og testprocesser) i Gitea
- Giver medarbejdere, freelancere eller eksterne samarbejdspartnere adgang til at oprette eller redigere workflows
Du er ikke ramt, hvis du kun bruger Gitea som kode-arkiv uden act_runner, eller hvis din runner kører med en anden backend end Docker.
Hvad kan ske?
En angriber, der kan køre et workflow på din runner, kan:
- Bryde ud af Docker-containeren og få fuld root-adgang til den underliggende server
- Læse og kopiere alle filer på serveren — herunder kildekode, hemmeligheder, API-nøgler og adgangskoder
- Installere bagdøre eller ondsindet software, der overlever genstart
- Bevæge sig videre i dit netværk fra den kompromitterede server
- Slette eller kryptere data til brug i et ransomware-angreb
Angrebets CVSS-score er 9,9 ud af 10, hvilket afspejler, at skaden kan ramme fortrolighed, integritet og tilgængelighed fuldt ud — og at effekten rækker ud over containeren selv.
Hvor alvorligt er det?
Sårbarheden er vurderet kritisk (9,9/10) af NVD. Det skyldes kombinationen af:
- Netværksbaseret angreb — ingen fysisk adgang nødvendig
- Lav kompleksitet — angrebet er let at udføre
- Kun lav privilegieniveau kræves — en almindelig bruger med workflow-adgang er nok
- Ingen brugerinteraktion — offeret behøver ikke klikke på noget
- Scope-udvidelse — angrebet bryder ud af den isolerede container og rammer hele værtsserveren
CWE-269 (forkert håndtering af privilegier) bekræfter, at kerneproblemet er, at programmet ikke korrekt begrænser, hvad brugere kan bede systemet om at gøre.
Hvad gør jeg nu?
Følg disse trin hurtigst muligt, helst inden for 24-48 timer:
- Afgør om du er ramt: Tjek om du kører Gitea med act_runner og Docker-backend. Kør
act_runner --versionog se om versionen er 0.262.0 eller ældre. - Begræns workflow-adgang midlertidigt: Fjern muligheden for at oprette eller ændre workflows for alle brugere undtagen betroede administratorer, indtil en patch er installeret.
- Opdater act_runner: Installér en patchet version så snart den er tilgængelig fra Giteas officielle udgivelsesside. Følg med på https://gitea.com/gitea/act_runner/releases.
- Gennemgå eksisterende workflows: Tjek om der allerede er workflows med mistænkelige container.options-parametre som
--pid=host,--cap-addeller--security-opt. - Tjek serveren for kompromittering: Gennemgå serverlogfiler for usædvanlig aktivitet, nye brugerkonti eller ukendte processer.
- Overvej alternativ backend: Hvis Docker-backend ikke er strengt nødvendig, kan du midlertidigt skifte til en anden runner-backend som Kubernetes eller bare-metal.
Handl inden for 24-48 timer
Denne sårbarhed er ekstremt alvorlig, fordi den giver en angriber med blot almindelig brugeradgang mulighed for at overtage hele din server. Vores klare anbefaling er at deaktivere eller isolere din act_runner med det samme, hvis du ikke kan garantere, at kun fuldstændig betroede brugere har workflow-adgang. Installer patchen, så snart den er tilgængelig, og undersøg om din server allerede er blevet misbrugt. Kontakt os, hvis du har brug for hjælp til at vurdere din eksponering eller gennemgå dine logfiler.
Tidslinje
Konkrete eksempler
Freelancer overtager udviklingsserver
En ekstern freelancer, der hjælper med et projekt, har adgang til jeres Gitea-arkiv og kan oprette workflows. Freelanceren tilføjer en linje i workflow-konfigurationen med container.options: "--pid=host --cap-add=SYS_ADMIN". Når workflow’et kører, bryder jobcontaineren ud af Docker og giver freelanceren root-adgang til hele udviklingsserveren — inkl. andre projekters kildekode og gemte adgangskoder.
Kompromitteret medarbejderkonto misbruges
En medarbejders Gitea-konto bliver stjålet via phishing. Angriberen logger ind som medarbejderen og opretter et nyt workflow med ondsindede container.options. Næste gang en automatisk pipeline kører — f.eks. ved et planlagt natte-byg — eskalerer angrebet til serverens root-niveau. Angriberen installerer en bagdør og begynder at kortlægge jeres interne netværk, uden at nogen opdager det.
Ransomware via CI/CD-pipeline
En angriber med en standardbrugerkonto på en offentlig Gitea-instans opretter et workflow, der via container-escape opnår root-adgang til serveren. Derfra krypterer angriberen alle data på serveren og kræver løsesum. Da serveren også er forbundet til backup-lageret, krypteres backups ligeledes, inden nogen reagerer.
Ofte stillede spørgsmål
Hvad er Gitea act_runner, og har vi det?
Gitea act_runner er et program, der automatisk udfører opgaver — f.eks. at bygge og teste kode — når nogen skubber ændringer til jeres Gitea-kodearkiv. Det bruges som en del af CI/CD-pipelines (automatiserede udviklingsprocesser). Spørg jeres IT-ansvarlige eller udvikler, om I kører Gitea med act_runner. Hvis I ikke ved, hvad Gitea er, er I sandsynligvis ikke ramt.
Er vi i fare, selvom vi har slået privilegeret tilstand fra?
Ja — og det er præcis det farlige ved denne sårbarhed. Fejlen betyder, at den sikkerhedsindstilling, der skal forhindre privilegeret adgang (privileged: false), omgås. En angriber kan stadig opnå root-adgang på serveren via andre Docker-flag, selvom I troede, I havde lukket hullet. At have slået privilegeret tilstand fra er altså ikke nok beskyttelse her.
Kan en ekstern angriber udnytte dette, eller kræver det intern adgang?
Angrebet kræver, at angriberen har en brugerkonto med adgang til at oprette eller køre workflows på jeres Gitea-instans. Det kan godt være en ekstern person — f.eks. en freelancer, ekstern samarbejdspartner eller en intern medarbejder med ondsindede hensigter. Hvis jeres Gitea-instans er offentlig tilgængelig på internettet, og fremmede kan oprette konti, er risikoen meget høj.
Hvornår kommer der en patch?
Der var på offentliggørelsestidspunktet (28. juni 2026) endnu ikke udgivet en officiel patch. Gitea-teamet er bekendt med problemet, og en rettelse forventes. Hold øje med den officielle udgivelsesside på https://gitea.com/gitea/act_runner/releases. I mellemtiden bør I begrænse adgangen til workflows som beskrevet i handlingsplanen ovenfor.
Hvad er et container-escape, og hvorfor er det farligt?
En Docker-container er som en isoleret boks, der er designet til at holde programmer adskilt fra resten af serveren. Et container-escape betyder, at nogen bryder ud af den boks og får adgang til hele serveren — inkl. alle andre programmer, filer og netværksforbindelser, der kører der. Det svarer til, at en lejer ikke kun får adgang til sin lejlighed, men pludselig har nøglen til hele ejendommen og alle andre lejligheder.
Gælder dette også cloud-hostede Gitea-løsninger som Gitea Cloud?
Sårbarheden er specifik for selvhostede opsætninger, hvor I selv kører act_runner med Docker-backend på jeres egne servere. Hvis I bruger en cloud-managed CI/CD-tjeneste, der håndterer runner-infrastrukturen for jer, er I typisk ikke direkte eksponerede — men I bør bekræfte dette med jeres udbyder. Kontakt dem og spørg direkte, om de anvender Gitea act_runner med Docker-backend, og om de er patchet.
Ramte produkter
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Gitea act_runner with the Docker backend (through act 0.262.0) passes a workflow’s container.options string to the Docker job container’s HostConfig and, when configured with privileged: false, forces only the Privileged flag off while merging options such as –pid=host, –cap-add, and –security-opt unchanged. A user who can run a workflow on a Docker-backed runner can create a job container with host namespaces and broad capabilities and escape to the host as root despite privileged mode being disabled.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.
