Elf seconden was genoeg

CVE-2026-60004 is een code-injectielek in Gitea, het zelfgehoste alternatief voor GitHub dat wordt gebruikt door teams die hun broncode liever op eigen servers houden dan op een Amerikaans platform. Onderzoeker Shai Rod, bekend als NightRang3r, ontdekte dat een aanvaller met gewone schrijftoegang tot een repository een kwaadaardige patch naar Gitea's diffpatch-API-eindpunt kon sturen, een uitvoerbare Git-hook kon plaatsen en willekeurige shell-commando's kon uitvoeren als het Gitea-serviceaccount. Doordat open registratie bij Gitea standaard is ingeschakeld, is daarvoor niets meer nodig dan een gewone accountaanmelding.

Bij een gedocumenteerde aanval merkte een hostingprovider ongewone activiteit op een verouderde Gitea-instantie op. Een aanvaller had een account geregistreerd, een repository aangemaakt, de exploitketen geactiveerd, een proof-of-concept teruggeschreven naar een Git-branch, een shell-loader gedownload en een crypto-mining-dropper geïnstalleerd die 70 procent van de servercapaciteit opeiste, allemaal binnen ongeveer elf seconden. Er werd geen blijvend mechanisme geïnstalleerd; de payload verdween bij de volgende containerherstart, maar het tijdvenster sloot alleen omdat iemand oplette.

De tijdlijn die elke zelf-hoster zou moeten verontrusten

Wat deze zaak tot een waarschuwing maakt in plaats van routinematig patchnieuws, is hoe weinig tijd er zat tussen een beschikbare oplossing en daadwerkelijke uitbuiting op grote schaal.

DatumGebeurtenis
27 juli 2026Gitea brengt versie 1.27.1 uit, waarmee het lek wordt verholpen
28 juli 2026Formeel beveiligingsadvies gepubliceerd
25 augustus 2026CISA voegt CVE-2026-60004 toe aan haar lijst van bekende uitgebuite kwetsbaarheden
26 augustus 2026Actieve uitbuiting in het wild bevestigd
28 augustus 2026Amerikaanse federale civiele instanties moeten gepatcht hebben

Er verstreek minder dan een maand tussen een publieke oplossing en bevestigde uitbuiting, en de instanties die nog werden geraakt, waren precies de instanties die een al weken publiek beschikbare patch niet hadden toegepast. Het venster van drie dagen dat CISA aan federale instanties gaf, is geen bureaucratische formaliteit; het laat zien hoe snel een bekend, verholpen lek een actief wapen wordt zodra aanvallers merken dat er nog ongepatchte doelen bestaan.

Waarom Europa voor dit soort tools koos

Gitea werd niet toevallig populair bij Europese organisaties. Onder druk van NIS2, regels voor dataresidentie en een bredere drang om de afhankelijkheid van Amerikaanse cloudplatforms te verminderen, kozen veel middelgrote EU-bedrijven en overheidsinstanties bewust voor zelfgehoste Git, zodat hun broncode, inloggegevens en CI-pijplijnen nooit GitHub, Microsoft of een andere Amerikaans gecontroleerde dienst zouden raken. Dat is een legitieme en vaak goed onderbouwde soevereiniteitskeuze, en niets aan dit lek verandert de onderliggende logica van het willen hebben van je eigen code op infrastructuur die je zelf beheert.

Wat wel verandert, is het prijskaartje dat aan die keuze hangt. Een beheerd platform neemt patchmonitoring, het aanscherpen van standaardconfiguraties en incidentrespons op zich als onderdeel van waar een klant voor betaalt. Een zelfgehoste instantie legt dat allemaal bij het interne team dat de instantie ooit heeft opgezet, vaak jaren geleden, soms zonder dat er nog iemand is die zich herinnert of open registratie ooit is uitgeschakeld.

De rekening voor soevereiniteit komt in patchvensters

De praktische oplossing hier is niet om zelf hosten op te geven. Gitea's eigen advies voor dit lek is concreet en direct toepasbaar: schakel open registratie uit door DISABLE_REGISTRATION op true te zetten, verplicht e-mailbevestiging voor elke accountaanmaak die open blijft, zet ongebruikte OpenID-aanmelding uit, en verplicht authenticatie voordat iemand pagina's mag bekijken of de API mag aanroepen. Elke organisatie die Gitea of een vergelijkbaar zelfgehost platform draait, moet deze vier instellingen vandaag controleren, niet pas na de volgende CVE.

De grotere les gaat over hoe soevereiniteitskeuzes worden begroot. Kiezen voor zelf hosten om redenen van dataresidentie of onafhankelijkheid is een echte, verdedigbare keuze, maar ze is alleen compleet als ze samengaat met de toezegging aan het doorlopende operationele beveiligingswerk dat een beheerde leverancier anders automatisch zou hebben gedaan. Een patch die een maand lang onaangebracht bleef op een naar het internet blootgestelde instantie met open registratie, is geen mislukking van de soevereiniteitskeuze; het is een mislukking om in te calculeren wat die keuze werkelijk kost om veilig te draaien.