Gitea CVE-2026-60004: vittima reale segnala spike CPU e dropper

Un amministratore di sistema russo ha pubblicato nei giorni scorsi su Habr il resoconto dettagliato di un attacco alla propria istanza Gitea, sfruttando la vulnerabilità CVE-2026-60004. Il provider di hosting HOSTKEY ha notificato l'anomalia per un utilizzo CPU persistentemente superiore al 70%. Il caso, riportato da The Hacker News, offre una rara finestra su exploitation attiva con impatto operativo concreto: non solo breach teorico, ma throttling del provider e indagine forense su un server compromesso.

Come funziona la vulnerabilità: diffpatch e Git hook

CVE-2026-60004 è una Remote Code Execution con punteggio CVSS 9.8, presente in Gitea dalla versione 1.17 fino alla 1.27.0 inclusa. Il meccanismo, documentato da CISA, è preciso: un attaccante con repository write access invia una patch malevola all'endpoint API diffpatch, pianta un Git hook eseguibile e ottiene l'esecuzione di comandi di shell con i privilegi dell'account servizio di Gitea.

La criticità non sta solo nel meccanismo tecnico, ma nel percorso di accesso. La configurazione di default di Gitea lascia aperte le registrazioni (DISABLE_REGISTRATION=false, REGISTER_EMAIL_CONFIRM=false), consentendo a un visitatore anonimo di creare un account con write access senza alcuna barriera di verifica. La vittima Andrey/@Causelof ha esplicitamente collegato questa impostazione alla compromissione: "The fact that open registration is enabled here is significant precisely because of its connection to the vulnerability".

Il vettore d'attacco nel caso documentato era HTTPS, non SSH esposto. Questo dettaglio è rilevante per gli amministratori che concentrano i controlli su porte non-standard o servizi esposti, trascurando il traffico web ordinario.

"Gitea contains a code injection vulnerability that allows an attacker with repository write access to send a malicious patch to the diffpatch API endpoint to plant an executable Git hook and run shell commands as the Gitea service account" — CISA

Il racconto della vittima: dalla notifica HOSTKEY al dropper

La catena di eventi inizia con una email del provider HOSTKEY, che segnala un utilizzo CPU superiore al 70% sul VPS della vittima. Andrey/@Causelof avvia l'analisi e identifica un processo sospetto con comportamento da dropper: fetch di un payload selezionato in base all'architettura di sistema, download, scrittura su disco ed esecuzione.

La descrizione del comportamento — fetch arch-specific, download, write, run — è quella fornita dalla vittima. The Hacker News ha riportato questa testimonianza come "cryptocurrency-miner-like dropper", ma è un'etichetta giornalistica, non una conferma analitica. La stessa fonte riporta che CISA non ha divulgato dettagli exploitation in the wild né identità di eventuali attacker, e non conferma il payload miner.

Il limite centrale del dossier è qui: la natura esatta del payload next-stage non è verificata. La vittima ha dichiarato esplicitamente: "I do not have confirmed information regarding the mining pool, wallet, miner family, or specific operator". Il claim "miner-like" rimane una descrizione soggettiva basata sul sintomo (spike CPU), non su analisi del codice.

Cosa è verificato e cosa resta oscuro

La distinzione tra fatti documentati e zone d'ombra è fondamentale in questo caso. Elementi confermati: esistenza della vulnerabilità con CVSS 9.8, presenza dal 2019 (versione 1.17), patch disponibile in 1.27.1, inserimento in KEV catalog CISA il 25 agosto 2026, notifica HOSTKEY per spike CPU, configurazione vulnerabile identificata, comportamento dropper descritto con dettaglio tecnico.

Elementi non confermati: natura miner del payload, obiettivi degli attacchi, identità dell'operatore, scala dell'exploitation oltre il caso singolo, esistenza di indicatori di compromissione pubblici, connessione causale tra l'attacco di Andrey e l'aggiunta CISA KEV. The Hacker News riporta che CISA ha indicato come "unclear" chi sia dietro gli attacchi e quali siano i loro obiettivi reali.

Il dossier non specifica inoltre settori target, volumi di istanze compromesse né fornisce IoC utilizzabili per detection. La singolarità della fonte — un post su Habr ripreso da The Hacker News — impone cautela nella generalizzazione: non emerge alcuna sovrapposizione infrastrutturale che colleghi questo caso specifico a campagne più ampie allo stato attuale.

Perché è importante

Il brief non documenta misure correttive specifiche indicate dalla fonte. Ciò che rende questo caso rilevante è invece la combinazione di tre fattori: una vulnerabilità critica con CVSS 9.8, una configurazione di default che espone l'attacco a chiunque, e un impatto operativo misurabile (throttling del provider) che ha forzato la scoperta dell'intrusione.

La tempistica è compressa: CISA ha aggiunto la vulnerabilità al KEV catalog il 25 agosto 2026, con scadenza patch per le agenzie federali USA fissata al 28 agosto 2026 — tre giorni. Questa cadenza riflette la valutazione di rischio attivo, anche se non corredata da dettagli pubblici sull'exploitation.

Il dossier non specifica se la versione patched 1.27.1 risolva anche configurazioni con registrazione aperta, né se la disabilitazione della registrazione anonima costituisca mitigazione sufficiente senza patch. La fonte non affronta questi scenari.

Per gli amministratori di istanze self-hosted, il caso Andrey funge da termometro: il rischio non è astratto, e la scoperta avviene spesso per sintomi operativi (fattura, throttling, alert provider) piuttosto che per detection attiva. La fonte non documenta strumenti o metodologie di rilevamento precoce.

Lettura: la trappola delle impostazioni di default

L'episodio solleva una questione strutturale nel software self-hosted. Gitea, come molte piattaforme open-source orientate alla facilità di adozione, abilita per default funzionalità che in contesti esposti a Internet diventano vettori d'attacco. La combinazione DISABLE_REGISTRATION=false e REGISTER_EMAIL_CONFIRM=false non è tecnicamente una vulnerabilità: è una scelta di progetto che diventa letale in presenza di CVE-2026-60004.

Questa interazione tra configurazione e codice è ciò che rende il caso interessante oltre il singolo incidente. Non si tratta solo di una fall da patchare, ma di un esempio di come le convenienze di onboarding possano trasformarsi in superficie d'attacco quando emergono flaw nel codice applicativo. La vittima ha colto questo nesso; la sua analisi tecnica, pur nei limiti della disponibilità di informazioni, è più sofisticata di molte reazioni post-incident standard.

Resta aperto il problema della visibilità. Senza la notifica HOSTKEY, l'attacco sarebbe potuto persistere: la fonte non indica quanto tempo sia trascorso tra compromissione e scoperta, né se siano disponibili log utili per ricostruzione forense. Questo silenzio è anch'esso un dato.

Fonti

• https://thehackernews.com/2026/08/critical-gitea-rce-actively-exploited.html

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

• https://www.securityweek.com/cisa-warns-of-exploited-gitea-vulnerability/
• https://www.infosecurity-magazine.com/news/australia-exploitation-teamcity/
• https://www.news4hackers.com/cisa-issues-urgent-alert-gitea-security-flaw-exploited/
• https://www.cisa.gov/news-events/alerts/2026/08/25/cisa-adds-one-known-exploited-vulnerability-catalog
• https://podcast.securityweek.com/