Gitea sotto attacco: il template Docker che apre le porte a…

Sono bastati tredici giorni dalla pubblicazione dell'advisory per vedere i primi tentativi di exploitation in-the-wild contro CVE-2026-20896, una vulnerabilità

{"main_topic":"cybersecurity","topics":["cybersecurity","vulnerabilita","cve","exploit","patch"]}

Sono bastati tredici giorni dalla pubblicazione dell'advisory per vedere i primi tentativi di exploitation in-the-wild contro CVE-2026-20896, una vulnerabilità critica nel template Docker di Gitea che trasforma una convenienza di deployment in autenticazione bypassabile con un singolo header HTTP. Sysdig ha rilevato il probing proveniente dall'indirizzo IP 159.26.98[.]241, un nodo del servizio ProtonVPN, confermando che la finestra di patch per gli amministratori si sta restringendo a velocità insostenibile.

La gravità è massima: il National Vulnerability Database assegna CVSS 9.8, con vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Qualsiasi istanza Gitea esposta su Internet, containerizzata con le immagini ufficiali fino alla versione 1.26.2 inclusa, è potenzialmente impersonabile senza credenziali.

Punti chiave

Il file app.ini template nelle immagini Docker ufficiali Gitea hard-coda REVERSE_PROXY_TRUSTED_PROXIES=*, fidandosi di qualsiasi origine IP
Con ENABLE_REVERSE_PROXY_AUTHENTICATION=true, un attaccante remoto invia l'header X-WEBAUTH-USER e ottiene sessione autenticata come qualsiasi utente, admin compresi
Sysdig ha rilevato probing in-the-wild il 6 luglio 2026, tredici giorni dopo la disclosure pubblica, da IP associato a ProtonVPN
La correzione in Gitea v1.26.3 rimuove il default insicuro e rende la reverse-proxy authentication opt-in con configurazione esplicita dell'amministratore

Il meccanismo: quando il reverse proxy diventa backdoor

La vulnerabilità non risiede nel codice sorgente di Gitea, ma nel template di configurazione distribuito con le immagini Docker ufficiali. L'advisory GitHub Security GHSA-f75j-4cw6-rmx4 documenta con precisione la catena: il file app.ini preconfigurato imposta REVERSE_PROXY_TRUSTED_PROXIES = *, un wildcard che annulla qualsiasi verifica sull'origine delle richieste.

Il pattern reverse-proxy authentication è legittimo e diffuso: un proxy perimetrale gestisce l'autenticazione utente e inoltra verso il backend un header attestante l'identità già verificata. Gitea supporta questo modello con la direttiva ENABLE_REVERSE_PROXY_AUTHENTICATION, tipicamente abilitata dagli amministratori che deployano dietro nginx, Traefik o equivalenti. Il problema: il template Docker predefinisce fiducia illimitata, trasformando un'architettura difensiva in un tunnel aperto.

Il ricercatore Ali Mustafa, noto come @rz1027, ha sintetizzato la dinamica in modo inequivocabile: «Con il reverse-proxy login abilitato, quel wildcard si fida di ogni sorgente IP, quindi chiunque riesca a raggiungere la porta può inviare un header X-WEBAUTH-USER e autenticarsi come qualsiasi utente, senza password e senza token». L'advisory originale aggiunge un dettaglio operativo rilevante: gli account admin — admin, gitea_admin e varianti prevedibili — sono i target ovvii per la compromissione.

Esiste un percorso di escalation ulteriore. L'opzione ENABLE_REVERSE_PROXY_AUTO_REGISTRATION, quando attiva, permette la creazione arbitraria di nuovi account tramite header forgiato, espandendo la superficie d'attacco oltre l'impersonazione verso l'inflazione del trust boundary.

Tredici giorni: la finestra che si chiude

La timeline documentata da Sysdig attraverso The Hacker News è implacabile: la disclosure pubblica, l'intervallo di tredici giorni, il primo rilevamento. Michael Clark, senior director of threat research presso Sysdig, ha circoscritto le attività alla fase di ricognizione iniziale: «Finora le attività si sono limitate all'investigazione preliminare da parte del threat actor... Sebbene abbiamo registrato la prima azione da un IP del servizio ProtonVPN, 159.26.98[.]241, non si è finora evoluta in exploitation o progresso d'attacco».

La distinzione tra probing e exploitation completa è tecnicamente rilevante ma operativamente fragile. Il probing verifica la presenza della condizione vulnerabile — risposta HTTP coerente con l'header X-WEBAUTH-USER elaborato — e prepara il terreno per l'azione successiva. L'assenza di escalation documentata al momento della rilevazione non implica assenza di rischio: l'indirizzo ProtonVPN indica deliberata occultazione dell'origine, pattern coerente con attività mirate piuttosto che scansione indifferenziata.

