Zimbra CVE-2026-73570: falla SNMP sfruttata prima dell’avviso

Una vulnerabilità di Zimbra Collaboration Suite (ZCS), CVE-2026-73570, è stata sfruttata prima di essere resa pubblica. Permette a un attaccante non autenticato di eseguire comandi del sistema operativo inviando contenuto costruito ad arte al servizio SMTP del server di posta. Microsoft Threat Intelligence ha descritto le intrusioni che ne sono seguite: web shell, escalation dei privilegi, raccolta di credenziali e archivi delle caselle pronti per essere portati fuori. La correzione esiste dalla versione 10.1.20.

Cosa è successo

Zimbra ha pubblicato la versione 10.1.20 il 20 luglio, ma la vulnerabilità è stata divulgata solo il 13 agosto. Nel frattempo, tra il 28 luglio e il 7 agosto, Microsoft ha osservato due diversi strumenti di scansione che sondavano su Internet proprio il componente poi usato negli attacchi.

Gli attaccanti hanno prima verificato che l’exploit funzionasse: facevano contattare ai server vulnerabili un’infrastruttura sotto il loro controllo, con richieste HTTP e DNS, ping ICMP e altre verifiche fuori banda. Così confermavano l’esecuzione dei comandi senza ancora compromettere il server. Poi sono passati all’installazione dei payload.

Secondo Microsoft, l’attività ha colpito organizzazioni di più regioni e settori, con una parte automatizzata e una parte condotta a mano sui server compromessi. Gli attacchi non sono stati attribuiti a un gruppo preciso.

Shadowserver, riporta Ars Technica, ha contato 274 istanze di ZCS compromesse. I server Zimbra visibili su Internet erano circa 19.000 nella settimana successiva alla patch e circa 10.000 a fine settembre.

Dettagli tecnici

• CVE: CVE-2026-73570, command injection senza autenticazione. Il CERTuy (Uruguay) indica un punteggio CVSS di 8.9, mentre Ars Technica e The Register la definiscono critica.
• Versioni colpite: Zimbra Collaboration Suite precedenti a 10.1.20.
• Condizioni necessarie: deve essere installato il pacchetto opzionale zimbra-snmp e devono essere attive le notifiche SNMP. Il CERTuy precisa: parametro snmp_notify attivo e servizio swatchdog in esecuzione.
• Vettore: rete, via SMTP. Il contenuto della richiesta arriva all’elaborazione delle notifiche SNMP senza essere ripulito, e i comandi shell inseriti vengono eseguiti con i privilegi dell’account di servizio zimbra.
• Privilegi iniziali: quelli dell’utente zimbra, non root. Bastano però per leggere configurazioni, dati e caselle della piattaforma.

La catena d’attacco osservata

Microsoft, nella ricostruzione riportata da The Register e Ars Technica, descrive queste fasi:

1. Ricognizione e verifica: scansioni e callback fuori banda per confermare l’esecuzione dei comandi.
2. Accesso e persistenza: web shell JSP, reverse shell, strumenti di accesso remoto persistente ed esecuzione in memoria. In alcuni casi i permessi delle cartelle pubbliche sono stati cambiati per depositare le web shell e poi rimessi com’erano, per rendere l’intrusione meno visibile.
3. Escalation: su almeno una macchina gli attaccanti hanno ottenuto root e si sono configurati la possibilità di eseguire comandi con i massimi privilegi senza password.
4. Movimento laterale: hanno cercato altri server di posta e sfruttato le relazioni SSH di fiducia già esistenti tra i sistemi Zimbra.
5. Raccolta: credenziali e segreti di autenticazione di Zimbra. Uno strumento era scritto apposta per estrarre le credenziali dell’account di servizio e le informazioni delle caselle dai database di Zimbra.
6. Esfiltrazione tentata: i backup recenti delle caselle sono stati compressi in un archivio e inviati verso Azure Blob Storage con AzCopy. Microsoft non ha potuto confermare che il trasferimento sia riuscito.

