Gitea sotto attacco: la RCE critica CVE-2026-60004 è nel catalogo KEV, oltre 8.300 server esposti

Una falla critica nel diffpatch di Gitea

La vulnerabilità CVE-2026-60004 interessa Gitea precedente alla versione 1.27.1 e consente l’esecuzione remota di codice attraverso l’API diffpatch, con l’installazione di un hook Git controllato dall’attaccante. Il bug è stato segnalato dal ricercatore di Salesforce Shai Rod, come riportato da BleepingComputer.

Gitea ha pubblicato la release correttiva 1.27.1 il 27 luglio. Nonostante la patch sia disponibile da diverse settimane, il quadro resta critico: Shadowserver ha individuato 8.393 indirizzi IP vulnerabili alla data del 27 agosto 2026. Il titolo di BleepingComputer parla di oltre 8.300 server esposti; nel corpo dell’articolo il numero sale a quasi 8.400. Il dato puntuale di Shadowserver, 8.393 IP, è quello di riferimento.

La CISA ha inserito la CVE nel Known Exploited Vulnerabilities Catalog il 25 agosto 2026, con scadenza per le agenzie federali civili statunitensi (FCEB) fissata al 28 agosto 2026, in base alla Binding Operational Directive BOD 26-04.

Come funziona tecnicamente l’attacco

La CVE-2026-60004 ha un punteggio CVSS 3.1 di 9.8, considerato critico, con vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H e classificazione CWE-94 (Code Injection). L’advisory GitHub GHSA-rcr6-4jqh-j84m descrive il meccanismo in dettaglio.

Il file services/repository/files/patch.go applica patch controllate dall’attaccante in un clone temporaneo bare condiviso. Inviando due volte la stessa patch si genera una collisione add/add. A quel punto il fallback three-way di Git estrae il percorso indicizzato anche se l’operazione avviene con --cached.

In un clone bare la root del repository coincide con $GIT_DIR. Una voce eseguibile denominata hooks/post-index-change diventa quindi un hook Git attivo. Git invoca l’hook mentre scrive l’indice: il contenuto controllato dal repository esegue comandi arbitrari come utente di sistema Gitea, normalmente git. Nell’advisory viene mostrato un output con uid=1000(git) gid=1000(git) e path temporanea sotto /data/gitea/tmp/.

Un dettaglio rilevante: il valore di ritorno dell’hook non viene propagato alla risposta diffpatch. Il proof of concept allegato salva l’output del comando in oggetti Git e crea un branch con il risultato, così non serve alcuna connessione in uscita. Il risultato viene recuperato tramite smart HTTP autenticato.

La registrazione aperta è necessaria solo per il percorso di attacco senza credenziali pregresse. Con la registrazione aperta predefinita, un visitatore non autenticato può registrarsi, creare un repository e ottenere l’accesso in scrittura necessario. Disabilitare la registrazione aperta blocca quel percorso, ma il rischio rimane per utenti con accesso in scrittura ai repository. Lo script fornito con l’advisory, gitea_diffpatch_rce_poc.py, utilizza un account Gitea già esistente e va eseguito contro istanze di test in cui l’account può creare repository.

Sfruttamento attivo e indicazioni CISA

L’inserimento nel catalogo KEV segnala che la falla non è teorica: è sfruttata in the wild. La CISA non ha ancora fornito dettagli sugli attacchi, ma secondo BleepingComputer la decisione sarebbe stata probabilmente motivata da segnalazioni di sfruttamento con distribuzione di malware di cryptomining su server Gitea non aggiornati.

Per le agenzie federali statunitensi la scadenza per applicare le mitigazioni era il 28 agosto 2026. L’azione richiesta da CISA è applicare le mitigazioni secondo le istruzioni del vendor, in conformità alla BOD 26-04 “Prioritizing Security Updates Based on Risk” e ai “Forensics Triage Requirements”. Per i servizi cloud va seguita la guida BOD 26-04 applicabile oppure va dismesso il prodotto se le mitigazioni non sono disponibili. I responsabili devono valutare l’esposizione internet di ogni asset e garantire l’aderenza alle linee guida BOD 26-04.

Un secondo problema critico: CVE-2026-20896

Non è la prima falla critica recente per Gitea. A luglio, sempre secondo BleepingComputer, attori malevoli hanno abusato di CVE-2026-20896, un’altra vulnerabilità con CVSS 9.8, questa volta nell’immagine Docker ufficiale di Gitea.

La CVE-2026-20896 è classificata CWE-284 (Improper Access Control). Le versioni dell’immagine Docker fino alla 1.26.2 inclusa usano REVERSE_PROXY_TRUSTED_PROXIES=* come impostazione predefinita. Questo consente a qualsiasi IP sorgente di impersonare un utente quando sono abilitati header di autenticazione di reverse proxy come X-WEBAUTH-USER. BleepingComputer la descrive come un authentication bypass che interessa le istanze Gitea con header di autenticazione via reverse proxy abilitati.

La scheda NVD non indica una versione corretta esplicita per CVE-2026-20896. Risulta che le versioni fino alla 1.26.2 sono interessate. In assenza di ulteriori indicazioni, è necessario verificare gli aggiornamenti del vendor per l’immagine Docker.

Che cosa fare

Per CVE-2026-60004 l’unica correzione indicata è aggiornare Gitea alla versione 1.27.1 o successiva. Non risultano workaround ufficiali alternativi nelle fonti consultate. Disabilitare la registrazione aperta riduce l’esposizione al percorso senza credenziali pregresse, ma non elimina il rischio per chi ha accesso in scrittura ai repository.

Chi gestisce un’istanza Gitea esposta su internet dovrebbe verificare subito la versione installata. Il dato Shadowserver di 8.393 IP vulnerabili al 27 agosto indica che migliaia di server non hanno ancora applicato la patch.

Per CVE-2026-20896 occorre controllare gli aggiornamenti dell’immagine Docker ufficiale e, nel frattempo, verificare la configurazione di REVERSE_PROXY_TRUSTED_PROXIES e degli header di autenticazione reverse proxy. La presenza di due vulnerabilità critiche nel giro di poche settimane rende Gitea un bersaglio concreto per chi cerca server di code hosting esposti.