Bastano un'intestazione HTTP e nessuna password per farsi passare per l'amministratore di un server Gitea. È il cuore di CVE-2026-20896, una vulnerabilità di bypass dell'autenticazione con punteggio CVSS 9.8 che affligge le immagini Docker della popolare piattaforma di gestione del codice. Divulgata a fine giugno 2026 e corretta nelle versioni 1.26.3 e 1.26.4, la falla è passata dalla teoria alla pratica in meno di due settimane: la società di sicurezza cloud Sysdig ha rilevato i primi tentativi di sfruttamento reale tredici giorni dopo la pubblicazione. Per chiunque ospiti il proprio codice sorgente su un'istanza Gitea auto-gestita, è il momento di aggiornare e rivedere la configurazione.

Cosa è successo

Il problema nasce da una scelta di configurazione predefinita. Le immagini Docker di Gitea distribuiscono un file app.ini che imposta REVERSE_PROXY_TRUSTED_PROXIES = *. Quel carattere jolly dice a Gitea di fidarsi di qualsiasi indirizzo IP come se fosse un reverse proxy legittimo. Se sull'istanza è attiva anche l'autenticazione tramite reverse proxy — una funzione usata di frequente per integrare i sistemi di single sign-on aziendali — allora chiunque riesca a raggiungere la porta del servizio può inviare l'intestazione HTTP X-WEBAUTH-USER con dentro un nome utente qualsiasi, incluso admin o gitea_admin, e viene autenticato come quell'utente. Nessuna password, nessun token, nessun secondo fattore: un solo header e l'accesso è completo.

Sono interessate le immagini Docker di Gitea fino alla 1.26.2 compresa. La correzione, rilasciata a fine giugno, rimuove il carattere jolly e rende l'autenticazione via reverse proxy una funzione opt-in, da abilitare esplicitamente. La patch fa parte di una security release più ampia che ha chiuso nove CVE nell'ecosistema Gitea/Forgejo.

Sul fronte dello sfruttamento, la telemetria di Sysdig ha registrato la prima attività in rete tredici giorni dopo la divulgazione: una ricognizione automatizzata partita da un nodo di uscita ProtonVPN, con scansione delle porte HTTP(S), fingerprinting delle installazioni Gitea e tentativi di bypass tramite l'header X-WEBAUTH-USER. Le stime parlano di circa 6.200 server Gitea esposti e potenzialmente vulnerabili nella prima ondata, mentre i motori di ricerca per dispositivi esposti contano centinaia di migliaia di istanze raggiungibili in rete.

Cosa significa per le aziende italiane

Gitea è la scelta tipica di chi vuole tenere il codice in casa. È leggero, si installa in autonomia e viene adottato da software house, PMI tecnologiche, team di sviluppo interni della pubblica amministrazione e da tutte quelle realtà — banche, difesa, sanità — che per policy non possono affidare il proprio codice sorgente a piattaforme cloud esterne. Proprio questa vocazione "on-premise" crea un falso senso di sicurezza: "il nostro Git è interno, quindi è protetto". Ma molte istanze finiscono comunque esposte in rete per abilitare l'accesso in smart working, l'integrazione con pipeline CI/CD esterne o con collaboratori remoti.

Il valore in gioco è enorme. Un attaccante che si impersona come amministratore non guadagna solo la lettura del codice: ottiene le chiavi del regno. I repository contengono spesso secret di configurazione, token di accesso, chiavi API, credenziali di database e deploy key verso gli ambienti di produzione. Con quei materiali si passa dal furto del codice al compromesso della catena di distribuzione del software: un aggressore può inserire una backdoor in un commit, alterare una pipeline di build e propagare codice malevolo a valle, verso i clienti dell'azienda. È lo schema dei più gravi attacchi supply chain degli ultimi anni, e qui il punto d'ingresso è banale come un header HTTP.

Il contesto normativo rende il rischio ancora più concreto. La direttiva NIS2 mette la sicurezza della catena di approvvigionamento tra gli obblighi dei soggetti essenziali e importanti: un'istanza Gitea esposta e non aggiornata è esattamente il tipo di anello debole che la norma chiede di presidiare. E se tra i segreti esposti figurano credenziali che danno accesso a dati personali — cosa frequente nelle configurazioni applicative — la violazione ricade sotto il GDPR, con l'obbligo di notifica al Garante entro 72 ore e la comunicazione ad ACN/CSIRT Italia per i soggetti tenuti.

Cosa fare subito

  • Aggiornare immediatamente a Gitea 1.26.3 o versione successiva, ricreando i container dalle immagini Docker aggiornate. È l'unica correzione definitiva.
  • Verificare la configurazione in app.ini: controllare i valori di ENABLE_REVERSE_PROXY_AUTHENTICATION e REVERSE_PROXY_TRUSTED_PROXIES. Se non si usa l'autenticazione via reverse proxy, disabilitarla. Se la si usa, restringere REVERSE_PROXY_TRUSTED_PROXIES ai soli IP reali del proxy, mai *.
  • Non esporre la porta di Gitea direttamente in Internet: farla precedere da un reverse proxy configurato per rimuovere l'header X-WEBAUTH-USER in arrivo dai client esterni, così che solo il proxy possa impostarlo.
  • Ruotare i segreti potenzialmente compromessi — token, chiavi API, deploy key, credenziali di database — se l'istanza era raggiungibile in rete ed eseguiva una versione vulnerabile.
  • Analizzare i log alla ricerca di header X-WEBAUTH-USER anomali, accessi amministrativi inattesi, creazione di token o modifiche ai permessi dei repository nelle ultime settimane.
  • Ridurre l'esposizione: collocare gli strumenti di sviluppo dietro una VPN o un modello zero-trust, evitando che siano direttamente raggiungibili dall'esterno.

CVE-2026-20896 è il promemoria che gli strumenti interni di sviluppo sono infrastruttura critica a tutti gli effetti. Un valore predefinito troppo permissivo, un'istanza lasciata esposta e un singolo header bastano a consegnare a un estraneo l'intera base di codice di un'azienda. Aggiornare Gitea e chiudere il carattere jolly nella configurazione è un intervento di pochi minuti che vale la sicurezza di tutta la catena di sviluppo.