Una singola richiesta SMTP costruita ad arte può trasformare un server Zimbra esposto su Internet in un punto di accesso alla posta, alle credenziali e agli altri nodi del cluster. Non serve rubare prima una password e non serve che un utente apra un allegato. È la conseguenza concreta di CVE-2026-73570 quando sul server sono presenti il pacchetto opzionale zimbra-snmp e le notifiche SNMP sono abilitate.

Il problema è stato corretto in Zimbra Collaboration 10.1.20, pubblicato il 20 luglio 2026. Microsoft ha però osservato attività sulla stessa catena di esecuzione già tra il 28 luglio e il 7 agosto, prima della divulgazione pubblica del 13 agosto. Il 30 settembre ha documentato compromissioni con web shell, reverse shell, persistenza, raccolta di segreti e preparazione di archivi contenenti dati delle caselle.

Per una PMI che gestisce Zimbra in proprio, la domanda quindi non è soltanto «abbiamo installato la patch?». La domanda corretta è: «possiamo dimostrare che il server non è stato compromesso prima della patch?». Questa guida separa le due attività: chiudere la vulnerabilità e cercare le tracce lasciate da chi potrebbe averla già sfruttata.

Che cosa rende CVE-2026-73570 diversa da una normale falla email

CVE-2026-73570 è una command injection nel percorso usato da Zimbra per le notifiche SNMP. Un input non affidabile inserito in una richiesta SMTP può arrivare alla costruzione di un comando snmptrap. Se contiene metacaratteri della shell, il sistema può eseguirlo con i privilegi dell’account di servizio zimbra.

Il perimetro vulnerabile è preciso. Secondo Microsoft Security servono tre condizioni:

  • una versione Zimbra precedente alla 10.1.20;
  • il pacchetto opzionale zimbra-snmp installato;
  • le notifiche SNMP abilitate.

Queste condizioni non rendono il rischio trascurabile. Un mail server deve ricevere traffico SMTP da Internet per svolgere il proprio lavoro. Filtrare il pannello amministrativo o mettere la webmail dietro una VPN non elimina il percorso d’attacco. Se il flusso vulnerabile è attivo, l’input malevolo arriva attraverso una funzione legittima del server.

La scheda NVD della CVE classifica il problema come command injection senza autenticazione e indica come vulnerabili le versioni precedenti alla 10.1.20. Il punteggio pubblicato dal CNA è 8,9 su 10. Più del numero, conta però l’evidenza di sfruttamento reale: CISA ha inserito la vulnerabilità nel catalogo delle falle note come sfruttate.

Prima decisione: stabilire se il server è nel perimetro

La verifica iniziale richiede pochi minuti, ma va registrata. Annotare hostname, ruolo del nodo, versione rilevata, presenza del pacchetto e stato delle notifiche. In un cluster non basta controllare il nodo che espone la webmail: vanno verificati MTA, mailbox node e ogni host che condivide identità o fiducia amministrativa.

Su un’installazione Linux standard, un amministratore può controllare la versione dalla shell Zimbra e verificare il pacchetto con il gestore della distribuzione:

sudo -iu zimbra zmcontrol -v

# Debian/Ubuntu
dpkg -l | grep zimbra-snmp

# RHEL/Rocky/AlmaLinux
rpm -qa | grep zimbra-snmp

L’assenza di output dal controllo del pacchetto riduce il perimetro specifico di questa CVE, ma non sostituisce l’inventario delle versioni né la verifica degli altri nodi. Se il pacchetto esiste, controllare la configurazione delle notifiche secondo la documentazione e le procedure del proprio ambiente. Eviterei comandi copiati alla cieca che stampano tutta la configurazione: su Zimbra alcuni output possono includere segreti operativi e finire nella cronologia del terminale o in un ticket.

