Gogs, la piattaforma open-source di Git self-hosted, è affetta da una vulnerabilità zero-day di remote code execution con punteggio CVSS 9.4 divulgata ai maintainer il 17 marzo 2026 e rimasta senza correzione per oltre due mesi. Rapid7 ha rilasciato un modulo Metasploit che automatizza l'exploit chain su Linux e Windows, rendendo l'attacco riproducibile su larga scala. La combinazione di semplicità operativa, impatto cross-platform e assenza di patch pone un rischio immediato per le migliaia di organizzazioni che ospitano codice proprietario su istanze on-premise.
- CVSS 9.4, RCE via argument injection: il flaw risiede nel modo in cui Gogs passa il nome del branch base al comando
git rebasesenza sanitizzazione, permettendo l'iniezione del flag--execcon codice arbitrario. - Exploit senza privilegi e senza interazione: la registrazione aperta abilitata di default consente a un attaccante non autenticato di creare account, repository e attivare il rebase merging autonomamente.
- Conseguenze totali sul server: l'esecuzione con privilegi del processo Gogs espone tutti i repository (anche privati), credenziali hashate, token API, chiavi SSH e segreti 2FA, con possibile modifica silenziosa del codice.
- Silenzio dei maintainer e precedente storico: è il secondo zero-day Gogs in sei mesi dopo CVE-2025-8110, con un pattern ricorrente di vulnerabilità nel merge logic non ancora sanato dall'adozione sistematica di API hardenizzate.
Il meccanismo: quando il nome del branch diventa un payload
La vulnerabilità si annida nel flusso di merge "Rebase before merging" di Gogs. Secondo quanto documentato da Rapid7 e riportato da SecurityWeek, il codice di merge utilizza un wrapper di esecuzione processo a basso livello invece dell'API git-module che era stata hardenizzata in altre parti del codebase con separatori --end-of-options o --.
Il risultato è che il nome del branch base viene passato direttamente come argomento al comando git rebase. Poiché Git accetta il flag --exec=<comando> per eseguire shell commands dopo ogni commit replayed, un attaccante può creare un branch il cui nome contiene --exec=<payload malevolo>. Quando Gogs elabora la pull request, il comando viene iniettato ed eseguito con i privilegi del processo server.
Jonah Burgess, ricercatore di Rapid7, ha descritto la semplicità operativa all'Hacker News: "Any registered user who creates a repo is automatically its owner. From there, enabling rebase merging is a single toggle in settings, and the entire exploit chain can be operated without interaction from any other user". La creazione e successiva eliminazione del repository malevolo lascia come unica traccia un errore HTTP 500 nei log del server.
La superficie d'attacco: registrazione aperta e istanze esposte
Un elemento che amplifica drasticamente il rischio è la configurazione predefinita di Gogs. Secondo Rapid7, citato da SecurityWeek: "Since Gogs ships with open registration enabled by default and no limit on repository creation, an unauthenticated attacker can simply create an account and repository on any default-configured instance". Questo significa che la barriera all'ingresso è nulla: non serve compromettere credenziali esistenti, social engineering o accesso privilegiato.
La stima di circa 1.141 istanze Gogs esposte su Internet, riportata dall'Hacker News, rappresenta probabilmente solo la punta dell'iceberg. Il numero reale è presumibilmente maggiore, considerando le installazioni interne accessibili via VPN e le reti aziendali che non vengono scansionate dagli enumerator pubblici. Ogni istanza con registrazione aperta e rebase merging abilitato è una potenziale vittima.
Conseguenze e persistenza: oltre il singolo server compromesso
L'impatto documentato da Rapid7 va oltre la semplice compromissione del sistema operativo. Secondo la citazione riportata da SecurityWeek, l'esecuzione come processo server Gogs concede all'attaccante: "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".
Questo profilo di danno solleva tre scenari di rischio concreto per le organizzazioni. Il primo è il data breach cross-tenant: in ambienti multi-tenant dove più team o clienti condividono la stessa istanza Gogs, la compromissione di un singolo account espone l'intero contenuto archiviato. Il secondo è l'attacco alla supply chain: la modifica silenziosa del codice sorgente può propagarsi attraverso i sistemi di build e distribuzione senza che gli sviluppatori rilevino l'anomalia. Il terzo è il pivoting interno: dall'istanza Gogs, un attaccante può muoversi lateralmente verso sistemi accessibili dalla stessa rete, sfruttando credenziali e trust relationship esposti nei repository.
Cosa fare adesso
Le fonti citate non documentano misure correttive ufficiali rilasciate dai maintainer Gogs. In assenza di patch, le azioni prioritarie derivano dall'analisi del meccanismo di exploit e dalla configurazione della piattaforma:
- Disabilitare la registrazione aperta: se l'organizzazione non richiede account pubblici, la chiusura della registrazione elimina il vettore di accesso non autenticato documentato da Rapid7.
- Disattivare il merge "Rebase before merging": la vulnerabilità è specifica di questo flusso; l'uso esclusivo di merge strategie alternative (merge commit o squash) impedisce il trigger del codice vulnerabile.
- Controllare i log per errori HTTP 500 in corrispondenza di operazioni su repository: l'unica traccia lasciata dall'exploit documentato è un errore server; il monitoraggio di questo pattern può indicare tentativi passati.
- Valutare la migrazione temporanea a piattaforme con ciclo di patch attivo: considerato il silenzio dei maintainer per oltre due mesi e il precedente CVE-2025-8110 con analoga latenza, le organizzazioni con esposizione critica devono ponderare alternative con governance di sicurezza strutturata.
Un pattern ricorrente: il caso CVE-2025-8110
Questa non è la prima volta che Gogs compare nel radar dei ricercatori con un zero-day critico. Entro sei mesi dalla disclosure pubblica di CVE-2025-8110 — una vulnerabilità di symlink handling con CVSS 8.8 che permetteva path traversal e potenziale esecuzione di codice — il progetto è nuovamente al centro di un RCE senza patch. Entrambi i flaw nascono in aree del codebase che interagiscono con operazioni Git a basso livello, dove la mancanza di astrazioni sicure espone il server a comportamenti non previsti del sottostante sistema di versionamento.
La scelta architetturale di mantenere wrapper processo legacy invece di migrare sistematicamente all'API git-module hardenizzata emerge come fattore di rischio strutturale. Se la prima occorrenza poteva essere considerata un'eccezione, la ripetizione solleva questioni di priorità nella governance del progetto open-source: la sicurezza del merge logic non ha ricevuto attenzione proporzionata al suo impatto, nonostante la precedente divulgazione responsabile.
"Since Gogs ships with open registration enabled by default and no limit on repository creation, an unauthenticated attacker can simply create an account and repository on any default-configured instance" — Rapid7, via SecurityWeek
Perché il silenzio dei maintener conta
La divulgazione ai maintainer Gogs è avvenuta il 17 marzo 2026. Alla data di pubblicazione dei report — fine maggio 2026 — nessuna patch è stata rilasciata. Questo intervallo di oltre due mesi, in un contesto dove un modulo Metasploit rende l'exploit riproducibile su larga scala, trasforma una vulnerabilità tecnica in un problema di gestione del rischio organizzativo.
I team di sicurezza non possono più affidarsi esclusivamente alla reattività del vendor. La decisione di mantenere in produzione una piattaforma con questo profilo di rischio richiede una valutazione esplicita dei trade-off: convenienza dell'hosting self-hosted contro esposizione a RCE documentati, controllo diretto dei dati contro assenza di SLA di sicurezza, familiarità del team con lo strumento contro costo di migrazione verso alternative enterprise.
Il caso Gogs del 2026 non è solo una vulnerabilità da catalogare. È un test della maturità delle pratiche di gestione del software open-source in ambito DevOps, dove la velocità di sviluppo spesso precede la verifica sistematica delle superfici di attacco.
Domande frequenti
La vulnerabilità richiede privilegi di amministratore su Gogs?
No. L'exploit funziona con un utente standard autenticato, che può essere creato autonomamente grazie alla registrazione aperta predefinita.
Esiste un CVE assegnato a questa vulnerabilità?
Le fonti citate indicano esplicitamente che non è stato assegnato un identificatore CVE al momento della pubblicazione.
La vulnerabilità è in Git o in Gogs?
È in Gogs, specificamente nel modo in cui invoca git rebase durante il merge. Il sottostante sistema Git non è vulnerabile; il problema è l'assenza di sanitizzazione degli argomenti nel codice chiamante.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://www.securityweek.com/gogs-zero-day-exposes-servers-to-remote-code-execution/
- https://thehackernews.com/2026/05/critical-gogs-rce-vulnerability-lets.html
- https://gbhackers.com/new-gogs-0-day-flaw/