Zimbra attaqué sans authentification : le correctif 10.1.20 devient urgent

Le 21 août 2026, l’exploitation active de CVE-2026-73570 contre Zimbra Collaboration Suite a été confirmée. La Cyber Security Agency of Singapore indique qu’un attaquant non authentifié peut exécuter des commandes à distance lorsque le paquet facultatif zimbra-snmp est installé et que les notifications SNMP sont activées. Elle attribue à la faille un score CVSS 3.1 de 8,9 sur 10.

À cette date, le seuil à retenir est clair : les versions antérieures à 10.1.20 réunissant ces conditions de configuration sont vulnérables, tandis que 10.1.20 apporte la correction permanente. L’urgence ne vient donc pas de la seule présence de SNMP, mais de la combinaison entre une ancienne version, le composant zimbra-snmp, les notifications actives et la possibilité pour des requêtes SMTP non fiables d’atteindre le serveur.

Pourquoi l’attaque ne demande aucun compte Zimbra

CVE-2026-73570 est une injection de commandes dans le traitement des notifications SNMP. Des données insuffisamment neutralisées, transmises au moyen de requêtes SMTP spécialement construites, peuvent être interprétées par le système d’exploitation. Les commandes résultantes s’exécutent avec les droits de l’utilisateur de service Zimbra, sans mot de passe ni session préexistante.

Cette précision distingue la faille des vulnérabilités qui exigent un compte compromis ou une action dans le client web. Le score élevé reflète notamment l’absence de privilèges requis et les conséquences possibles : contrôle du serveur ciblé, persistance, accès aux comptes de messagerie, collecte d’identifiants et mouvements latéraux vers d’autres systèmes.

Tous les serveurs Zimbra ne présentent toutefois pas la même surface d’attaque. La description publiée vise ZCS avant 10.1.20 lorsque zimbra-snmp est installé et les notifications SNMP sont activées. L’accessibilité du flux SMTP depuis une source non fiable détermine ensuite l’exposition pratique ; elle doit être examinée séparément de la seule présence du paquet.

Trois vérifications déterminent la priorité

L’inventaire doit être réalisé nœud par nœud : version de Zimbra, installation de zimbra-snmp et état des notifications SNMP. Une console d’administration à jour ne prouve pas que les relais, nœuds secondaires ou serveurs moins visibles ont tous reçu le même correctif.

1. Version antérieure à 10.1.20, paquet installé et notifications actives : le serveur correspond aux conditions publiées pour CVE-2026-73570. La mise à jour est urgente et la recherche d’une compromission antérieure doit commencer en parallèle.
2. Version antérieure à 10.1.20, mais paquet absent ou notifications inactives : la configuration ne réunit pas les conditions décrites pour cette chaîne précise. Cela ne rend pas la version ancienne sûre face aux autres vulnérabilités corrigées par la même mise à jour.
3. Version 10.1.20 : la correction permanente de CVE-2026-73570 est présente. Il reste à confirmer cette version sur chaque nœud et à rechercher des traces si le serveur a été vulnérable avant son actualisation.

Si le déploiement du correctif doit être brièvement différé, désactiver les notifications SNMP retire l’une des conditions nécessaires à cette voie d’exploitation. Il s’agit d’une mesure de réduction temporaire du risque, susceptible d’affecter la supervision, et non d’un remplacement de la mise à jour. Son application et son effet doivent être vérifiés sur chaque serveur concerné.

La version 10.1.20 est le correctif permanent

Zimbra a publié la version 10.1.20 le 20 juillet 2026. Dans son annonce de la version 10.1.20, l’éditeur présente une correction permanente de l’injection de commandes dans le composant de supervision lorsque les notifications SNMP sont activées. La version corrige aussi plusieurs problèmes distincts, dont des failles XSS, un contournement de restrictions de transfert, un défaut d’autorisation et une SSRF dans l’intégration Nextcloud.

Ces correctifs ne doivent pas être confondus avec CVE-2026-73570. La vulnérabilité traitée ici est la faille préauthentification du composant SNMP ; les autres défauts ont leurs propres prérequis et effets. La configuration SNMP sert donc à évaluer l’exposition à cette CVE, tandis que le passage à 10.1.20 traite l’ensemble de la livraison de sécurité.

Installer 10.1.20 ferme la vulnérabilité, mais ne supprime ni les fichiers ni les commandes qu’un attaquant aurait pu créer auparavant. Sur un serveur précédemment exposé, la fin de la mise à jour marque donc le début d’un contrôle rétrospectif, pas la preuve automatique que l’hôte n’a jamais été compromis.

Quels indices rechercher après la mise à jour

Les contrôles doivent d’abord viser les traces propres à la campagne observée. Le CERT Polska recommande d’examiner /var/log/zimbra.log et les fichiers créés par l’utilisateur zimbra pendant les 30 derniers jours dans plusieurs répertoires sensibles.

• Dans /var/log/zimbra.log, rechercher les événements « Service status change » contenant une charge inattendue et signalant un passage de stopped à running, ou l’inverse.
• Contrôler les fichiers créés par l’utilisateur zimbra dans /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ et /tmp/.
• Conserver la chronologie, les journaux et les fichiers suspects avant toute suppression afin de ne pas détruire des éléments utiles à l’analyse.

Un résultat suspect change la nature de l’intervention : il ne s’agit plus seulement de gestion de correctif, mais de réponse à incident. L’enquête doit alors déterminer quelles commandes ont été exécutées, quels comptes ou messages ont pu être consultés, quelles connexions sortantes ont été établies et si d’autres systèmes ont été atteints. À l’inverse, l’absence de ces indicateurs connus ne démontre pas à elle seule l’absence de compromission.

Ce qui est confirmé et ce qui reste inconnu

Le statut opérationnel est désormais établi : CVE-2026-73570 est exploitée activement, les conditions techniques d’exposition sont identifiables et Zimbra 10.1.20 contient le correctif permanent. Aucun nombre consolidé de serveurs compromis n’est toutefois fourni par les avis retenus, et la simple présence d’un serveur Zimbra accessible en ligne ne permet pas de savoir si zimbra-snmp et ses notifications y sont actifs.

La priorité consiste donc à séparer trois décisions : installer 10.1.20 sur toute branche antérieure, désactiver temporairement les notifications SNMP uniquement si la mise à jour ne peut pas être immédiate, puis rechercher une activité antérieure sur les installations qui ont réuni les conditions vulnérables. Cette distinction évite de confondre réduction provisoire de l’exposition, correction définitive et vérification d’une compromission déjà survenue.

À lire aussi:

• Chez Meta, l’heure gagnée par l’IA devient une heure de travail en plus
• PACT veut distinguer humains et robots sans compte ni CAPTCHA
• Homebrew 6 : faire confiance à une formule sans ouvrir tout le dépôt