Il 29 maggio 2026 Rapid7 ha pubblicato l'analisi tecnica di una vulnerabilità zero-day in Gogs, il servizio Git self-hosted open source, assegnandole un punteggio CVSS 9.4. La falla consente esecuzione remota di codice a un attaccante autenticato tramite argument injection nel comando git rebase --exec, con impatto totale sul server compromesso. La notizia è politicamente rilevante: i maintainer del progetto sono stati informati a metà marzo 2026, hanno riconosciuto la ricezione del report, ma al momento della pubblicazione non hanno rilasciato alcuna correzione.
- CVSS 9.4, gravità critica: argument injection in git rebase --exec durante l'operazione "Rebase before merging" permette esecuzione di comandi arbitrari con i privilegi del processo server Gogs
- La configurazione di default espone la superficie d'attacco massima: registrazione aperta abilitata, nessun limite ai repository, singolo toggle per attivare il rebase merging
- Secondo zero-day critico in Gogs in sei mesi, dopo il CVE-2025-8110 divulgato da Wiz a dicembre 2025
- Rapid7 ha rilasciato modulo Metasploit e indicatori di compromesso, rendendo l'exploit replicabile per chiunque
Il meccanismo d'attacco: quando il nome di un branch diventa codice
La vulnerabilità risiede nel modo in cui Gogs elabora i nomi di branch durante le operazioni di merge. Quando l'amministratore di un'istanza abilita l'opzione "Rebase before merging", il server invoca git rebase con argomenti derivati dal nome del branch sorgente della pull request. Gogs non sanifica questi input: un attaccante può inserire il flag --exec nel nome del branch, e git rebase lo interpreta come istruzione per eseguire un comando shell dopo ogni commit replayed.
La fonte descrive esplicitamente la catena: il flag --exec "tells Gogs to run a shell command after replaying each commit", con esecuzione nel contesto del processo server. Non è una vulnerabilità in git stesso: il tool git rebase --exec è una funzionalità legittima e documentata. La falla è nel wrapper Gogs che la espone a input esterno non controllato.
La configurazione di default amplifica il rischio oltre la semplice presenza del bug. Secondo la fonte, Gogs "ships with open registration enabled by default and no limit on repository creation". Un attaccante non autenticato crea account, attiva repository, abilita il rebase merging tramite l'interfaccia web e sfrutta la vulnerabilità "without user interaction, as the attacker operates entirely within their own account and repository". Il percorso di attacco è completamente unipersonale e automatizzabile.
"The result is arbitrary command execution as the Gogs server process user, giving the attacker the ability to compromise the server, read every repository on the instance (including other users' private repos), dump credentials (password hashes, API tokens, SSH keys, 2FA secrets), pivot to other network-accessible systems, and modify any hosted repository's code" — Rapid7, riportato da SecurityWeek
L'impatto: compromissione totale, non leakage parziale
Il risultato non è una fuga di dati limitata o un'escalation di privilegi locale. La fonte elenca una gamma di conseguenze documentate: lettura di ogni repository presente sull'istanza, privati inclusi; dump di credenziali con hash password, token API, chiavi SSH e segreti 2FA; pivoting verso altri sistemi raggiungibili in rete; modifica arbitraria del codice ospitato. Con privilegi del processo server, l'attaccante ha accesso al filesystem e ai database interni di Gogs.
Le istanze affette coprono tutte le piattaforme supportate: Windows, Linux, macOS, con configurazione default. La fonte non specifica versioni puntuali interessate, limitandosi alla genericità della configurazione standard. Questo lascia aperto il problema del perimetro esatto: chi ha personalizzato registrazione o limiti repository potrebbe avere superficie ridotta, ma la fonte non quantifica questa variabile.
La crisi di governance: due zero-day in sei mesi, zero patch
Il contesto temporale è il dato più disturbante. I maintainer Gogs sono stati notificati "in mid-March 2026", hanno "acknowledged receiving the vulnerability report", ma al 29 maggio 2026 "no patch has been released". L'intervallo è di circa due mesi e mezzo, un lasso di tempo che nella gestione delle vulnerabilità critiche rappresenta una carenza strutturale, non un ritardo operativo.
Questa non è la prima volta. La fonte colloca l'incidente in una sequenza: il precedente zero-day, CVE-2025-8110 con CVSS 8.8, era stato divulgato da Wiz a dicembre 2025. Sei mesi separano i due eventi critici. Il CVE-2025-8110 è documentato nel brief come fatto distinto, con punteggio ufficiale NVD 8.8 HIGH; la nuova vulnerabilità non ha ancora identificatore assegnato al momento della notizia.
La fonte non fornisce dettagli sulla struttura organizzativa di Gogs: numero di maintainer attivi, modello di finanziamento, governance del progetto. Questi dati mancanti rendono difficile distinguere tra crisi di risorse, disaccordo strategico o semplicemente abbandono progressivo. Ciò che la fonte documenta è il risultato: una vulnerabilità critica con modulo Metasploit pubblico e nessuna contromessa ufficiale.
Perché è importante
Il brief non documenta misure correttive specifiche rilasciate dai maintainer Gogs o azioni mitigative ufficiali consigliate agli utenti. La fonte non specifica se esistano configurazioni alternative che disabilitino completamente il percorso di attacco senza rimuovere funzionalità essenziali.
Il dossier non quantifica il numero di istanze Gogs esposte su internet, né verifica se la vulnerabilità sia già stata sfruttata attivamente prima della disclosure. Lo stato della patch al momento della lettura è ignoto: la notizia è datata 29 maggio 2026, e possibili evoluzioni successive non sono nel brief.
La fonte non dettaglia il modulo Metasploit rilasciato da Rapid7: la sua struttura, i requisiti di esecuzione, gli indicatori di compromesso pubblicati non sono descritti tecnicamente. Ciò che è documentato è la loro esistenza, non il loro contenuto operativo.
Il confronto con alternative come Gitea o GitLab, suggerito dall'angolo editoriale, non è sviluppato dalla fonte come analisi comparata: rimane una lettura redazionale sul rischio di dipendenza da progetti con singolo punto di fallimento organizzativo, non un dato empirico sullo stato di sicurezza delle alternative.
Domande che restano aperte
La vulnerabilità è sfruttabile solo con registrazione aperta? La fonte descrive il percorso più diretto tramite account self-creato, ma non esclude che utenti autenticati legittimi possano abusare della stessa falla. Chi ha disabilitato la registrazione pubblica riduce la superficie, non necessariamente il rischio interno.
Qual è la natura esatta dei dati a rischio? La citazione elenca categorie precise: hash password, token API, chiavi SSH, segreti 2FA. La fonte non chiarisce se questi siano archiviati in chiaro, hashed, o con quale algoritmo: la capacità di "dump" implica accesso al database, non necessariamente leggibilità immediata di tutti i campi.
Perché i maintainer non hanno rilasciato la patch? La fonte riporta solo acknowledgment e assenza di fix. Motivazioni, timeline interne, o discussioni di design non sono documentate. Il limite informativo è netto: si sa che non c'è patch, non si sa perché.
La crisi di Gogs è emblema di un problema più ampio nell'infrastruttura open source critica: la sicurezza di migliaia di installazioni dipende dalla capacità di risposta di un numero spesso ridotto di volontari. Quando questa capacità si interrompe, la disclosure responsabile diventa un annuncio pubblico senza contrappeso tecnico, e il modulo Metasploit trasforma una falla teorica in attacco praticamente off-the-shelf.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.