Zimbra Collaboration Suite (ZCS) è di nuovo sotto attacco. La vulnerabilità CVE-2026-73570, corretta a luglio, è ora sfruttata attivamente in rete: il CERT polacco ha lanciato l'allarme il 17 agosto e la CISA statunitense ha inserito la falla nel catalogo KEV il 21 agosto. Per chi gestisce un server Zimbra esposto su internet la finestra di tolleranza è chiusa.
I fatti
CVE-2026-73570 è una OS command injection con punteggio CVSS 8.9 che risiede nel componente di monitoraggio SNMP di Zimbra. A causa di una sanificazione insufficiente dell'input durante l'elaborazione delle notifiche SNMP, un attaccante non autenticato può inviare richieste SMTP appositamente costruite e ottenere l'esecuzione di comandi di sistema arbitrari con i privilegi dell'utente zimbra.
Le condizioni perché l'installazione sia vulnerabile sono precise: deve essere installato il pacchetto opzionale zimbra-snmp, le notifiche SNMP devono essere abilitate tramite il parametro snmp_notify e il servizio swatchdog deve essere in esecuzione. Quest'ultimo, però, è attivo per impostazione predefinita quando il pacchetto è presente: chi ha installato zimbra-snmp anni fa per collegare Zimbra a un sistema di monitoraggio e poi se ne è dimenticato è probabilmente esposto senza saperlo.
La patch esiste dal 20 luglio 2026 con la versione 10.1.20. Il 17 agosto CERT Polska ha pubblicato l'alert 145/2026 segnalando lo sfruttamento in corso; quattro giorni dopo la CISA ha aggiunto la CVE al catalogo delle vulnerabilità note sfruttate. Shadowserver, nel frattempo, conta oltre 12.100 server Zimbra raggiungibili da internet, di cui 4.382 in Europa e 4.492 in Asia. Non è dato sapere quanti siano già aggiornati o quanti siano honeypot, ma l'ordine di grandezza della superficie di attacco è chiaro.
Perché "solo utente zimbra" non è una consolazione
Un errore ricorrente nella valutazione del rischio è liquidare l'impatto perché il codice non gira come root. L'utente zimbra possiede il mailstore, la configurazione LDAP locale, i certificati TLS del servizio e il processo mailboxd. Chi controlla quell'utente controlla tutte le caselle di posta del sistema, può leggerle, esportarle, creare regole di inoltro e generare token di accesso. L'escalation a root, se serve, è un problema successivo e spesso banale su un sistema non aggiornato.
Cosa significa per le aziende italiane
Zimbra ha in Italia una diffusione superiore alla media europea, per ragioni molto concrete: è l'alternativa on-premise a Microsoft 365 scelta da enti locali, ordini professionali, studi e PMI che volevano contenere i costi per casella o mantenere i dati su infrastruttura propria o nazionale. Molti provider italiani lo rivendono come servizio di posta gestita.
Il problema, in questo scenario, non è tecnico ma organizzativo: nella maggior parte dei casi il server Zimbra è installato e mantenuto da un fornitore esterno — un system integrator o un ISP — mentre il titolare del trattamento è l'azienda cliente. Quando esce una CVE come questa, la domanda "chi applica la patch, entro quando, e chi verifica che sia stata applicata" spesso non ha una risposta scritta da nessuna parte. Il rischio, però, ricade sul titolare.
C'è poi un precedente storico che vale la pena ricordare. Zimbra è un bersaglio ricorrente dello spionaggio statale: nel 2023 il gruppo russo Winter Vivern ha usato una XSS per sottrarre email di organizzazioni legate alla NATO, nel 2024 le agenzie di Stati Uniti e Regno Unito hanno segnalato APT29 all'attacco di server Zimbra, e a marzo 2026 APT28 ha sfruttato una XSS memorizzata contro server governativi ucraini. Con l'ingresso nel catalogo KEV, però, lo sfruttamento smette di essere appannaggio di attori sofisticati e diventa massivo e opportunistico: chiunque scansiona internet in cerca di server non aggiornati.
Il rischio concreto per una PMI o un comune italiano è che la casella di posta non è "solo posta". È il canale di reset password di quasi tutti gli altri servizi aziendali, l'archivio di fatture, contratti e coordinate bancarie, e il punto di partenza ideale per una frode BEC sul cambio IBAN.
Il profilo normativo
Un accesso non autorizzato a un archivio di posta è quasi sempre una violazione di dati personali notificabile: le mailbox contengono per definizione dati di clienti, dipendenti e fornitori, e spesso categorie particolari (basti pensare ai certificati medici che transitano dalle risorse umane). Scattano quindi l'articolo 33 del GDPR con la notifica al Garante entro 72 ore dalla conoscenza, e l'articolo 34 con la comunicazione agli interessati se il rischio per i loro diritti è elevato.
Per i soggetti rientranti nel perimetro NIS2 (D.Lgs. 138/2024) si aggiungono gli obblighi verso ACN: pre-allarme entro 24 ore e notifica entro 72 ore. Il sistema di posta è quasi sempre classificabile come servizio critico nella categorizzazione richiesta dall'Autorità.
C'è un aspetto probatorio che nella pratica pesa più della norma: se il fornitore non conserva log sufficienti a ricostruire cosa è accaduto, non riuscirete a dimostrare che la compromissione non c'è stata. L'articolo 5(2) del GDPR mette l'onere della dimostrazione in capo al titolare, e "non abbiamo trovato prove" senza log non è una posizione difendibile.
Cosa fare subito
- Verificare la versione con
zmcontrol -v. Se è inferiore a 10.1.20, aggiornare senza attendere la finestra di manutenzione ordinaria. - Controllare se SNMP è attivo:
su - zimbra -c "zmlocalconfig | grep snmp"e verificare il valore disnmp_notify. - Mitigazione temporanea se non potete aggiornare subito: disabilitare le notifiche SNMP e fermare o rimuovere il pacchetto
zimbra-snmpe il servizioswatchdog, dove operativamente sostenibile. - Threat hunting secondo le indicazioni di CERT Polska: cercare file creati dall'utente
zimbranegli ultimi 30 giorni in/opt/zimbra/jetty/webapps/,/opt/zimbra/jetty_base/webapps/e/tmp/, e verificare nei log eventuali riavvii spontanei del servizio Zimbra. - Se trovate indicatori, presumete la compromissione delle caselle: invalidate tutte le sessioni attive, forzate il cambio password, revocate token e password applicative, e soprattutto controllate le regole di inoltro automatico create sulle mailbox, tecnica di persistenza classica che sopravvive al cambio password.
- Ridurre l'esposizione: le porte di gestione e SNMP non devono essere raggiungibili da internet, punto.
- Mettere per iscritto con il fornitore uno SLA di patching esplicito per le CVE presenti nel catalogo KEV. È l'unico modo per trasformare una discussione a incidente avvenuto in un obbligo contrattuale verificabile.