È bastata una serata di lavoro a Julien Voisin, noto come jvoisin, per pubblicare un quadro poco rassicurante sulla sicurezza di Forgejo. Nel post uscito il 28 aprile, il ricercatore afferma di aver individuato diverse vulnerabilità e di averne concatenate alcune fino a ottenere un’esecuzione di codice remoto.

La motivazione dell’analisi è stata pratica: Fedora ha avviato la transizione da Pagure a Fedora Forge, una nuova piattaforma basata su Forgejo. Il passaggio non è ancora concluso: il cutover finale è previsto per Flock 2026 e la dismissione delle restanti istanze Pagure è indicata nella roadmap verso Fedora 46. È comunque abbastanza per aver spinto Voisin a guardare più da vicino la postura di sicurezza del progetto.

// affiliato ▸ Proton Pass · Le tue password, protette sul serio con sconti al 50% · Provalo gratis →

Quello che dice di aver trovato non è confortante. La lista parte dalle SSRF, vulnerabilità che permettono a un attaccante di far eseguire richieste al server verso destinazioni scelte da lui, incluse potenzialmente risorse interne non esposte su Internet. A queste si aggiungono debolezze lato browser, come l’assenza di Content Security Policy e Trusted Types, difese pensate per limitare l’impatto di eventuali XSS.

Il ricercatore segnala anche un templating JavaScript fragile, pratiche crittografiche che giudica discutibili e problemi nei meccanismi di autenticazione: OAuth2, OTP, sessioni, gestione degli accessi e recupero dopo compromissione. In altre parole, non solo bug isolati, ma difetti in aree che dovrebbero proteggere identità, permessi e persistenza degli account.

Completano il quadro vari vettori di denial of service, perdite di informazioni e race condition di tipo TOCTOU: bug in cui il software controlla una condizione in un momento, ma usa quella risorsa più tardi, quando lo stato può essere cambiato. Su una piattaforma che gestisce codice, utenti, repository e autorizzazioni, è esattamente il genere di superficie che può trasformare una falla locale in una catena d’attacco più ampia.

Secondo Voisin, combinando alcune di queste vulnerabilità è possibile arrivare a un RCE completo, a leak di segreti, ad accesso persistente agli account e a privilege escalation via OAuth2. Un dettaglio importante per contestualizzare: la catena RCE descritta non viene presentata come sfruttabile su qualunque installazione Forgejo. Il ricercatore scrive che richiede registrazione aperta e almeno un’opzione di configurazione impostata a un valore non predefinito; aggiunge però di aver trovato entrambe le condizioni attive su alcune istanze pubbliche reali.

La carrot disclosure

Anziché optare per una disclosure coordinata, segnalazione privata al vendor, tempo per correggere e pubblicazione successiva, o per una full disclosure immediata, Voisin ha scelto un approccio che aveva già teorizzato nel 2024: la carrot disclosure.

L’idea è semplice e volutamente scomoda: pubblicare solo l’output, eventualmente redatto, di un exploit per una vulnerabilità critica, senza pubblicare il codice dell’exploit. In questo modo si dimostra che la vulnerabilità è sfruttabile, ma non si consegna subito una ricetta pronta all’uso.

Il vendor si trova così davanti a una scelta: fare un audit più ampio del software, nella speranza di correggere anche la catena mostrata, oppure convivere con il rischio reputazionale di un software indicato pubblicamente come vulnerabile. Nel post su Forgejo, Voisin pubblica anche l’hash SHA256 dello script usato per la dimostrazione, così da poter provare in futuro che l’exploit esisteva già al momento della disclosure.

La parte più delicata è proprio questa: il post non contiene i dettagli tecnici necessari per riprodurre la catena, ma mostra l’output dell’esecuzione di codice e una struttura di file che suggerisce l’esistenza di più exploit o script di supporto. Rimanda inoltre ad alcune pull request già aperte, ma sostiene che il problema non sia un singolo bug da correggere: a suo giudizio, la questione sarebbe più sistemica.

Per chi gestisce un’istanza

La catena RCE descritta da Voisin non va letta come automaticamente sfruttabile su ogni istanza Forgejo. I prerequisiti indicati nel post sono registrazione aperta e una configurazione non predefinita. Va però notato che, nella documentazione Forgejo, DISABLE_REGISTRATION è impostato di default a false: in altre parole, la registrazione aperta è il comportamento predefinito documentato, salvo diversa configurazione dell’amministratore.

L’output pubblicato cita un “server-side hook”. Questo rende sensato controllare con attenzione anche le impostazioni relative ai Git hook lato server: Forgejo documenta DISABLE_GIT_HOOKS: true come valore predefinito e avverte che abilitarli può permettere esecuzione arbitraria di codice sul sistema host. Il post di Voisin, però, non identifica esplicitamente quell’opzione come il prerequisito non-default della catena; quindi è meglio trattarla come un’area da verificare, non come una diagnosi certa.

In attesa di chiarimenti o aggiornamenti dal progetto, chi amministra un’istanza Forgejo dovrebbe quindi rivedere la configurazione, valutare se la registrazione pubblica sia davvero necessaria e controllare con particolare attenzione le funzionalità che possono introdurre esecuzione di codice lato server o superfici di attacco non indispensabili.