XSS nella webmail Zimbra: l'email che svuota la casella

Il 7 luglio Zimbra ha rilasciato Collaboration 10.1.19 con una nota di sicurezza di una riga: una stored cross-site scripting nel Classic Web Client, segnalata dal Threat Analysis Group di Google. Nessun CVE. Nessun CVSS. Nessun proof-of-concept. Solo un urgente "aggiornate il Classic Web Client il prima possibile" e un salto di versione. Per una piattaforma di posta che, secondo i numeri della stessa Zimbra, serve centinaia di milioni di utenti tra migliaia di aziende e centinaia di enti governativi, questa non è una patch silenziosa. È la forma esatta dell'ultimo zero-day nella webmail Zimbra che gli attori statuali stavano già sfruttando prima che chiunque, al di fuori di TAG, ne conoscesse l'esistenza.

Se gestisci Zimbra, la domanda interessante non è "quanto è grave la XSS". È "cosa succede nei 30 giorni tra una patch webmail rilasciata in sordina e il giorno in cui ti accorgi che le caselle sono state lette". Questo articolo parla di quel divario, e di come chiuderlo.

Cosa chiude davvero la patch XSS della webmail Zimbra

La correzione risiede in due pacchetti — zimbra-patch e zimbra-mbox-webclient-war — inclusi nella release Daffodil 10.1.19 del 7 luglio 2026. La vulnerabilità è una stored XSS nel Classic Web Client: un'email appositamente costruita trasporta JavaScript che viene eseguito all'interno della sessione webmail autenticata del destinatario nel momento in cui il messaggio viene renderizzato. La copertura di BleepingComputer conferma Google TAG come segnalatore e nota che Zimbra non ha (ancora) marcato la falla come sfruttata in the wild.

Tre proprietà la rendono peggiore di una XSS ordinaria:

• È stored, non reflected. Il payload risiede nella casella. La vittima non deve cliccare un link avvelenato — è sufficiente che il messaggio venga renderizzato. Con un riquadro di anteprima, è di fatto zero-click.
• Gira con la sessione della vittima. Il JavaScript nel DOM di una sessione Zimbra autenticata può fare tutto ciò che può fare l'utente: leggere ogni cartella, effettuare chiamate REST/SOAP, impostare filtri e sottrarre il token di autenticazione.
• Il Classic Web Client è il default legacy che non se n'è mai andato. È l'interfaccia Ajax più leggera che molte organizzazioni tengono attiva proprio perché più veloce sulle cartelle grandi. The Hacker News nota che il client moderno non è la superficie colpita — ma "noi usiamo solo il client moderno" è un'affermazione che la maggior parte degli amministratori non ha verificato account per account.

Nelle note di rilascio non c'è né un identificativo CVE né un punteggio CVSS. Non leggetelo come "minore". Leggetelo come "non arriverà una voce KEV a forzare la vostra triage, quindi la triage dovete farla voi".

Perché la segnalazione di Google TAG è il vero segnale

TAG non insegue bug web qualunque. Traccia lo sfruttamento da parte di attaccanti sponsorizzati da governi, e la webmail Zimbra è uno dei suoi dossier ricorrenti — non per caso. Un server di posta self-hosted, ricco di utenti governativi e raggiungibile da internet, è il bersaglio più prezioso che una squadra di spionaggio possa desiderare: contiene la corrispondenza, e una XSS nella webmail permette di portarla via senza rilasciare un binario che un EDR potrebbe intercettare.

Il precedente è puntuale. Nel 2023, TAG ha scoperto uno zero-day XSS in Zimbra Collaboration attivamente sfruttato — poi corretto come CVE-2023-37580 — e ha osservato quattro gruppi distinti sfruttarlo contro organizzazioni governative in Vietnam, Grecia, Tunisia e Pakistan. Winter Vivern (UNC4907), un APT con una documentata predilezione per le XSS in Zimbra e Roundcube, era uno di essi. Il dettaglio da fissare a memoria: Zimbra ha pubblicato l'hotfix sul GitHub pubblico il 5 luglio 2023, e tre dei quattro gruppi hanno sfruttato il bug intorno e dopo quella pubblicazione — perché una correzione di codice pubblica, su un bug privo di advisory, è una mappa per chiunque tenga d'occhio il repository.

