Gitea: 4 anni di bug nascosto, immagini private a rischio di esposizione

CVE-2026-27771: bug nel registry container di Gitea ha lasciato ~31.750 istanze potenzialmente vulnerabili per circa quattro anni. Scoperta da un agente AI pen…

Contenuto

Gitea: 4 anni di bug nascosto, immagini private a rischio di esposizione
Gitea: 4 anni di bug nascosto, immagini private a rischio di esposizione

Il 27 maggio 2026 la ricerca di sicurezza NoScope ha reso pubblico CVE-2026-27771, una vulnerabilità nel registry container integrato di Gitea che ha reso inefficace il flag "privato". Per circa quattro anni, chiunque poteva scaricare immagini container dichiarate private senza account, password o autorizzazione. La scoperta, avvenuta ad aprile 2026 tramite un agente autonomo di penetration testing basato su intelligenza artificiale, mette in luce un paradosso crescente: le infrastrutture DevOps self-hosted vengono scelte per il controllo, ma finiscono per accumulare bug silenziosi che nessun audit interno rileva.

Gitea è un servizio Git leggero, open source e self-hosted, ampiamente adottato da team che vogliono tenere codice e artefatti lontani dai cloud pubblici. Il registry OCI integrato — disponibile dalla versione 1.13.0 — permette di ospitare immagini Docker e container OCI. La patch è disponibile nella versione 1.26.2; il fork Forgejo risulta vulnerabile secondo verifiche indipendenti di NoScope e Orca Security.

Punti chiave
  • CVE-2026-27771: il flag "privato" sui repository container non attivava alcun controllo di autenticazione all'endpoint registry, permettendo pull anonime complete
  • Stima di ~34.000 istanze Gitea esposte su Internet, di cui circa 31.750 (93%) potenzialmente vulnerabili, distribuite in oltre 30 paesi con concentrazione in Cina, Stati Uniti, Germania, Francia e Regno Unito
  • Il bug ha persistito per circa quattro anni dalla introduzione della funzionalità registry; nessuna exploitation confermata al momento della disclosure
  • La scoperta è stata effettuata ad aprile 2026 dall'agente AI di NoScope; la versione patch è 1.26.2 (un workaround temporaneo impone REQUIRE_SIGNIN_VIEW=true)

Il meccanismo: quando "privato" non significa protetto

Il registry OCI di Gitea espone endpoint standard HTTP su path /v2/ per manifest e blob, il protocollo che Docker e client compatibili usano per pull e push. Secondo la documentazione tecnica di Rescana e la ricerca di Orca Security, il repository flaggato come "privato" nell'interfaccia web di Gitea non propagava la stessa restrizione al livello registry. L'API rispondeva a richieste GET anonime servendo layer e manifest completi, effettivamente bypassando qualsiasi verifica di identità.

Questo non è un caso di credenziali deboli o di configurazione errata da parte dell'utente. La vulnerabilità risiede nella logica di controllo accessi del software stesso: il middleware di autenticazione applicato all'interfaccia grafica non era replicato all'endpoint registry. Il risultato è un'asimmetria pericolosa — un amministratore vedeva "privato" nella dashboard e assumeva protezione, mentre il registry esposto al web trattava ogni richiesta come pubblica.

La portata: numeri da rete critica, non da hobby

I dati raccolti da NoScope tramite Shodan indicano circa 34.000 istanze Gitea raggiungibili da Internet. Di queste, circa 31.750 — il 93% — eseguivano versioni comprese tra la 1.13.0 e la 1.26.1, quindi potenzialmente vulnerabili. Secondo Orca Security, circa il 52% di queste istanze risiede su piattaforme cloud principali. SecurityWeek riporta che circa 4.000 sistemi siano configurazioni di produzione su cloud o VPS, non macchine da sviluppatore isolato.

