Falla critica in Zimbra: anche dopo la patch gli hacker restano dentro la posta aziendale

Cosa cambia con la CVE-2026-73570

La CVE-2026-73570 è una vulnerabilità di command injection non autenticata, con punteggio di gravità 8,9 su 10, nel modulo SNMP di Zimbra Collaboration Suite. Si attiva quando sul server è installato il pacchetto opzionale zimbra-snmp e sono abilitate le notifiche SNMP, condizione presente di default su molte installazioni che usano questa funzione di monitoraggio. Un attaccante invia una richiesta SMTP appositamente costruita che inserisce caratteri speciali nel flusso di notifica: il servizio interno che gestisce gli allarmi li passa, senza controlli sufficienti, a un comando di sistema che li esegue con i privilegi dell'account con cui gira Zimbra. Niente password, nessuna interazione da parte dell'utente.

La correzione è disponibile dal 20 luglio 2026 nella versione 10.1.20, ma la vulnerabilità è stata resa pubblica solo il 13 agosto e, secondo Microsoft, era già sfruttata in rete tra fine luglio e i primi di agosto, prima ancora della divulgazione ufficiale. Il 21 agosto CISA l'ha inserita nel proprio catalogo delle vulnerabilità sfruttate attivamente e lo scanner indipendente Shadowserver ha censito oltre 270 server compromessi nel giro di pochi giorni. In Italia Zimbra è una soluzione molto diffusa tra pubbliche amministrazioni, studi professionali e piccole e medie imprese che la scelgono, spesso tramite un fornitore di hosting o un gestore di servizi IT, come alternativa più economica a Microsoft 365: non è raro che il titolare di un'azienda non sappia nemmeno che la propria casella di posta gira su questo sistema.

Perché una patch non chiude il problema

Il rapporto Microsoft del 30 settembre spiega perché questo caso vada oltre la normale corsa tra scoperta della falla e aggiornamento del software. Sui server compromessi prima della patch, gli attaccanti non si sono limitati a eseguire comandi: hanno usato l'accesso ottenuto per sottrarre, tramite interrogazioni LDAP, alcuni segreti di altissimo valore, tra cui la zimbraAuthTokenKey, cioè la chiave con cui l'intera piattaforma firma i token di sessione di tutti gli utenti. A questa si aggiungono la zimbraPreAuthKey, che permette di costruire link di accesso pre-autenticato a qualunque casella, e la zimbraTwoFactorAuthSecret, che rende inutile anche la verifica a due fattori. Microsoft ha osservato inoltre il furto di credenziali di servizio per LDAP, MySQL, Postfix e Amavis, oltre a contenuti completi di mailbox e backup e a certificati SSL con le relative chiavi private.

Il punto cruciale per chi gestisce un'azienda è questo: queste chiavi non scadono quando un utente cambia la propria password, e la patch alla versione 10.1.20 chiude soltanto il canale con cui l'attaccante è entrato, non invalida automaticamente i segreti già sottratti in precedenza. Un server aggiornato può quindi restare pienamente accessibile a chi possiede la zimbraAuthTokenKey, che può continuare a generare sessioni valide per qualunque casella come se avesse la password di ogni utente. In pratica, se l'azienda (o il suo fornitore) si è limitata ad applicare l'aggiornamento senza verificare se c'era già stata una compromissione, può considerarsi al sicuro solo sulla carta.

Cosa controllare subito sul proprio server Zimbra

Chi gestisce direttamente un server Zimbra, o riceve questo servizio da un fornitore esterno, dovrebbe far verificare quattro punti:

