Angripere kjører kommandoer på Gitea-tjenere ved å sende den samme patchen to ganger

CISA førte CVE-2026-60004 opp i katalogen over kjente utnyttede sårbarheter 25. august 2026, og bekrefter med det at sårbarheten i Gitea blir utnyttet i angrep. Gitea varslet om feilen 28. juli og rettet den i versjon 1.27.1. Alle utgaver fra og med 1.17 og fram til 1.27.1 er berørt. En bruker med skrivetilgang til et repositorium kan sende inn en manipulert patch og få kjørt skallkommandoer som den systemkontoen Gitea kjører under. Er åpen registrering slått på, rekker det å opprette en konto og et repositorium for å skaffe seg den tilgangen.

Mekanismen ligger i endepunktet diffpatch. Sendes den samme patchen to ganger, kolliderer den med seg selv, og Git løser kollisjonen ved å skrive filen ut på disk selv om operasjonen var bedt om å holde seg i indeksen. Klonen er bar, så rotkatalogen er den samme katalogen Git bruker til sitt eget, og filen hooks/post-index-change blir dermed en aktiv git-hook som kjøres som systemkontoen til Gitea. Gitea opplyser at eksempelkoden legger resultatet i git-objekter og en egen gren i stedet for å sende det ut av tjeneren, så angrepet trenger ingen utgående forbindelse. Feilen er klassifisert som kodeinjeksjon, CWE-94, og sikkerhetsvarselet gir den 9,8 av 10 etter CVSS 3.1.

Konto med skrivetilgang Åpen registrering holder Samme patch to ganger Sendt til diffpatch Kommandoer kjøres Som systemkontoen Den doble innsendingen gjør hooks/post-index-change til en aktiv git-hook. CVE-2026-60004 er rettet i Gitea 1.27.1 og katalogført av CISA 25. august.
Figur: Forløpet slik Gitea beskriver det i sikkerhetsvarselet. Åpen registrering er bare nødvendig for veien inn uten konto fra før.

Hva det betyr for deg som drifter Gitea selv

Har du en Gitea-tjener stående, er tiden for planlagt vedlikehold ute. Oppføringen hos CISA betyr at noen allerede utnytter feilen, og datoen i katalogen sier bare når CISA førte den opp, ikke når angrepene begynte. Vår vurdering er at en selvdriftet Gitea er et fristende mål uansett hvor liten installasjonen er. Kildekoden ligger der, nøklene i app.ini ligger der, og systemkontoen kommer som regel til begge deler.

Innstillingen som avgjør hvor eksponert du er, heter åpen registrering. Står den på, og tjeneren svarer fra internett, trenger ingen å skaffe seg et passord først. Avstanden fra en tilfeldig besøkende til kommandokjøring på tjeneren er da tre helt vanlige handlinger i grensesnittet. Spørsmålet vi mener du bør stille i dag, er ikke om noen har forsøkt. Det er hva systemkontoen din faktisk kommer til, dersom noen har lyktes. Gitea oppgir selv at app.ini, databasekoblingen, de monterte repositoriene og påloggingene til integrasjoner ligger innenfor rekkevidde.

Berigo anbefaler

  • Oppgrader til Gitea 1.27.1 eller nyere. Alt fra og med 1.17 er berørt.
  • Slå av åpen registrering på tjenere som svarer fra internett, med mindre du har en god grunn til å la den stå på.
  • Gå gjennom hvem som har skrivetilgang til repositoriene, og ta bort tilgangen der den ikke lenger trengs.
  • Se etter filer under hooks i repositoriene på tjeneren, og etter grener og git-objekter du ikke kan gjøre rede for.
  • Har tjeneren stått uoppdatert og åpen mot internett, behandle den som mulig kompromittert. Bytt nøklene i app.ini og passordet til databasen.

Sikkerhet som forstås, styres og virker.

La oss hjelpe dere å gjøre sikkerhet til et fortrinn, ikke en kostnad. Ta kontakt for en uforpliktende samtale om hvor virksomheten står, og hva som bør prioriteres først.

Ta kontakt