Il dato di esposizione è quantificabile: secondo le stime Sysdig riportate da The Hacker News, esistono circa 6.200 istanze Gitea raggiungibili da Internet. Il dossier non specifica quante tra queste eseguano immagini Docker vulnerabili, né quante abbiano abilitato ENABLE_REVERSE_PROXY_AUTHENTICATION. L'incertezza sui due fattori di condizionamento — versione e configurazione — impedisce stime precise della popolazione effettivamente a rischio.

Il fix: dalla convenienza alla responsabilità esplicita

La pull request #38151 documenta la correzione con chiarezza chirurgica: «Rimuovi REVERSE_PROXY_LIMIT / REVERSE_PROXY_TRUSTED_PROXIES dai template app.ini Docker (il default = * permetteva impersonazione via X-WEBAUTH-USER; la reverse-proxy auth è ora opt-in e configurata dall'amministratore)».

La scelta architetturale è significativa. Il team Gitea non ha semplicemente corretto il valore da wildcard a range loopback — 127.0.0.0/8,::1/128, quello che la documentazione indica come sicuro — ma ha eliminato completamente il default dal template, trasferendo l'onere della decisione all'amministratore. La funzionalità richiede ora configurazione esplicita, rimuovendo la trappola del "funziona subito" che ha caratterizzato le immagini precedenti.

Secondo il record CVE ufficiale, la vulnerabilità interessa le versioni fino alla 1.26.2 inclusa. La versione corretta è la 1.26.3, il cui changelog riflette la modifica dei template Docker.

«Any process that can reach the Gitea container's HTTP port directly — not through the intended authenticating proxy — can impersonate any user whose login name is known or guessable. Admin accounts (admin, gitea_admin, etc.) are the obvious targets.»
— Advisory GitHub Security GHSA-f75j-4cw6-rmx4

Confusione da evitare: CVE-2026-20896 e CVE-2026-58053

L'editor's note apparso su Daily Security Review ha corretto un'assocazione inizialmente errata tra vulnerabilità. CVE-2026-58053, distinto da quello trattato, riguarda un container escape in Gitea — meccanismo, impatto e superficie d'attacco completamente differenti. CVE-2026-20896 resta un authentication bypass basato su header spoofing, confinato al layer applicativo e condizionato dalla specifica combinazione di template Docker e abilitazione del reverse proxy.

La distinzione è operativa: le misure di mitigazione per un container escape — hardening del runtime, policy seccomp, riduzione dei privilegi — non risolvono un authentication bypass basato su configurazione applicativa. Gli amministratori devono verificare specificamente i tre elementi della catena vulnerante: immagine Docker, versione ≤1.26.2, presenza di REVERSE_PROXY_TRUSTED_PROXIES=* con reverse-proxy authentication abilitata.

Cosa fare adesso

Quattro azioni prioritarie emergono dal dossier tecnico:

Aggiornare a Gitea v1.26.3 o successiva: il fix ufficiale rimuove il default insicuro dal template Docker e rende la funzionalità opt-in
Verificare la configurazione di REVERSE_PROXY_TRUSTED_PROXIES nelle istanze che non possono aggiornarsi immediatamente: se valorizzato a *, sostituirlo con l'intervallo loopback 127.0.0.0/8,::1/128 o con gli IP espliciti dei proxy autorizzati
Controllare i log per probing: ricercare richieste con header X-WEBAUTH-USER da indirizzi IP non corrispondenti ai proxy legittimi, con particolare attenzione all'indirizzo 159.26.98[.]241 documentato da Sysdig
Disabilitare ENABLE_REVERSE_PROXY_AUTO_REGISTRATION se non strettamente necessaria, per ridurre la superficie di escalation da impersonazione a creazione account arbitrari

Il problema del default insicuro

CVE-2026-20896 illustra una categoria di vulnerabilità sottovalutata: non il bug di implementazione, ma la decisione di deployment ottimizzata per la convenienza. Il template Docker è progettato per far funzionare Gitea al primo avvio, senza intervento manuale; il wildcard risolve ogni scenario di rete immaginabile, trasformando l'amministratore ignaro in un utente che ha aperto un'autenticazione alternativa senza saperlo.

Il reverse-proxy authentication è percepito come pattern sicuro perché delega l'autenticazione a un componente perimetrale hardened. La rottura del modello avviene non nel proxy, ma nella fiducia eccessiva del backend: quando il filtro di origine è disattivato, il confine tra "richiesta legittima dal proxy" e "richiesta diretta arbitraria" si dissolve. Gitea v1.26.3 risolve il problema spostando il costo della configurazione corretta sul deployer, dove dovrebbe sempre essere stato.

Per le circa 6.200 istanze esposte, la domanda non è se aggiornare, ma se l'aggiornamento arriverà prima che il probing rilevato da Sysdig maturi in compromissione documentata. La finestra di tredici giorni è già chiusa.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti