Microsoft a confirmé le 30 septembre 2026 que des attaquants ont exploité CVE-2026-73570, une injection de commandes non authentifiée dans Zimbra Collaboration Suite, pour déposer des web shells et exfiltrer des boîtes mail entières. Si vous hébergez Zimbra, le correctif de juillet ne suffit pas : il faut vérifier maintenant que personne n’est déjà entré avant que vous ne l’appliquiez.
Ce que Microsoft a observé sur les serveurs Zimbra
La faille porte le score CVSS 8.9. Elle réside dans la gestion des notifications SNMP et n’est exploitable que si le paquet optionnel zimbra-snmp est installé et que ces notifications sont activées. Dans ce cas, une simple requête SMTP spécialement construite — autrement dit un e-mail envoyé à votre serveur — déclenche une exécution de code à distance, sans authentification et sans action de l’utilisateur.
L’équipe Microsoft Security Research décrit une chaîne d’attaque complète après l’exploitation : dépôt de web shells JSP sur plusieurs chemins applicatifs de Jetty et de mailboxd pour assurer la redondance, shells inverses, escalade de privilèges, outils d’accès distant persistants et exécution en mémoire. Les attaquants ont ensuite accédé aux messages, collecté des données d’authentification et des contenus de boîtes mail, puis créé des archives et les ont transférées hors du réseau.
Les victimes identifiées se répartissent sur plusieurs régions et plusieurs secteurs d’activité. L’attribution n’est pas établie à ce jour.
Pourquoi un correctif de juillet ne suffit pas
C’est le point qui concerne directement les PME et ETI françaises hébergeant leur messagerie. Zimbra a corrigé la faille en juillet 2026 avec la version 10.1.20. La divulgation publique, elle, n’a eu lieu que le 13 août. Entre ces deux dates, les attaquants savaient et vos équipes ne savaient pas.
La télémétrie Microsoft situe précisément l’activité observée dans cette fenêtre : du 28 juillet au 7 août 2026, deux outils de balayage distincts ont sondé le chemin d’injection pour valider l’exécution de commandes, sans livrer de charge utile. Les compromissions effectives ont suivi. Autrement dit : un serveur mis à jour en août ou en septembre a pu être compromis en juillet, et le correctif n’a rien retiré de ce qui avait déjà été déposé.
Le CERT polonais avait déjà alerté sur cette exploitation en août 2026, en recommandant de relire /var/log/zimbra.log à la recherche de redémarrages suspects de services Zimbra et d’inspecter les fichiers créés dans les répertoires temporaires et webapps. La CISA a inscrit la faille à son catalogue KEV le même mois, avec une échéance de correction fixée au 24 août pour les agences fédérales américaines. Un web shell JSP, lui, survit à une mise à jour : il reste un fichier dans un répertoire applicatif que personne ne relit.
Que faire maintenant
- Vérifiez si le paquet
zimbra-snmpest installé et si les notifications SNMP sont activées. Si la réponse est non sur les deux points, votre serveur n’était pas exploitable par ce vecteur et vous pouvez vous arrêter là. - Appliquez la version 10.1.20 ou supérieure si ce n’est pas déjà fait, et notez la date exacte à laquelle vous l’avez appliquée : c’est elle qui détermine votre fenêtre d’exposition.
- Recherchez les fichiers
.jspnon attendus dans les répertoireswebappsde Jetty et de mailboxd, et relisez/var/log/zimbra.logsur juillet et août à la recherche de redémarrages de services inexpliqués. - Révoquez les secrets d’authentification du serveur et forcez la réinitialisation des mots de passe des comptes hébergés si vous avez été exposé : les données d’authentification faisaient partie du butin.
- Restreignez l’exposition de votre serveur en plaçant l’interface d’administration derrière un VPN et en limitant SNMP au réseau d’administration.
Une compromission qui commence par un e-mail et se termine par une archive exfiltrée trois semaines plus tard ne se détecte pas à la main : elle se repère dans les journaux, en continu. C’est exactement le rôle d’un SOC managé 24/7 pour PME et ETI.
Le schéma n’est pas propre à Zimbra. Nous l’avions décrit à l’identique sur un autre serveur de messagerie avec le zero-day Exchange CVE-2026-42897, et la méthode pour construire la détection correspondante est détaillée dans notre tutoriel de pipeline de détection avec Wazuh.
Ce qu’il faut retenir
- CVE-2026-73570 n’est exploitable que si
zimbra-snmpest installé et les notifications SNMP activées : commencez par cette vérification. - Le correctif existe depuis juillet 2026 (version 10.1.20), mais la divulgation publique date du 13 août : la fenêtre d’exposition a précédé votre information.
- L’exploitation observée visait les données : web shells JSP redondants, accès aux messages, collecte de secrets d’authentification, exfiltration par archives.
- Mettre à jour ne supprime pas une persistance déjà en place : il faut chercher les fichiers déposés et relire les journaux de juillet et août.