• Versione installata: deve essere la 10.1.20 o successiva. Se è precedente, va aggiornata subito; se l'aggiornamento non è immediatamente possibile, occorre disinstallare il pacchetto zimbra-snmp o disattivare le notifiche SNMP e limitare l'accesso SNMP e SMTP ai soli host fidati.
• Presenza di webshell: Microsoft ha rilevato file JSP non previsti, tra cui varianti note come Chopper e GodzillaWebShell, nelle cartelle dell'applicazione web (i percorsi che contengono jetty_base/webapps, jetty/webapps, mailboxd/webapps) e nelle directory di lavoro interne, a volte copiati anche sui nodi secondari che gestiscono altre caselle.
• Permessi e configurazioni di sistema modificati: directory pubbliche con permessi alzati temporaneamente e unità di avvio automatico (systemd) con proprietario o data di modifica anomali, segno di meccanismi di persistenza installati dall'attaccante.
• Log di accesso: sessioni aperte tramite link di pre-autenticazione, accessi da indirizzi IP o orari insoliti, caselle risultate attive senza un login tracciabile con password.

Si tratta di verifiche che richiedono competenze di analisi dei log e di forensics sui file di sistema che un piccolo ufficio IT interno raramente ha a disposizione: è un controllo che Hi-Keep può eseguire direttamente sui server Zimbra dei propri clienti, sia gestiti internamente sia affidati a un hosting provider terzo.

Le domande da fare al proprio fornitore IT

Molte PMI italiane non amministrano Zimbra direttamente, ma lo ricevono come servizio da un hosting provider o da un gestore IT. In questo caso la cosa più utile da fare subito è porre domande precise, perché una risposta generica del tipo abbiamo aggiornato tutto non è sufficiente dopo un incidente di questo tipo:

• Quale versione di Zimbra Collaboration è installata sui nostri server, ed è già la 10.1.20 o successiva?
• Il modulo zimbra-snmp era installato e attivo prima della patch?
• Dopo l'aggiornamento, le chiavi zimbraAuthTokenKey e zimbraPreAuthKey sono state rigenerate, o sono ancora quelle in uso prima dell'incidente?
• È stata effettuata una ricerca di webshell e di accessi anomali nei log del periodo precedente alla patch?
• Le sessioni già aperte sono state invalidate dopo la rotazione delle chiavi?

Se il proprio fornitore non sa rispondere con precisione a queste domande, è il momento di farsi affiancare da un consulente che sappia valutare la risposta tecnica: Hi-Keep offre questo tipo di verifica indipendente anche quando la posta aziendale resta in gestione a un hosting provider esterno, senza che sia necessario cambiare fornitore.

La lezione per ogni PMI: patching e rotazione sono due cose diverse

Il caso Zimbra insegna una distinzione che vale per qualsiasi sistema aziendale esposto a Internet, non solo per la posta elettronica: installare gli aggiornamenti di sicurezza (patch management) e sostituire le credenziali dopo un sospetto di compromissione (rotazione) sono due processi distinti, e serve farli entrambi. Il primo chiude la porta da cui è entrato l'attaccante; il secondo toglie valore a tutto ciò che l'attaccante potrebbe aver già portato via prima che la porta venisse chiusa. Un piano di incident response che si ferma al primo punto lascia intatta una delle vie di accesso più efficaci, perché non richiede di scoprire o indovinare una password: basta avere la chiave giusta.

Per una PMI, questo significa due cose pratiche: avere un processo che tenga traccia delle versioni software in uso su tutti i sistemi esposti su Internet (non solo la posta, anche VPN, pannelli di amministrazione e gateway), e avere una procedura, anche minima, da attivare dopo un incidente sospetto, che preveda sempre la rotazione di chiavi, password e certificati potenzialmente esposti. Hi-Keep segue proprio questi due aspetti per i clienti che le affidano la gestione della cybersecurity: il monitoraggio costante degli aggiornamenti disponibili sui sistemi critici e un piano di risposta agli incidenti che non si considera concluso con la sola installazione della patch.

Il supporto di Hi-Keep

Se la vostra azienda usa Zimbra, direttamente o tramite un fornitore di hosting, Hi-Keep può verificare la versione installata e la presenza di webshell o accessi anomali nei log, gestire la rotazione delle chiavi di autenticazione e impostare, in modo strutturato, un processo di patch management collegato a un piano di incident response, così che un aggiornamento di sicurezza non resti l'unica misura adottata dopo un attacco di questo tipo.