Settori identificati nelle istanze esposte includono healthcare, aerospaziale, retail, ISP e sviluppo software enterprise. Questi non sono repository di test con immagini hello-world: sono infrastrutture che ospitano pipeline CI/CD e configurazioni di deployment. Le immagini container potrebbero contenere codice sorgente, configurazioni o — in casi non documentati — parametri sensibili.

"Il dato è inequivocabile. Non sono macchine da hobby. Sono organizzazioni che hanno preso una decisione deliberata di self-hostare la loro infrastruttura di sviluppo, eseguendola su compute di produzione, per carichi di lavoro reali." — NoScope, citato da SecurityWeek

Discrepanze nel rating di severità

Il punteggio CVSS di CVE-2026-27771 non è univoco nelle fonti. The Hacker News riporta 8.2. TechJack Solutions indica 9.1, specificando che il vettore CVSS è "in attesa di pubblicazione NVD". L'NVD al momento dell'accesso mostra solo un placeholder per CVE-2026-27771, senza dettagli tecnici popolati. La classificazione CWE-306 (Missing Authentication for Critical Function) è riportata da TechJack, coerente con la natura del bug.

TechJack Solutions dichiara esplicitamente che gli intervalli di versione "non sono confermati dai dati di origine disponibili", un limite che rende la specifica 1.13.0-1.26.1 di Rescana la più dettagliata tra le fonti, ma non verificata ufficialmente dal vendor. Tutte le fonti concordano invece sulla versione patch 1.26.2.

Limiti delle fonti disponibili

Nessun advisory strutturato ZDI/GHSL è disponibile per CVE-2026-27771. La ricostruzione tecnica si basa su ricerca vendor e disclosure coordinata. La ricostruzione si basa su fonti concordanti ma non tutte strutturate come advisory ufficiale. Questo limite va considerato nella valutazione del rischio e nella pianificazione delle contromisure.

Cosa fare adesso

Le fonti concordano su tre priorità immediate per gli operatori.

Primo, aggiornare a Gitea 1.26.2. Le release notes ufficiali contengono la correzione; il fork Forgejo richiede verifica indipendente della patch disponibile.

Secondo, dove l'aggiornamento non è immediatamente applicabile, impostare REQUIRE_SIGNIN_VIEW=true nella sezione [service] della configurazione Gitea. Questo workaround temporaneo forza l'autenticazione per ogni richiesta, mitigando il bypass sul registry — con l'effetto collaterale di rendere il contenuto non navigabile da utenti anonimi anche dove desiderato.

Terzo, rivedere i log di accesso del registry per identificare pull anonime su repository privati nel periodo storico. Nessuna fonte segnala exploitation confermata prima della disclosure, ma la natura del bug — accesso indistinguibile da una richiesta legittima — rende la verifica dei log essenziale per escludere accessi non autorizzati passati.

ANALISI — Il paradosso della fiducia self-hosted

Il caso CVE-2026-27771 illustra una tensione strutturale nelle infrastrutture DevOps autogestite. Le organizzazioni scelgono Gitea per mantenere il controllo su codice e artefatti, evitando la dipendenza da cloud pubblici. Questa scelta, ragionevole per policy di sovranità dati, crea però una superficie di attacco meno scrutinata: i bug nei componenti integrati non ricevono la stessa attenzione di quelli in servizi cloud mainstream.

Il registry container è un componente secondario rispetto al core Git, ma ha accesso agli stessi livelli di rete e storage. Artefatti interni, considerati trusted dall'organizzazione, avrebbero potuto essere accessibili all'esterno senza che alcun sistema di monitoraggio lo segnalasse. La mancanza di autenticazione non è un errore di configurazione dell'utente, ma una lacuna nel software stesso — e questo rende il rischio più difficile da anticipare.

Per le oltre 30.000 istanze stimate, la questione ora non è solo patchare. È verificare, attraverso i log, se qualcuno ha già fatto quello che il bug rendeva possibile.

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

Fonti

Link utili

Apri l'articolo su DeafNews