Una vulnerabilità critica nel motore di rendering di Gitea consente a un attaccante non autenticato di leggere file arbitrari sul server tramite una direttiva del linguaggio Org-mode. La falla, pubblicata il 2 agosto 2026 dall'advisory GHSA-6v53-hr58-556r, ha ottenuto il punteggio massimo per questa classe di bug: CVSS 9.8. La catena di escalation verso esecuzione remota, descritta nell'advisory ufficiale del progetto, rimane teoricamente valida ma non è stata dimostrata indipendentemente al momento della pubblicazione.
- CVE-2026-59774 colpisce Gitea dalla versione 1.22.1 alla 1.27.0 con un attacco non autenticato via endpoint POST /{owner}/{repo}/markup
- Il vettore sfrutta la direttiva
#+INCLUDEdel markup Org-mode, che passa path assoluti al filesystem attraverso il callback ReadFile non sostituito di go-org 1.9.1 - Il fix nella versione 1.27.1 sostituisce il callback per restituire il path come contenuto anziché risolverlo dal filesystem
- La catena RCE documentata nell'advisory procede da lettura di app.ini a furto di INTERNAL_TOKEN e iniezione di Git hook, ma non ha ricevuto verifica indipendente né exploit pubblico
Il meccanismo: quando il rendering del markup diventa syscall al filesystem
Gitea utilizza la libreria go-org 1.9.1 per il rendering dei file in formato Org-mode, un linguaggio di markup leggero originato nell'ecosistema Emacs. L'inizializzazione di default di go-org espone un callback ReadFile che punta a ioutil.ReadFile, una funzione di lettura diretta dal filesystem. Gitea non sostituisce questo callback con un handler sandboxato.
La direttiva #+INCLUDE del markup Org-mode è progettata per incorporare contenuti esterni. Nell'implementazione vulnerabile, accetta path assoluti del filesystem server e li passa direttamente al callback ReadFile senza validazione. Un attaccante può quindi inviare una richiesta POST all'endpoint /{owner}/{repo}/markup con parametri Mode: file e filename: .org contenente una direttiva #+INCLUDE puntante a qualsiasi file leggibile dall'account di servizio Gitea.
L'attacco richiede solo l'esistenza di almeno un repository pubblico con la code unit abilitata. Non è necessaria autenticazione né permessi di scrittura sul repository.
"An unauthenticated remote attacker can submit Org-mode markup containing a #+INCLUDE directive to POST /{owner}/{repo}/markup for any suitable public repository to read arbitrary server files" — GitHub Advisory GHSA-6v53-hr58-556r
Da file read a RCE: la catena teorica dell'advisory
L'advisory ufficiale di Gitea descrive una catena di escalation che trasforma la lettura arbitraria di file in esecuzione remota. Il percorso inizia con l'esfiltrazione del file app.ini, che contiene il parametro INTERNAL_TOKEN utilizzato per le comunicazioni interne del servizio. Con questo token, un attaccante potrebbe iniettare un Git hook attraverso il meccanismo di internal logging, ottenendo esecuzione di comandi come utente del sistema operativo che esegue Gitea durante un clone anonimo.
Questa catena è documentata esclusivamente nell'advisory del progetto. Secondo The Hacker News, "the token-to-hook command-execution chain remains single-sourced to Gitea's advisory": nessun ricercatore indipendente ha pubblicato un proof-of-concept che la dimostri, e non risultano exploitation in the wild confermate al 5 agosto 2026. La falla non è presente nel catalogo KEV della CISA.
La distinzione tra primitive file-read verificata e catena RCE teorica è rilevante per la valutazione del rischio. La lettura di file arbitrari è immediatamente sfruttabile e può esporre configurazioni, credenziali di database, chiavi API e altri secret senza interazione dell'amministratore. L'escalation a RCE richiede condizioni aggiuntive non quantificate pubblicamente.
Chi ha scoperto la falla: il ruolo emergente degli strumenti autonomi
La scoperta principale è attribuita a XBOW Security, un sistema autonomo di offensive security che esegue ricerca di vulnerabilità senza intervento umano diretto. Il triage tecnico è stato condotto da Guido Leo. Una segnalazione indipendente, ricevuta prima o in parallelo, proviene da Shai Rod, noto come NightRang3r.
Questo profilo di scoperta segnala una evoluzione nel panorama della ricerca su vulnerabilità: gli strumenti di offensive security autonomi stanno producendo risultati confrontabili con quelli dei team umani tradizionali, almeno per classi di bug dove la superficie di attacco è definita da API documentate e formati di parsing. Per Gitea, un progetto open source con codebase pubblica e endpoint standardizzati, la combinazione di analisi automatica e revisione umana ha individuato una falla che precedenti audit avevano mancato.
Il preview del primitive file-read è stato pubblicato prima dell'advisory formale, secondo The Hacker News. Il brief non specifica se questo anticipo abbia generato tentativi di exploitation attiva prima della disponibilità della patch.
Cosa fare adesso
- Aggiornare immediatamente le istanze self-hosted a Gitea 1.27.1, che contiene il fix nei pull request #38642 e #38645
- Verificare che le istanze Cloud siano state aggiornate automaticamente durante la finestra di manutenzione del rilascio, secondo quanto dichiarato da Gitea a The Hacker News
- Ruotare proattivamente
INTERNAL_TOKENe altri secret presenti inapp.inianche dopo il patching, data la possibilità di esfiltrazione pre-patch - Limitare l'esposizione di repository pubblici con code unit abilitata dove non strettamente necessario, riducendo la superficie di attacco
Perché il vettore Org-mode sfida le difese tradizionali
La scelta di Org-mode come vettore di attacco ha conseguenze per la detection. I formati di markup leggeri non rientrano tipicamente nel perimetro di analisi dei sistemi di sicurezza, che privilegiano eseguibili, script e payload noti. Una richiesta POST a un endpoint di rendering con contenuto Org-mode legittimo è indistinguibile dal traffico normale senza ispezione semantica del payload.
Il caso solleva inoltre una questione architetturale ricorrente: l'integrazione di librerie di parsing "innocue" in applicazioni con privilegi elevati. go-org è una libreria di rendering testuale; il suo callback ReadFile non è documentato come pericoloso se non configurato correttamente. L'assenza di sandboxing predefinita, combinata con la mancata sostituzione del callback da parte di Gitea, ha creato una primitive di attacco dove nessuno si aspetterebbe di trovarla.
Le istanze self-hosted restano la superficie più esposta. Gitea ha dichiarato che le istanze Cloud vengono aggiornate automaticamente, ma il brief non quantifica la completezza della rotazione dei secret in quel contesto. Per gli amministratori di istanze on-premise, la combinazione di patch immediato e rotazione preventiva dei token rappresenta la risposta più conservativa.
Fonti
- https://thehackernews.com/2026/08/critical-gitea-flaw-let-unauthenticated.html
- https://thomasharris6.wordpress.com/2026/08/05/critical-gitea-flaw-let-unauthenticated-attackers-read-server-files-via-org-mode-markup/
- https://cybersecuritynews.com/gitea-arbitrary-file-read-vulnerability/
- https://blog.rankiteo.com/gan1785839090-gitea-vulnerability-august-2026/
- https://gbhackers.com/critical-gitea-flaw/
- https://github.com/advisories/GHSA-6v53-hr58-556r
- https://github.com/go-gitea/gitea/security/advisories/GHSA-6v53-hr58-556r
- https://thehackernews.com/
- https://thehackernews.com/p/upcoming-hacker-news-webinars.html
- https://thehackernews.com/search/label/Threat%20Intelligence
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.