Gitea sotto attacco con Red Heron: Telegram e Windows mostrano i limiti delle patch

🛡️ Executive Summary

• Red Heron ha trasformato CVE-2026-60004 in una catena automatizzata contro Gitea pochi giorni dopo la pubblicazione del PoC.
• Telegram Desktop ha corretto una stored XSS negli export HTML, ma i file creati con versioni vulnerabili possono conservare payload attivi.
• Microsoft distribuisce aggiornamenti fuori banda per i guasti RDS introdotti dalle patch di settembre, lasciando però irrisolti alcuni problemi USB Audio.

Tre incidenti molto diversi mostrano lo stesso problema operativo: installare una patch non significa automaticamente chiudere il rischio. Il gruppo denominato Red Heron ha trasformato rapidamente una vulnerabilità già corretta di Gitea in uno strumento per rubare repository e muoversi nelle infrastrutture delle vittime; Telegram Desktop ha eliminato una stored XSS dal proprio codice, ma non può bonificare gli export HTML già salvati dagli utenti; Microsoft ha invece dovuto pubblicare aggiornamenti fuori banda dopo che le patch di sicurezza di settembre avevano reso instabili i Remote Desktop Services. Tre casi che spostano l’attenzione dalla semplice disponibilità della correzione alla gestione dell’intero periodo di esposizione.

Red Heron trasforma la RCE di Gitea in una catena di compromissione

Il caso più grave riguarda CVE-2026-60004, vulnerabilità critica con punteggio CVSS 9,8 che interessa Gitea dalla versione 1.17 alla 1.27.0. Il problema era stato eliminato il 27 luglio 2026 con Gitea 1.27.1 e descritto il giorno successivo nell’advisory ufficiale pubblicato dal progetto Gitea. L’endpoint diffpatch permetteva a un utente con accesso in scrittura a un repository di sfruttare il comportamento di git apply per scrivere un file dentro $GIT_DIR/hooks e ottenere l’esecuzione di comandi come utente del servizio Gitea. Nelle installazioni con registrazione aperta, configurazione predefinita, un aggressore esterno poteva crearsi autonomamente l’account e il repository necessari. La vulnerabilità era stata già ricostruita nell’analisi del 29 luglio su Gitea 1.27.1 e sulla trasformazione di una patch in un Git hook eseguibile, ma l’indagine successiva di Acronis Threat Research Unit mostra cosa accade quando il tempo tra disclosure e aggiornamento diventa spazio operativo per un attaccante. Red Heron ha iniziato a modificare un PoC pubblico già il 29 luglio, il giorno successivo alla pubblicazione dell’advisory; entro il 30 luglio aveva scandagliato 1.386 istanze Gitea in sette Paesi utilizzando 50 thread concorrenti per identificare quelle con registrazione aperta, alle quali si aggiungeva un dataset separato di 477 sistemi localizzati a Taiwan. Dei sistemi censiti, 128 istanze con signup aperto sono state trasformate in una lista prioritaria di possibili obiettivi.

JITTERLY e SIXZUT mostrano il costo reale del ritardo nell’aggiornamento

La differenza tra una vulnerabilità teoricamente chiusa e una compromissione realmente risolta emerge nella fase successiva. La ricostruzione tecnica di Acronis TRU sulla campagna Red Heron documenta il passaggio da un semplice exploit a un framework capace di registrare automaticamente account, sfruttare le istanze vulnerabili, scaricare repository e cancellare alcune tracce dal database Gitea. Le compromissioni osservate hanno coinvolto organizzazioni in Canada, Argentina, Taiwan, Stati Uniti e Sri Lanka, con furto di codice sorgente, credenziali, database e segreti applicativi. In un ambiente taiwanese l’accesso iniziale ha permesso all’operatore di arrivare fino ai privilegi root su un cluster Proxmox composto da tre nodi. L’infrastruttura dell’attaccante ha inoltre esposto JITTERLY, impianto Linux scritto in C++ con oltre 30 funzioni di post-exploitation, tra shell remota, trasferimento file, tunneling e pivoting, insieme a SIXZUT, rootkit basato su LD_PRELOAD in grado di nascondere processi, file e connessioni di rete e riavviare l’impianto se terminato. Acronis attribuisce con confidenza moderata l’operazione a un contesto collegato alla Repubblica Popolare Cinese, ma precisa di non avere elementi sufficienti per associarla a un gruppo già conosciuto. Per un sistema sul quale siano emerse prove di compromissione, aggiornare Gitea non elimina quindi persistence, chiavi SSH, credenziali sottratte o eventuali pivot già realizzati: la bonifica deve comprendere rotazione dei segreti, verifica degli asset raggiungibili e, dove necessario, ricostruzione dell’host.

Leggi anche: Gitea entra nel KEV e gli agenti AI aprono nuove vie all’esecuzione di codice

