Se amministri Zimbra Collaboration 10.1, aggiorna a Zimbra 10.1.21 prima di intervenire con workaround improvvisati. La release del 24 settembre 2026 corregge più problemi di sicurezza, tra cui vulnerabilità XSS nel Classic Web Client, controlli WebDAV legati ai token pre-MFA e un difetto nel recupero password. Le installazioni precedenti alla 10.1.21 devono essere considerate da aggiornare.
Il punto pratico è semplice: non basta proteggere l’accesso con MFA se il server resta su una build vulnerabile. La correzione è nella release 10.1.21, quindi il primo controllo è la versione effettivamente installata e il secondo è l’esito dell’upgrade su tutti i nodi del servizio.
Chi deve aggiornare Zimbra
La pagina di rilascio ufficiale indica Zimbra Daffodil 10.1.21 come versione che incorpora i fix pubblicati il 24 settembre 2026. Se il tuo ambiente è ancora su una release 10.1 precedente, pianifica l’aggiornamento secondo la procedura supportata per la tua installazione.
Quali problemi corregge Zimbra 10.1.21
- Stored XSS nel Classic Web Client legato a nomi mittente appositamente costruiti.
- Stored XSS attraverso header Content-Location di allegati malevoli.
- Controlli WebDAV più rigidi: i token pre-MFA vengono rifiutati finché l’autenticazione multifattore non è completata.
- Correzione nel meccanismo self-service di recupero password che poteva rendere prevedibili i codici di recupero.
- Aggiornamento di OpenJDK e componenti server inclusi nella release.
Tra le vulnerabilità rese pubbliche il 25 settembre compare anche CVE-2026-93647, associata a uno scenario di stored XSS nel client Classic. Il rischio non va tradotto automaticamente in compromissione: la presenza di una versione vulnerabile indica esposizione al difetto, non prova che l’ambiente sia stato attaccato.
Come verificare la versione prima dell’upgrade
- Accedi al server con un account amministrativo autorizzato.
- Annota la versione Zimbra installata e l’eventuale patch level.
- Controlla che repository e canali di aggiornamento siano quelli previsti dalla tua edizione.
- Esegui un backup verificato prima della manutenzione.
- Segui la procedura ufficiale di patching e porta l’ambiente alla 10.1.21 o a una release successiva supportata.
Cosa controllare dopo l’aggiornamento
Dopo il riavvio dei servizi, verifica che il numero di versione sia quello atteso, che webmail e autenticazione funzionino e che i nodi di un’installazione distribuita siano allineati. Se usi WebDAV o MFA, prova anche il flusso reale con un account di test: il fix modifica proprio la validazione dei token prima del completamento dell’autenticazione multifattore.
Se non puoi aggiornare subito
Non considerare la disattivazione di una singola funzione come sostituto permanente della patch. Riduci l’esposizione dell’interfaccia amministrativa, limita l’accesso ai servizi non necessari e accelera la finestra di manutenzione. Se l’istanza è esposta a Internet, conserva i log utili e controlla attività amministrative o accessi anomali prima e dopo l’upgrade.
Cosa evitare
- Non disattivare MFA pensando che risolva il problema.
- Non applicare patch destinate a rami diversi senza verificare la documentazione.
- Non cancellare log e tracce di accesso prima di aver escluso attività anomale.
- Non rimandare l’upgrade perché non hai osservato sintomi: molte vulnerabilità server non producono errori visibili agli utenti.
Collegamenti utili per il cluster sicurezza
Su Tech abbiamo già seguito un precedente aggiornamento di sicurezza di Zimbra. Per un altro esempio di software di amministrazione da aggiornare con priorità, puoi confrontare anche il caso ScreenConnect: l’obiettivo in entrambi i casi è correggere il prodotto senza confondere patch e verifica di una possibile compromissione.
La release note ufficiale di Zimbra 10.1.21 elenca i fix inclusi, mentre la pagina Zimbra Security Advisories mantiene lo storico delle vulnerabilità corrette.
Verifica finale
Considera chiuso il lavoro solo quando il server riporta 10.1.21 o una versione successiva supportata e i servizi principali superano i test dopo l’upgrade. Se l’ambiente era esposto mentre usava una build precedente, la patch riduce il rischio futuro ma non sostituisce il controllo dei log relativi al periodo precedente.