Quel pattern non si è raffreddato. Secondo il resoconto di BleepingComputer, le falle Zimbra sono state sfruttate di nuovo negli ultimi quattro mesi — CVE-2025-66376 legata ad APT28 a marzo, e CVE-2025-48700 con oltre 10.500 istanze vulnerabili ancora esposte ad aprile. Quando lo stesso prodotto finisce di continuo sulla scrivania di TAG, il tasso di base per "questa è già in uso" non è basso.

L'email malevola non è la mailbox exfiltration che intercetterai

Ecco la parte operativamente importante, e il motivo per cui la maggior parte delle vittime Zimbra scopre la compromissione dall'attaccante anziché da un sensore.

Il perimetro non può vedere l'exploit. L'email malevola arriva su SMTP cifrato in TLS; il tuo secure email gateway vede un messaggio senza allegato e senza macro. Il payload diventa codice solo dentro il browser, nel DOM di una sessione già autenticata — lato server e lato rete, nulla appare anomalo nella consegna. Non c'è dropper, non c'è file PE, non c'è handshake C2 nel momento della compromissione.

Ciò che viene dopo è dove risiede davvero il segnale:

Analista: "Il gateway ha registrato la mail in ingresso come pulita. L'endpoint non ha visto nulla. Allora come hanno preso la posta di tre ministeri?" Realtà: "Non hanno mai toccato un endpoint. Il token è stato sottratto in-sessione, e le caselle sono uscite via IMAP e REST — verso un ASN con cui questa rete non aveva mai parlato — nel corso delle due settimane successive."

Post-compromissione, una catena XSS su webmail segue un copione stabile che si mappa in modo pulito su MITRE ATT&CK:

Fase	Tecnica ATT&CK	Come appare sul filo
Consegna	T1566 Phishing	Mail in ingresso, TLS, nessun allegato — invisibile
Esecuzione	T1059.007 JavaScript	Solo nel browser — nessun artefatto sull'host
Accesso credenziali	T1539 Steal Web Session Cookie	Furto del token, riusato da un nuovo IP/ASN
Raccolta	T1114.002 Remote Email Collection	Letture IMAP/REST massive di intere caselle
Persistenza	T1114.003 Email Forwarding Rule	Regole di inoltro/filtro silenziose lato server
Esfiltrazione	T1041 / T1020	Volume in uscita sostenuto verso una destinazione mai vista

Ogni riga dopo "Esecuzione" è un evento di rete. L'export massivo delle caselle, il token rigiocato da un ASN sconosciuto, la regola di inoltro che copia in silenzio ogni messaggio in arrivo: sono esattamente i comportamenti che lasciano l'endpoint pulito e accendono il filo. Il report TAG del 2023 diceva che i quattro gruppi usarono il bug "per rubare dati di posta, credenziali utente e token di autenticazione". Di quell'obiettivo non è cambiato nulla; manca solo il numero di CVE.

Il timing della patch è una trappola

La combinazione no-CVE più segnalazione-TAG crea una modalità di fallimento specifica:

• Nessuna voce KEV (per ora) significa nessuna scadenza guidata da una direttiva che popola automaticamente la coda dei ticket. Con i livelli risk-based della BOD 26-04, un bug guadagna un orologio obbligatorio solo una volta catalogato — una patch di vendor silenziosa no.
• Nessun CVSS significa che il tuo strumento di vulnerability management potrebbe non assegnarle nemmeno un punteggio, quindi non supera mai la tua soglia di severità per un change d'emergenza.
• Il salto di versione pubblico telegrafa la correzione. Come nel 2023, il diff tra 10.1.18 e 10.1.19 è un colpo di pistola per chi vuole reverse-engineerizzare la patch più in fretta di quanto il tuo tenant più lento la applichi.

La conclusione non è "patcha più in fretta" — lo sai già. È che tra la patch e il deployment completo, la tua unica visibilità sul fatto che qualcuno sia entrato prima è comportamentale, sulla rete, non basata su firme sull'host.

Remediation

Trattala come un esercizio assume-breach, non come un semplice ticket di patch. Il Classic Web Client è stato raggiungibile e vulnerabile da ben prima del 7 luglio.

1. Sono interessato?

Verifica la versione e se il Classic Web Client è effettivamente abilitato:

su - zimbra
zmcontrol -v                 # qualsiasi versione sotto la 10.1.19 è vulnerabile
zmprov gcf zimbraWebClientClassicAppEnabled   # TRUE = il client legacy è attivo

Se zimbraWebClientClassicAppEnabled è TRUE (default su molti deployment aggiornati), gli utenti possono raggiungere l'interfaccia vulnerabile indipendentemente dal client che "di solito" usano.

