Il Git autogestito ha dimostrato il suo prezzo di sovranità

Bastarono undici secondi

CVE-2026-60004 è una falla di code injection in Gitea, l'alternativa autogestita a GitHub usata da team che preferiscono tenere il proprio codice sorgente su server propri anziché su una piattaforma di proprietà statunitense. Il ricercatore Shai Rod, noto come NightRang3r, ha scoperto che un attaccante con il solo accesso di scrittura ordinario a un repository poteva inviare una patch malevola all'endpoint API diffpatch di Gitea, piazzare un hook di Git eseguibile ed eseguire comandi shell arbitrari come account di servizio di Gitea. Con la registrazione aperta attiva per impostazione predefinita in Gitea, quell'accesso non richiede altro che iscriversi come utente normale.

In un attacco documentato, un fornitore di hosting ha segnalato attività insolite su un'istanza Gitea non aggiornata. Un attaccante aveva registrato un account, creato un repository, attivato la catena di sfruttamento, scritto una prova di concetto su un branch Git, scaricato un caricatore di shell e installato un dropper di crypto-mining che ha consumato il 70 per cento della capacità di elaborazione del server, tutto in circa undici secondi. Non è stato installato alcun meccanismo di persistenza; il payload è scomparso al successivo riavvio del container, ma la finestra di esposizione si è chiusa solo perché qualcuno stava osservando.

La cronologia che dovrebbe preoccupare ogni autogestore

Ciò che rende questo caso un avvertimento e non una notizia di patch di routine è quanto poco tempo sia intercorso tra la disponibilità di una correzione e lo sfruttamento reale su larga scala.

È trascorso meno di un mese tra una correzione pubblica e lo sfruttamento confermato, e le istanze ancora colpite erano proprio quelle che non avevano applicato una patch pubblica da settimane. La finestra di tre giorni concessa dalla CISA alle agenzie federali non è una formalità burocratica; riflette quanto velocemente una falla nota e corretta diventi un'arma attiva non appena gli attaccanti notano che esistono ancora obiettivi non aggiornati.

Perché l'Europa ha scelto proprio questi strumenti

Gitea non è diventato popolare nelle organizzazioni europee per caso. Sotto la spinta di NIS2, delle norme sulla residenza dei dati e di una più ampia volontà di ridurre la dipendenza dalle piattaforme cloud di proprietà statunitense, molte aziende europee di medie dimensioni ed enti pubblici hanno scelto Git autogestito proprio perché il loro codice sorgente, le credenziali e le pipeline CI non tocchino mai GitHub, Microsoft o un altro servizio controllato dagli Stati Uniti. Si tratta di una decisione di sovranità legittima e spesso ben motivata, e nulla in questa vulnerabilità cambia la logica di fondo di voler avere il proprio codice su un'infrastruttura controllata direttamente.

Ciò che cambia è il prezzo legato a quella decisione. Una piattaforma gestita assorbe il monitoraggio delle patch, l'irrobustimento delle configurazioni predefinite e la risposta agli incidenti come parte di ciò per cui un cliente paga. Un'istanza autogestita sposta tutto questo sul team interno che l'ha messa in piedi, spesso anni prima, a volte senza che resti nessuno che ricordi se la registrazione aperta sia mai stata disattivata.

Il conto della sovranità si paga nelle finestre di patch

La soluzione pratica qui non è abbandonare l'autogestione. La stessa guida di Gitea per questa falla è concreta e immediata: disattivare la registrazione aperta impostando DISABLE_REGISTRATION su true, richiedere la conferma via email per qualsiasi creazione di account che resti aperta, disattivare la registrazione OpenID se non è in uso attivo, e richiedere l'autenticazione prima di consentire a chiunque di sfogliare le pagine o chiamare l'API. Qualsiasi organizzazione che utilizzi Gitea, o una piattaforma autogestita comparabile, dovrebbe controllare oggi queste quattro impostazioni, non dopo la prossima CVE.

La lezione più ampia riguarda come vengono preventivate le decisioni di sovranità. Scegliere l'autogestione per motivi di residenza dei dati o indipendenza è una decisione reale e difendibile, ma è completa solo se accompagnata dall'impegno per il lavoro continuo di sicurezza operativa che un fornitore gestito avrebbe altrimenti svolto automaticamente. Una patch rimasta non applicata per un mese su un'istanza esposta a internet con registrazione aperta non è un fallimento della decisione di sovranità; è un fallimento nel calcolare quanto quella decisione costi realmente per essere gestita in sicurezza.

Da leggere ora: NCSC impone lo spegnimento per gli agenti IA  |  Se usi Zimbra, il 21 agosto ha cambiato il rischio