Telegram corregge il codice ma non gli export HTML già creati

Un meccanismo diverso produce lo stesso problema di rischio residuo in Telegram Desktop. I ricercatori di ExPatch hanno individuato una stored XSS nel processo utilizzato dal client desktop per esportare le conversazioni in HTML: il testo dei pulsanti delle inline keyboard veniva inserito nel documento senza la corretta sanitizzazione, consentendo a un payload JavaScript opportunamente costruito di restare invisibile nell’interfaccia Telegram e diventare invece eseguibile quando l’utente esportava la chat e apriva il file in un browser. La ricerca tecnica pubblicata da ExPatch assegna al problema un CVSS 8,2 High e precisa che, all’11 settembre, non risultava ancora un CVE pubblico. L’impatto richiede un’interazione precisa della vittima, perché il file deve essere esportato e successivamente aperto, ma lo script può leggere messaggi e metadati presenti nel documento e manipolarne il DOM. Telegram ha corretto il problema modificando il serializer: il commit del progetto Telegram Desktop sostituisce l’inserimento diretto di button.text.toUtf8() con SerializeString(button.text.toUtf8()). La correzione è entrata nella beta 6.9.4 e nella prima release stabile contenente il fix, 7.0.1 del 14 luglio. Il punto operativo più importante è però esterno all’applicazione aggiornata: gli export HTML generati prima della patch non vengono riscritti. Se contengono il payload, possono quindi continuare a eseguirlo. ExPatch raccomanda di rigenerare gli export dopo l’aggiornamento oppure di aprire quelli precedenti con JavaScript disabilitato.

Microsoft corregge RDS fuori banda dopo le patch di settembre

Nel caso Windows il rischio residuo nasce invece dalla correzione stessa. Microsoft ha pubblicato il 14 settembre 2026 una serie di aggiornamenti out-of-band dopo che gli update di sicurezza dell’8 settembre avevano introdotto instabilità nei Remote Desktop Services su numerose versioni client e server. Su Windows Server 2025, per esempio, KB5129235 corregge il problema causato da KB5122871: in alcuni ambienti le connessioni RDP fallivano dopo pochi minuti, il login poteva non riuscire e i server potevano bloccarsi durante la configurazione di Remote Desktop; potevano inoltre diventare non responsivi MMC, RDS Licensing Diagnoser, File Explorer e la pagina Windows Update. La documentazione ufficiale Microsoft per KB5129235 conferma la correzione, mentre Windows Server 2022 riceve KB5129237 e altre versioni dispongono dei rispettivi pacchetti fuori banda. Microsoft sottolinea che gli OOB sono cumulativi e incorporano le protezioni di sicurezza precedenti: la risposta corretta non è quindi rimuovere indiscriminatamente le patch di settembre, operazione che riaprirebbe le vulnerabilità corrette, ma distribuire l’aggiornamento successivo dopo i test necessari. Il ciclo non è ancora completamente chiuso: gli OOB risolvono anche i problemi delle periferiche USB Audio Class 1.0 in modalità 8 canali o 3D, mentre restano sotto indagine altri sintomi, tra cui dispositivi con Code 10, assenza di output e controlli del volume non responsivi.

Continua con:

• Windows 11 corregge il mouse, ma gli update rompono RDS ed Excel
• Microsoft Patch Tuesday settembre 2026: 966 falle e due zero-day già sfruttati

La sicurezza comincia dove finisce il semplice conteggio delle patch

Gitea, Telegram Desktop e Windows rappresentano tre classi differenti dello stesso problema. Nel primo caso la patch chiude la vulnerabilità, ma non dice se l’organizzazione sia stata compromessa prima dell’aggiornamento: servono hunting, revisione dei log, rotazione delle credenziali e controllo della persistence. Nel secondo la vulnerabilità viene eliminata dal software, mentre l’artefatto vulnerabile sopravvive fuori dal software sotto forma di file HTML già creati. Nel terzo l’aggiornamento di sicurezza introduce una regressione che costringe gli amministratori a gestire contemporaneamente continuità operativa e mantenimento delle protezioni appena distribuite. La metrica utile non è quindi soltanto quanti sistemi risultino formalmente aggiornati. Conta sapere quanto è durata la finestra di esposizione, quali effetti possono essere sopravvissuti alla patch e quali verifiche devono essere eseguite dopo l’installazione. Red Heron dimostra quanto rapidamente un n-day possa diventare un framework automatizzato; Telegram mostra che alcuni payload sopravvivono nei dati prodotti dall’applicazione; Microsoft ricorda che perfino una patch necessaria può introdurre un secondo problema operaivo. È in questa fase successiva all’aggiornamento che la gestione delle vulnerabilità smette di essere semplice patch management e diventa realmente gestione del rischio.