2. Patch — versione corretta esatta

Aggiorna a Zimbra Collaboration 10.1.19 (Daffodil), che rilascia i pacchetti corretti zimbra-patch e zimbra-mbox-webclient-war. Conferma con zmcontrol -v dopo il riavvio. Verifica la pagina Zimbra Security Advisories per la release corrente prima del deploy.

3. Non puoi patchare subito? — controlli compensativi

• Disabilita globalmente il Classic Web Client finché non patchi: zmprov mcf zimbraWebClientClassicAppEnabled FALSE, poi zmcontrol restart. Gli utenti ripiegano sul client moderno, che non è la superficie colpita.
• Applica una Content-Security-Policy sul reverse proxy (script-src 'self') così gli script inline iniettati non vengono eseguiti anche se il payload arriva.
• Verifica che l'header sia attivo: curl -I https://mail.example.com | grep -i content-security-policy.

4. Caccia alla compromissione

Assumi che la finestra fosse aperta prima della patch. Cerca le conseguenze, non l'email:

• Inoltri / filtri malevoli (T1114.003): controlla ogni account per indirizzi di inoltro inattesi e regole Sieve.

  zmprov ga [email protected] zimbraPrefMailForwardingAddress zimbraMailSieveScript
  

• Letture anomale delle caselle (T1114.002): grep su mailbox.log e audit.log per operazioni SearchRequest/export di grandi dimensioni, e per sessioni IMAP/REST che scaricano intere cartelle a raffica.
• Riuso del token da nuove posizioni (T1539): correla l'uso del token di autenticazione tra IP/ASN sorgente; un token emesso per un ufficio e rigiocato da un ASN di un hosting provider è la prova schiacciante.
• Egress: volume in uscita sostenuto dall'host Zimbra verso una destinazione con cui non ha storia di comunicazione — l'esfiltrazione stessa.

5. Eradica + verifica

• Invalida ogni sessione attiva e forza la rotazione del token di autenticazione così che qualsiasi token rubato muoia (svuotando le sessioni in cache e riavviando il servizio mailbox; ruota le credenziali di ogni account con accessi anomali).
• Rimuovi le regole di inoltro piantate dall'attaccante: zmprov ma [email protected] zimbraPrefMailForwardingAddress "".
• Conferma la correzione con un test benigno: invia <script>alert('XSS_TEST')</script> a un account di prova e aprilo nel Classic Web Client. Dopo la patch deve essere renderizzato come testo inerte, non eseguito.
• Rivedi gli ultimi 30 giorni di audit.log prima di dichiarare chiuso l'incidente — la compromissione probabilmente precede la patch.

Dove si inserisce Zero Hunt

La lezione di questo bug è una lezione di detection: la compromissione è invisibile al punto d'ingresso e diventa visibile solo come comportamento sulla rete. È esattamente il divario che l'AI Traffic Analysis di Zero Hunt è stata costruita per chiudere. Il nostro modello di deep learning proprietario — addestrato su miliardi di sequenze PCAP, in esecuzione localmente sulla GPU dell'appliance con un baseline di 2,7+ Gbit/s e quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) — osserva il filo mentre l'attività sta accadendo. L'export IMAP/REST massivo di una casella che storicamente riceveva solo posta, un token di autenticazione rigiocato da un ASN mai visto, un egress improvviso e sostenuto da un host di posta: sono le firme di un'esfiltrazione webmail in corso, e compaiono sul filo nell'istante in cui l'attaccante inizia a estrarre i dati — non nel digest del SIEM del mattino dopo, e non settimane più tardi quando un partner ti dice che la tua corrispondenza è in vendita.

A monte, lo swarm di 10 agenti per il pentest generativo risponde all'altra metà: i suoi agenti Web e Credential concatenano stored-XSS-fino-al-furto-di-sessione come farebbe un avversario, per singolo target e per singolo ambiente, così trovi il Classic Web Client raggiungibile e il flusso di sessione sfruttabile prima dei successori di Winter Vivern. Ogni skill offensiva usata dallo swarm viene backtestata nell'AI Gym contro un corpus di esercizi web e di exploitation prima ancora di toccare il tuo ambiente di produzione — e tutto gira al 100% on-prem, il che conta quando l'asset che stai testando è il server di posta che contiene tutto. Guarda la panoramica della piattaforma o contattaci se una patch webmail silenziosa è appena arrivata nella tua coda di change.