Gitea: rilevata vulnerabilità critica CVE-2026-60004, aggiornamento immediato alla versione 1.27.1

Introduzione

Il 28 luglio 2026 il team di Gitea ha pubblicato un advisory di sicurezza per una grave vulnerabilità che colpisce le versioni dalla 1.17 fino alla 1.27.0 della piattaforma Git self-hosted. La falla, identificata come CVE-2026-60004 e valutata con un CVSS di 9.8 (critico), consente l’esecuzione di comandi arbitrari sul server sfruttando l’API /diffpatch. La scoperta è stata fatta dal ricercatore Shai Rod (NightRang3r), che ha anche rilasciato pubblicamente un proof-of-concept. La correzione è stata integrata il 26 luglio e resa disponibile il 27 luglio con il rilascio della versione 1.27.1. Le istanze Gitea Cloud sono state aggiornate automaticamente; tutti gli amministratori di istanze on-premise devono applicare l’aggiornamento con la massima urgenza.

Analisi tecnica

Il punto debole risiede nella gestione delle patch applicate tramite l’endpoint API /diffpatch. Durante l’elaborazione, Gitea esegue un clone temporaneo di tipo bare del repository di destinazione. L’attaccante può inviare due volte la stessa patch: ciò forza un conflitto di tipo three-way merge, innescando la scrittura di un hook Git eseguibile – denominato post-index-change – all’interno della directory hooks del clone bare. Git, per comportamento predefinito, esegue qualsiasi script presente in quella directory. In questo modo un utente malintenzionato può iniettare codice arbitrario che verrà eseguito con gli stessi privilegi dell’account di servizio Gitea.

Per sfruttare la vulnerabilità è necessario essere autenticati e disporre di permessi di scrittura su almeno un repository. Tuttavia, la configurazione standard di Gitea prevede la registrazione aperta senza necessità di approvazione: chiunque può creare un account e un proprio repository, rendendo l’attacco di fatto eseguibile anche da soggetti esterni completamente privi di credenziali pregresse. La complessità di sfruttamento è bassa e non richiede interazione con altri utenti.

Impatto

Un attaccco riuscito permette l’esecuzione remota di codice (RCE) come utente di sistema Gitea. Questo consente di leggere variabili d’ambiente, rubare credenziali del database, token OAuth, chiavi SSH dei repository e accedere a qualsiasi file o servizio di rete visibile dal server. L’infrastruttura è a rischio di compromissione laterale completa. La gravità critica è giustificata dall’abbinamento di sfruttabilità remota, bassi privilegi richiesti e assenza di interazione utente.

Mitigazione

• Azione prioritaria: aggiornare immediatamente Gitea alla versione 1.27.1 o superiore. La patch modifica il processo di patching convertendo il clone temporaneo da bare a non-bare, eliminando così la possibilità di iniezione dell’hook malevolo.
• Contenimento temporaneo: disabilitare la registrazione aperta (impostando REGISTRATION_DISABLED = true o equivalente) impedisce a nuovi utenti ostili di creare account e repository. Tale misura non corregge la vulnerabilità e non protegge da utenti già registrati in possesso di permessi di scrittura.
• Riduzione parziale del rischio: montare il filesystem utilizzato per i temporanei con l’opzione noexec può ostacolare l’esecuzione degli hook, ma non rappresenta una soluzione completa e non deve essere considerata un sostituto dell’aggiornamento.
• Non sono disponibili workaround alternativi.

La stessa release 1.27.1 include anche una mitigazione per un problema di inclusione di file nel renderer Org-mode, al momento senza CVE specifico.

FAQ

1. Quali versioni di Gitea sono interessate dalla CVE-2026-60004?
Tutte le versioni dalla 1.17 (inclusa) fino alla 1.27.0 (inclusa). La versione 1.27.1, pubblicata il 27 luglio 2026, contiene la correzione.

2. Bisogna essere autenticati per sfruttare la falla?
Sì, occorre un account con permessi di scrittura su un repository. Poiché però la configurazione predefinita di Gitea permette la registrazione libera, un attaccante può crearsi un account e un repository autonomamente, rendendo l’exploit di fatto accessibile da remoto senza disporre di credenziali pregresse.

3. La vulnerabilità è già stata usata in attacchi reali?
Al 29 luglio 2026 non risultano campagne di sfruttamento attive. La presenza di un proof-of-concept pubblico eleva comunque significativamente il rischio concreto. Le organizzazioni sono invitate ad applicare l’aggiornamento senza indugio.