Segui Una vulnerabilità critica di esecuzione di codice remoto in Gitea è passata dalla divulgazione allo sfruttamento attivo in meno di un mese dopo che una patch è diventata disponibile. Tracciato come CVE-2026-60004 e valutato 9.8 sulla scala CVSS, il difetto consente a un attaccante con accesso ordinario alla scrittura del repository di piantare un hook Git eseguibile ed eseguire comandi shell arbitrari con i privilegi dell’account del servizio Gitea.
Il 25 agosto 2026, l’Agenzia per la Sicurezza Cibernetica e delle Infrastrutture degli Stati Uniti (CISA) ha aggiunto la vulnerabilità Gitea sfruttata al suo catalogo delle Vulnerabilità Conosciute Sfruttate (KEV), confermando che gli attacchi stanno avvenendo in natura. Le agenzie civili federali sono state istruite a risanare le installazioni interessate entro il 28 agosto 2026.
Il problema diventa particolarmente pericoloso perché Gitea abilita la registrazione aperta per impostazione predefinita. Sebbene lo sfruttamento richieda tecnicamente un account autenticato con permessi di scrittura nel repository, un attaccante esterno potrebbe essere in grado di creare un account, creare un repository e ottenere quei privilegi senza possedere credenziali precedentemente rubate.
Un attacco pubblicamente segnalato contro un server vulnerabile ha portato al dispiegamento di un dropper che mostrava un comportamento di mining di criptovaluta. L’incidente sottolinea perché l’RCE critico di Gitea sfruttato attivamente in natura dovrebbe essere trattato come una priorità urgente di risanamento per l’infrastruttura di sviluppo self-hosting esposta a Internet.
Analisi CVE-2026-60004
La vulnerabilità è classificata come CWE-94, Controllo Inadeguato della Generazione del Codice, e risiede nella funzionalità diffpatch di Gitea. Il punto finale API interessato applica patch fornite dall’utente all’interno di un repository Git temporaneo. In condizioni vulnerabili, un attaccante può manipolare questo processo in modo che il contenuto controllato dal repository diventi un hook Git eseguibile anziché un normale file del repository.
I dettagli importanti per CVE-2026-60004 si concentrano su come Gitea ha creato il repository temporaneo utilizzato per elaborare le patch. Le versioni vulnerabili usavano un clone Git bare, dove la directory del repository stesso funge da directory dati interna di Git. Combinato con il comportamento di elaborazione delle patch di Git, il contenuto del repository appositamente costruito potrebbe quindi raggiungere la directory degli hook e diventare eseguibile.
Un attaccante con accesso in scrittura può inviare contenuti di patch dannosi all’API diffpatch. Attivando una condizione di patch in conflitto, l’elaborazione a tre vie di Git può causare la materializzazione di un file eseguibile controllato dall’attaccante come hook post-modifica-indice. Git esegue successivamente quell’hook durante le operazioni del repository, risultando in un’esecuzione di comando come l’account del sistema operativo che esegue Gitea.
CVE-2026-60004 colpisce Gitea 1.17 e versioni successive precedenti alla versione 1.27.1. Gitea 1.27.1, rilasciata il 27 luglio 2026, corregge il problema cambiando il clone temporaneo interessato da un repository bare a uno non-bare, impedendo che i percorsi controllati dall’attaccante vengano interpretati come hook Git eseguibili nello stesso modo.
Lo sfruttamento riuscito richiede l’accesso alla scrittura del repository. Tuttavia, le impostazioni di installazione predefinite di Gitea indeboliscono significativamente quel prerequisito: la registrazione è normalmente abilitata, gli utenti non necessitano necessariamente di approvazione dell’amministratore o di verifica e-mail, e gli utenti appena registrati possono creare repository. Un attaccante che prende di mira un’installazione esposta a Internet non modificata potrebbe quindi essere in grado di soddisfare le autorizzazioni richieste semplicemente creando un nuovo account.
Ulteriori condizioni di sfruttamento identificate nella ricerca tecnica includono una versione del server Git che supporta il comportamento di fallback a tre vie rilevante, l’accesso al punto finale diffpatch e un filesystem temporaneo dove il servizio Gitea può scrivere ed eseguire file. Questi requisiti significano che non tutte le installazioni vulnerabili saranno necessariamente sfruttabili attraverso esattamente la stessa catena, ma le configurazioni predefinite possono fornire un percorso pratico.
Una volta che i comandi arbitrari vengono eseguiti sotto l’account del servizio Gitea, l’impatto si estende ben oltre un singolo repository. A seconda di come l’ambiente è configurato, un attaccante può ottenere l’accesso a repository privati, credenziali del database, segreti OAuth, configurazione dell’applicazione, variabili d’ambiente, credenziali CI/CD, registri di pacchetti o servizi interni raggiungibili dall’host Gitea.
Per le organizzazioni che utilizzano Gitea come parte dei flussi di lavoro di sviluppo e distribuzione del software, ciò crea anche un potenziale rischio per la catena di approvvigionamento. Il compromesso di una piattaforma di gestione del codice sorgente può esporre il codice proprietario e i segreti di distribuzione e può fornire opportunità per alterare i repository o utilizzare credenziali rubate per penetrare nell’infrastruttura CI/CD e di produzione.
Il ricercatore di sicurezza Shai Rod, noto anche come NightRang3r, ha scoperto e segnalato la vulnerabilità. Gitea ha rilasciato la versione 1.27.1 il 27 luglio, seguita dall’avviso formale di sicurezza il 28 luglio. Il problema inizialmente non aveva segnalazioni di sfruttamento confermate, ma questo è cambiato quando CISA lo ha aggiunto al catalogo KEV il 25 agosto.
Una PoC pubblica CVE-2026-60004 è stata disponibile dalla divulgazione della vulnerabilità, riducendo significativamente lo sforzo richiesto per comprendere e riprodurre la tecnica di attacco sottostante. Gli strumenti di sicurezza pubblici hanno anche aggiunto modelli di rilevamento per istanze vulnerabili, aumentando la probabilità che gli attaccanti possano identificare server esposti su larga scala.
Anche Hacker News ha documentato un incidente reale che coinvolge un server Gitea esposto a Internet con registrazione aperta abilitata. Secondo l’amministratore, l’attaccante ha raggiunto il servizio vulnerabile tramite HTTPS, ha creato le condizioni necessarie per lo sfruttamento ed ha eseguito un dropper che consumava risorse significative della CPU.
Il dropper ha cancellato certe variabili d’ambiente relative alle librerie, ha cercato processi che consumavano risorse significative della CPU, ha tentato di terminare i processi concorrenti, ha scaricato un payload corrispondente all’architettura host, lo ha eseguito e poi ha rimosso il file scaricato. L’amministratore non ha recuperato abbastanza prove per identificare uno specifico miner di criptovaluta, portafoglio, pool di mining o attore della minaccia, quindi il payload dovrebbe attualmente essere descritto come simile a un miner piuttosto che definitivamente attribuito a una famiglia di cryptojacking conosciuta.
Rimane poco chiaro se questo attacco specifico abbia causato a CISA l’aggiunta della vulnerabilità a KEV oppure se l’agenzia abbia osservato campagne di sfruttamento separate. Né CISA né i due rapporti citati hanno attribuito pubblicamente l’attività più ampia a un noto attore della minaccia.
Non è stato pubblicato nessun set autorevole di IOCs campagna-wide per CVE-2026-60004. I difensori dovrebbero quindi fare affidamento su prove comportamentali come la creazione di account sospetti, chiamate insolite all’API diffpatch, hook Git inaspettati, processi lanciati dal servizio Gitea e attività insolite della CPU o di rete in uscita.
Mitigazione CVE-2026-60004
Le organizzazioni che eseguono Gitea self-hosting dovrebbero immediatamente aggiornare alla versione 1.27.1 o successiva. Gli ambienti Gitea Cloud erano programmati per ricevere l’aggiornamento automaticamente, mentre gli amministratori delle installazioni autogestite sono responsabili di applicare personalmente il rilascio riparato.
Poiché lo sfruttamento è ora confermato in natura, l’applicazione della patch non dovrebbe essere ritardata fino alla prossima finestra di manutenzione routine. L’inclusione nella KEV di CISA fornisce una forte evidenza che la vulnerabilità rappresenta un rischio operativo immediato, con le agenzie civili federali degli Stati Uniti che devono risanare entro il 28 agosto 2026.
Le organizzazioni che non possono applicare immediatamente la patch dovrebbero disabilitare la registrazione pubblica dove non è richiesta. Impostare la registrazione in modalità controllata dall’amministratore impedisce a un utente Internet non autenticato di creare semplicemente un account e un repository per ottenere l’accesso alla scrittura necessario per l’exploit. Questa misura riduce l’esposizione ma non corregge la vulnerabilità perché gli utenti esistenti con permessi di scrittura nel repository possono comunque raggiungere la funzionalità vulnerabile.
Gli amministratori dovrebbero inoltre limitare la creazione e i permessi di scrittura del repository, ridurre l’accesso esterno a Gitea ove possibile ed evitare di esporre direttamente l’infrastruttura di sviluppo a Internet a meno che non vi sia una chiara esigenza aziendale.
Il rilevamento di CVE-2026-60004 dovrebbe iniziare identificando tutte le installazioni di Gitea, controllando le loro versioni esatte e determinando se la registrazione pubblica era abilitata mentre il server eseguiva una versione interessata. Le istanze esposte a Internet che consentivano ai visitatori anonimi di registrare account meritano la massima priorità di indagine.
Per rilevare i tentativi di sfruttamento di CVE-2026-60004 e le attività post-compromesso, i difensori dovrebbero esaminare la telemetria di Gitea, delle API, del sistema operativo e di rete per:
- – Richieste ripetute o inaspettate a /api/v1/repos/{proprietario}/{repo}/diffpatch
- – Account appena creati seguiti rapidamente dalla creazione di repository e operazioni di patch
- – Shell o processi non familiari generati dall’account del servizio Gitea
- – Utilizzo insolito sostenuto della CPU su host Gitea
- – Download o esecuzioni inaspettate da directory temporanee
- – Nuove connessioni in uscita originate da Gitea o dai suoi processi figlio
- – Modifiche non autorizzate del repository
- – Accesso imprevisto alla configurazione dell’applicazione, credenziali o segreti
La presenza di questi comportamenti non prova indipendentemente lo sfruttamento, ma combinazioni come la registrazione di nuovi account seguita dalla creazione di repository, richieste diffpatch e nuovi processi figlio dovrebbero essere urgentemente indagate.
Gli amministratori dovrebbero anche rivedere gli account creati mentre la versione vulnerabile era esposta. Utenti sconosciuti, repository creati poco dopo la registrazione e account che hanno immediatamente eseguito operazioni API possono aiutare a identificare tentativi di sfruttamento avvenuti prima che il server fosse patchato.
Il processo di mitigazione CVE-2026-60004 dovrebbe andare oltre l’installazione della versione 1.27.1 se si sospetta un compromesso. Poiché lo sfruttamento riuscito offre l’esecuzione del codice con i privilegi dell’utente del sistema operativo Gitea, i team di sicurezza dovrebbero trattare l’host interessato come potenzialmente compromesso e indagare su segreti accessibili e sistemi connessi.
Gli addetti alla risposta agli incidenti dovrebbero ruotare le credenziali del database, i token OAuth e API, i segreti CI/CD, le chiavi SSH, le credenziali di distribuzione e altro materiale sensibile accessibile a Gitea dove le prove suggeriscono che si sia verificata un’esecuzione di codice arbitrario. I repository privati dovrebbero anche essere esaminati per modifiche non autorizzate e i sistemi di build o distribuzione connessi dovrebbero essere esaminati per il movimento laterale.
CVE-2026-60004 dimostra come una vulnerabilità nell’infrastruttura di sviluppo possa rapidamente evolvere da un bug software a un percorso di compromissione attivo. Con informazioni di exploit pubbliche disponibili e confermato sfruttamento in corso, le organizzazioni che eseguono istanze Gitea self-hosting vulnerabili dovrebbero prioritizzare sia l’applicazione delle patch che la caccia retrospettiva alla minaccia.
FAQ
Cos’è CVE-2026-60004 e come funziona?
CVE-2026-60004 è una vulnerabilità critica di iniezione di codice nell’API diffpatch di Gitea. Un attaccante con accesso alla scrittura del repository può inviare contenuti di patch dannosi che risultano in un hook Git eseguibile installato ed eseguito, permettendo l’esecuzione di comandi shell arbitrari come utente del sistema operativo di Gitea. La registrazione aperta predefinita può consentire a un attaccante esterno di ottenere i permessi richiesti del repository semplicemente creando un account.
Quando è stato scoperto per la prima volta CVE-2026-60004?
La data esatta di scoperta privata non è stata divulgata pubblicamente. Gitea accredita il ricercatore di sicurezza Shai Rod, noto anche come NightRang3r, per aver segnalato il problema. La versione 1.27.1 contenente la correzione è stata rilasciata il 27 luglio 2026 e l’avviso di sicurezza è stato pubblicato il 28 luglio. CISA ha confermato lo sfruttamento attivo aggiungendo il difetto al suo catalogo KEV il 25 agosto.
Qual è l’impatto di CVE-2026-60004 sui sistemi?
Lo sfruttamento riuscito consente l’esecuzione di comandi arbitrari con i privilegi dell’account del servizio Gitea. Ciò può esporre repository di codice sorgente, segreti dell’applicazione, credenziali del database, materiale OAuth, credenziali CI/CD e altre risorse accessibili dal server compromesso. Gli attaccanti possono anche distribuire malware o utilizzare l’host Gitea come punto d’appoggio per ulteriori intrusioni.
CVE-2026-60004 può ancora colpirmi nel 2026?
Sì. Qualsiasi installazione Gitea self-hosting che esegue versioni dalla 1.17 alla 1.27.0 rimane vulnerabile. Il rischio è ora particolarmente urgente perché CISA ha confermato lo sfruttamento attivo, e almeno un’intrusione pubblicamente descritta sembra aver utilizzato il difetto per distribuire un payload simile a un miner.
Come posso proteggermi da CVE-2026-60004?
Aggiorna immediatamente Gitea alla versione 1.27.1 o successiva. Disabilita la registrazione aperta se non è richiesta, limita la creazione e l’accesso in scrittura del repository e rivedi l’attività API storica per richieste diffpatch sospette. Se si sospetta uno sfruttamento, indaga sull’host per hook Git dannosi e processi inaspettati e ruota i segreti accessibili all’account del servizio Gitea.