Il CERTuy aggiunge che, secondo i rapporti analizzati, su alcuni server compromessi è comparso anche software di cryptomining. Avverte di non fermare l’indagine al miner, perché potrebbero esserci altri meccanismi di persistenza.

MITRE ATT&CK (nostra mappatura dei comportamenti descritti): T1595 Active Scanning, T1190 Exploit Public-Facing Application, T1059.004 Unix Shell, T1505.003 Web Shell, T1222.002 Linux File and Directory Permissions Modification, T1021.004 SSH, T1114.001 Local Email Collection, T1560 Archive Collected Data, T1567.002 Exfiltration to Cloud Storage, T1496 Resource Hijacking.

Impatto per le aziende europee e italiane

Il server di posta conserva comunicazioni, allegati e credenziali. Chi lo controlla può leggere la corrispondenza, rubare identità e preparare attacchi successivi dall’interno. L’aggiornamento chiude la falla ma non rimuove web shell, chiavi SSH o altre persistenze installate prima. Va quindi controllato ogni server rimasto esposto e vulnerabile dopo il 28 luglio.

Per i soggetti NIS2, la compromissione della posta può essere un incidente significativo da notificare allo CSIRT Italia dell’ACN. Se le caselle contengono dati personali, e quasi sempre è così, va valutata anche la notifica di violazione al Garante privacy secondo il GDPR. Nella sanità, dove le email possono contenere dati sanitari, l’accesso alle caselle e ai loro backup pesa di più.

Cosa fare subito

1. Inventario: trova tutte le installazioni di Zimbra, comprese quelle gestite da fornitori, e verificane la versione.
2. Aggiorna a Zimbra Collaboration 10.1.20 o successiva. Le versioni fuori supporto vanno migrate a un ramo supportato.
3. Se non puoi aggiornare subito: disattiva le notifiche SNMP (snmp_notify) o rimuovi il pacchetto zimbra-snmp, se non ti servono. Valuta di togliere dall’esposizione i server che non puoi né aggiornare né mitigare. Sono misure temporanee.
4. Controlla la configurazione: presenza di zimbra-snmp, valore di snmp_notify, stato di swatchdog, e da quando il server era esposto in condizioni vulnerabili.
5. Cerca segni di sfruttamento, come indica il CERTuy:
   • in /var/log/zimbra.log, righe Service status change: … changed from stopped to running (o from running to stopped) con comandi, caratteri speciali o sostituzioni di shell;
   • file creati o modificati dall’utente zimbra in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /tmp/, /var/tmp/ e /dev/shm/;
   • processi dell’utente zimbra con consumo anomalo di CPU, uso di curl o wget, processi avviati da cartelle temporanee;
   • attività pianificate, servizi, script di avvio e chiavi SSH nuovi o modificati, compresi i permessi sudo;
   • connessioni in uscita insolite, verso pool di mining o servizi di storage cloud come Azure Blob;
   • accessi non riconosciuti alle caselle e agli account amministrativi.
6. Se trovi indizi: conserva log ed evidenze prima di cancellare file o fermare processi, isola il server e gestiscilo come incidente. Ruota le credenziali dell’account di servizio e degli utenti, e controlla i server raggiungibili via SSH da quello compromesso. L’assenza di righe sospette nei log non basta a escludere lo sfruttamento, soprattutto se i log sono stati ruotati.

Come aiuta ARXDOME

ARX Expose mostra quali servizi la tua azienda espone su Internet, quali prodotti vi sono riconosciuti e quali hanno vulnerabilità note: un server Zimbra raggiungibile e non aggiornato emerge tra i rilievi. Sui server Linux, l’agent di ARX Sentry raccoglie log, processi, porte e le modifiche ai file nelle cartelle stabilite, come quelle delle applicazioni web di Zimbra. ARX Shield elenca le vulnerabilità aperte per macchina e per pacchetto e permette di isolare dalla rete una macchina sospetta. Con ARX Trace gli analisti possono avviare raccolte e ricerche su più server.

Ultimo aggiornamento: 9 ottobre 2026