Il risultato va tradotto in una delle tre classi seguenti:

  • fuori perimetro specifico: nessun nodo usa zimbra-snmp con notifiche attive;
  • esposto ma non ancora verificato: prerequisiti presenti e versione precedente alla 10.1.20;
  • corretto ma da indagare: versione aggiornata, senza prova che il sistema fosse pulito prima dell’update.

La terza classe è quella che spesso viene saltata. Una patch modifica il software vulnerabile; non rimuove automaticamente una web shell, una chiave SSH aggiunta, un servizio systemd creato dall’attaccante o credenziali già copiate.

Patch e mitigazione: cosa fare nelle prime due ore

La correzione ufficiale è Zimbra Collaboration 10.1.20 o successiva. Le note di rilascio Zimbra 10.1.20 indicano esplicitamente la correzione della command injection nel componente di monitoraggio SNMP quando le notifiche sono abilitate. L’aggiornamento va eseguito con backup verificato, finestra di manutenzione e procedura prevista per l’edizione installata.

Se non è possibile aggiornare subito, Microsoft suggerisce di rimuovere il pacchetto opzionale zimbra-snmp, disabilitare le notifiche SNMP e restringere l’accesso SNMP e SMTP agli host fidati. Sono mitigazioni temporanee, non una chiusura del caso. Prima di cambiare configurazione, acquisire almeno i log e i metadati utili all’analisi: una modifica frettolosa può cancellare proprio la cronologia che serve a distinguere un server vulnerabile da un server compromesso.

Qui vale la stessa regola che applico alle vulnerabilità WordPress: la patch viene prima del WAF. Un filtro può ridurre esposizione e rumore, ma non corregge il punto in cui l’applicazione passa input non sanificato alla shell. Nel caso Zimbra, inoltre, SMTP è parte del servizio: bloccarlo indiscriminatamente significa spegnere la posta.

Una sequenza prudente è questa:

  1. identificare tutti i nodi e salvare versione, ruoli e configurazione rilevante;
  2. preservare log, alert EDR, cronologia dei file e snapshot disponibili;
  3. contenere gli host con evidenze sospette senza distruggere i dati forensi;
  4. aggiornare almeno alla 10.1.20 o applicare la mitigazione documentata;
  5. verificare di nuovo versione, servizi e raggiungibilità dopo il riavvio.

La patch non basta: cercare accesso e persistenza

Microsoft ha osservato una catena molto più ampia della semplice esecuzione iniziale. Gli attaccanti hanno scritto file JSP nelle directory delle applicazioni, avviato shell inverse, usato processi in memoria, creato meccanismi di persistenza e sfruttato la fiducia SSH tra nodi Zimbra. In alcuni ambienti hanno raccolto credenziali di servizio, chiavi di autenticazione e dati delle caselle.

La ricerca deve quindi essere comportamentale. Una scansione antivirus senza rilevamenti non dimostra che il server sia pulito: parte dell’attività osservata usava una normale shell e utility già presenti nel sistema.

Controllerei almeno questi gruppi di segnali, confrontandoli con la normale attività amministrativa:

  • processi shell avviati da Perl, Java, jspawnhelper o dal percorso SNMP di Zimbra;
  • invocazioni anomale di snmptrap seguite da metacaratteri shell, download con curl o wget e callback DNS/HTTP;
  • file .jsp, sorgenti *_jsp.java o artefatti compilati creati di recente nelle directory web e di lavoro di Jetty/mailboxd;
  • nuove unità systemd, modifiche a cron, profili shell, authorized_keys, utenti locali e regole sudoers;
  • archivi inattesi sotto /tmp o /opt/zimbra, soprattutto vicino a eventi di rete in uscita;
  • uso insolito dell’identità SSH condivisa di Zimbra o trasferimenti rsync tra nodi.

Le query Microsoft pubblicate insieme all’analisi sono un buon riferimento per chi usa Defender XDR, ma l’idea si applica anche ad altri SIEM ed EDR: cercare la relazione tra processo padre, shell, file scritto e connessione in uscita. Un hash da solo invecchia in fretta; una catena di comportamento è più difficile da cambiare senza rompere l’attacco.

Se trovi una traccia, trattala come compromissione del dominio mail

Una reverse shell confermata su un mail server esposto equivale ad accesso dell’attaccante. Non basta cancellare il file trovato e riavviare. L’account zimbra può leggere configurazioni che contengono credenziali di LDAP, MySQL, Postfix e altri servizi. Microsoft ha inoltre osservato la raccolta di zimbraPreAuthKey e zimbraAuthTokenKey, materiale che può essere usato per ottenere sessioni senza conoscere la password del singolo utente.

La risposta dovrebbe includere:

  1. isolamento del nodo e verifica degli altri host del cluster;
  2. conservazione delle prove e ricostruzione della prima attività sospetta;
  3. rotazione delle chiavi di pre-autenticazione, dei segreti di servizio e delle credenziali amministrative rilevanti;
  4. revoca delle sessioni, controllo delle regole di inoltro e verifica degli account privilegiati;
  5. ricerca di persistenza su tutti i nodi, non solo sul primo server allertato;
  6. valutazione legale e privacy se log o prove indicano accesso a caselle o dati personali.

La rotazione va pianificata: cambiare una chiave su un solo nodo può interrompere servizi o lasciare attive relazioni di fiducia altrove. Se manca una competenza interna di incident response, è il momento di coinvolgere chi la possiede. Un contatto chiaro pubblicato in un file security.txt non risolve l’incidente, ma rende più probabile che una segnalazione esterna arrivi subito alla persona giusta.

Una checklist per PMI, fornitore IT e responsabile privacy

Il lavoro diventa più rapido se ogni ruolo sa quale prova deve produrre. Non serve una riunione di due ore per decidere da dove partire.

Amministratore o fornitore IT

  • Elenco completo dei nodi Zimbra, versioni e ruoli.
  • Esito della verifica zimbra-snmp e notifiche SNMP.
  • Data e ora esatte dell’aggiornamento alla 10.1.20 o successiva.
  • Copertura temporale dei log disponibili e degli snapshot.
  • Esito della ricerca di web shell, persistenza e connessioni anomale.

Titolare o responsabile della decisione

  • Nome della persona che può autorizzare isolamento e fermo del servizio.
  • Canale alternativo alla posta aziendale per coordinare l’incidente.
  • Elenco dei sistemi che si fidano delle credenziali o delle identità del mail server.
  • Conferma che il backup sia separato e verificabile, non solo «verde» nel pannello.

Privacy e comunicazione

  • Quali caselle e categorie di dati potrebbero essere state accessibili.
  • Quali evidenze confermano accesso, raccolta o trasferimento.
  • Chi valuta eventuali obblighi di notifica e con quali scadenze.
  • Messaggi interni preparati su un canale non dipendente da Zimbra.

La mia take è netta: per i servizi esposti, «patchato» non deve essere uno stato binario ma una coppia di prove. La prima dimostra che la versione vulnerabile non è più in esecuzione. La seconda dimostra che abbiamo cercato compromissioni nella finestra precedente. Senza la seconda, stiamo confondendo la manutenzione con l’incident response.

Chiusura operativa

Se gestisci Zimbra, oggi servono tre risultati verificabili: inventario di tutti i nodi, versione 10.1.20 o successiva e ricerca documentata delle tracce di sfruttamento. Se il pacchetto zimbra-snmp non è presente o le notifiche non sono attive, registra comunque la verifica. Se era presente su un sistema vulnerabile, conserva le prove prima di modificare tutto e considera il server da indagare, non semplicemente da aggiornare.

La finestra utile è quella dei log che possiedi davvero. Microsoft ricorda che la telemetria grezza di Advanced Hunting copre 30 giorni: per eventi più vecchi servono SIEM, archivi o backup dei log. Aspettare significa perdere contesto e trasformare una verifica tecnica in una supposizione.

Fonti