Bastano un repository pubblico e un frammento di testo formattato per estrarre file riservati da un server Gitea senza fornire alcuna credenziale. È CVE-2026-59774, punteggio CVSS 9.8, l'ennesima falla critica a colpire la piattaforma open source di gestione del codice negli ultimi due mesi. Interessa le versioni da 1.22.1 a 1.27.0, è corretta nella 1.27.1 rilasciata il 27 luglio, e diversi ricercatori indipendenti — tra cui Criminal IP e il team di runZero — ne confermano l'attivo interesse da parte di attaccanti dopo la divulgazione tecnica pubblicata da The Hacker News all'inizio di agosto.

Cosa è successo

Il problema nasce dal modo in cui Gitea elabora il markup Org-mode, un formato di testo usato per la documentazione dei repository che, come Markdown, viene reso automaticamente in HTML dall'interfaccia web. Un attaccante può inserire in un file Org-mode all'interno di un repository pubblico una sintassi costruita ad arte che, durante il rendering, induce il server a leggere e restituire il contenuto di file arbitrari del filesystem — non serve login, non serve un account, basta che il repository sia raggiungibile.

Il rischio non si ferma alla lettura di file: potendo accedere a file di configurazione, chiavi private, token interni o addirittura al database SQLite usato in molte installazioni leggere, un attaccante ottiene spesso il materiale sufficiente per scalare fino all'esecuzione di codice o al pieno controllo dell'istanza. Gitea ha risolto il problema nella versione 1.27.1, pubblicata il 27 luglio; è la stessa release che ha chiuso anche CVE-2026-60004, una falla distinta che permette a chi ha accesso in scrittura a un repository di piazzare un git hook malevolo in un clone temporaneo e ottenere esecuzione di comandi shell.

È la terza volta in due mesi che Gitea finisce sotto i riflettori per una falla critica: a luglio avevamo già trattato CVE-2026-20896, il bypass di autenticazione nelle immagini Docker sfruttato tredici giorni dopo la divulgazione. La ricorrenza non è casuale: più la piattaforma cresce in adozione, più diventa un bersaglio economicamente interessante per chi cerca un punto d'ingresso verso il codice sorgente e i segreti delle aziende che la usano.

Cosa significa per le aziende italiane

Gitea resta la scelta preferita di chi vuole tenere il codice sorgente in casa: software house, PMI tecnologiche, team interni della pubblica amministrazione, banche e realtà del settore sanitario o della difesa che per policy non possono affidarsi a piattaforme cloud esterne. La ripetizione di falle critiche in pochi mesi dovrebbe far riconsiderare un'idea diffusa: un'istanza self-hosted non è automaticamente più sicura di un servizio gestito, lo è solo se qualcuno si occupa attivamente di applicare gli aggiornamenti con la stessa urgenza riservata ai sistemi esposti al pubblico.

Il vettore d'attacco qui è particolarmente insidioso perché richiede solo un repository pubblico raggiungibile, condizione comune per progetti open source aziendali, portali documentali o istanze usate per condividere codice con partner e fornitori esterni. Un attaccante che estrae file di configurazione ottiene tipicamente token di accesso ad altri sistemi, credenziali di database o chiavi API: da lì il salto verso una compromissione della catena di distribuzione del software — l'inserimento di codice malevolo in una pipeline di build — è breve.

La direttiva NIS2 individua esplicitamente la sicurezza della catena di approvvigionamento software tra gli obblighi dei soggetti essenziali e importanti: un'istanza Gitea non aggiornata e raggiungibile da internet rientra precisamente nel tipo di debolezza che la norma chiede di individuare e correggere con un programma di gestione delle vulnerabilità. Se tra i dati esposti figurano informazioni personali — email di collaboratori, credenziali che aprono l'accesso a banche dati con dati dei clienti — scatta anche l'obbligo di notifica al Garante Privacy entro 72 ore.

Cosa fare subito

  • Aggiornare a Gitea 1.27.1 o versione successiva: è l'unica correzione definitiva per CVE-2026-59774 e CVE-2026-60004.
  • Se l'aggiornamento immediato non è possibile, verificare quali repository sono pubblici e valutare di renderli temporaneamente privati fino al completamento della patch.
  • Ruotare token, chiavi API e credenziali che potrebbero essere state esposte tramite file di configurazione leggibili dal server.
  • Analizzare i log delle richieste HTTP alla ricerca di pattern di rendering Org-mode anomali o richieste ripetute su percorsi di file di sistema.
  • Non esporre Gitea direttamente su internet: collocarlo dietro VPN o un accesso segmentato, riservando l'esposizione pubblica solo ai repository che devono davvero essere raggiungibili dall'esterno.
  • Includere Gitea (e gli strumenti DevOps self-hosted in genere) in un ciclo di patching con la stessa priorità riservata ai sistemi perimetrali, non trattarlo come infrastruttura "interna e quindi minore".

Tre falle critiche in due mesi non sono un caso isolato ma un trend: chi ospita il proprio codice su Gitea dovrebbe considerare gli aggiornamenti di sicurezza della piattaforma alla stregua di quelli di un firewall, non di uno strumento di produttività interno.