Une injection de commandes dans le module SNMP de Zimbra s’exploite par simple e-mail et rejoint le KEV
CVE-2026-73570, une injection de commandes OS dans le composant SNMP de Zimbra Collaboration, est exploitée activement et a rejoint le catalogue KEV de CISA le 21 août 2026, avec une échéance fédérale au 24 août. Corrigez vers la 10.1.20 et traquez l’intrus dans les journaux, pas seulement le correctif.
13 août 2026. La NVD publie CVE-2026-73570, une injection de commandes système dans Zimbra Collaboration notée 8,9 en CVSS v3.1. 17 août 2026. CERT Polska signale une campagne d’exploitation active dans la nature. 21 août 2026. CISA inscrit la faille au catalogue KEV et fixe une échéance fédérale au 24 août 2026.
Pour un RSSI qui opère une messagerie Zimbra, la leçon tient en une phrase : une faille qui s’amorce par un e-mail entrant et finit en commande système exécutée sous l’utilisateur zimbra ne se traite pas comme un simple correctif — elle se traite comme une compromission probable.
Une chaîne d’injection peu banale
CVE-2026-73570 est une OS command injection (CWE-78) qui vit dans le composant de supervision SNMP de Zimbra, plus précisément dans le traitement des notifications SNMP. La description officielle est sèche mais précise : un attaquant non authentifié envoie des requêtes SMTP spécialement forgées, et obtient l’exécution de commandes système arbitraires avec les privilèges de l’utilisateur zimbra.
Le chemin d’attaque mérite qu’on s’y arrête, parce qu’il ne ressemble pas aux injections classiques. La faille ne se déclenche pas depuis l’interface web, ni depuis un endpoint d’API, mais depuis l’entrée de messagerie : un message SMTP entrant, dont certaines données transitent vers le traitement des traps SNMP, y est mal assaini, et finit interprété comme une commande. C’est une chaîne mail → supervision → shell — trois systèmes qui n’auraient jamais dû partager le même flux de confiance.
Le vecteur SMTP a une conséquence pratique immédiate : il n’y a pas de prérequis d’authentification applicative à satisfaire. L’attaquant n’a pas besoin d’un compte, d’un mot de passe ni d’une session. Il lui faut la capacité de faire parvenir un message à l’instance — ce qui, pour un serveur de messagerie, est précisément sa fonction première.
Le piège du composant « optionnel »
La fiche NVD encadre la faille d’une condition qui, lue trop vite, rassure à tort : la vulnérabilité ne se manifeste que si le paquet optionnel zimbra-snmp est installé et que les notifications SNMP sont activées. Deux conditions, donc, dont la première semble éliminer la plupart des déploiements.
C’est ici que le détail technique reprend ses droits. CERT Polska précise que la condition d’activation est le paramètre snmp_notify, et que le service qui fait le travail — swatchdog — est, lui, activé par défaut. Autrement dit, la moitié « optionnelle » de la condition porte sur un composant que des équipes installent sans y penser (la supervision SNMP est une demande d’exploitation courante), et la moitié « active par défaut » l’est sans que personne n’ait rien décidé.
La leçon est structurelle : sur un produit de messagerie exposé, une fonction de supervision SNMP n’est pas un module inoffensif. Elle devient une surface d’exécution de commandes dès qu’elle reçoit, même indirectement, des données d’origine réseau — ici, les messages SMTP. Le correctif supprime la faille, mais il ne rend pas le réflexe moins utile : n’activez pas ce qui ne sert pas.
Exploitation active et consignes de détection
L’inscription au KEV le 21 août 2026 établit l’exploitation active — c’est le critère même du catalogue. CERT Polska va plus loin en publiant, dès le 17 août, des consignes de détection précises pour les administrateurs qui veulent savoir s’ils sont déjà atteints.
La première porte sur les journaux. Le fichier /var/log/zimbra.log doit être fouillé à la recherche de lignes de la forme Service status change: <charge utile> changed from stopped to running et de sa symétrique changed from running to stopped. C’est la signature de la faille : la charge utile injectée apparaît dans le suivi d’état de service, ce qui en fait un marqueur à la fois simple et fiable.
La seconde porte sur le système de fichiers. Il faut vérifier les fichiers créés au cours des 30 derniers jours par l’utilisateur zimbra dans trois arborescences sensibles : /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ et /tmp/. Un web shell déposé dans l’une de ces arborescences survit au redémarrage du service et re-sert l’attaquant après correction.
Ces consignes ne sont pas une liste de contrôle universelle, mais un point de départ d’investigation. Une absence de marqueur ne prouve pas qu’un serveur est sain — elle dit seulement que l’indicateur le plus évident n’a pas été trouvé.
Le correctif et l’échéance
La faille est éliminée dans Zimbra 10.1.20. L’avis de sécurité Zimbra liste CVE-2026-73570 parmi les corrections de cette version, aux côtés d’autres identifiants traités dans la même publication — CVE-2026-50055, CVE-2026-10631, CVE-2026-50054, entre autres. Le remède est donc disponible, versionné et documenté : il n’y a pas d’excuse d’attente pour les branches 10.1.x antérieures.
CISA impose, via sa directive BOD 26-04, une échéance au 24 août 2026 pour les agences fédérales américaines. Trois jours entre l’inscription au KEV et la date limite : c’est une fenêtre serrée, et elle doit être lue pour ce qu’elle est — un signal d’urgence, pas un confort administratif. Une échéance fédérale courte est l’indicateur le plus honnête de la vitesse à laquelle la campagne se propage.
La version antérieure à 10.1.20 couvre toutes les branches non corrigées. Pour les déploiements qui tournent encore sur des versions plus anciennes — Zimbra a une longue histoire de failles de messagerie exploitées massivement — la montée vers 10.1.20 est la seule issue, et elle doit s’accompagner d’une chasse à la compromission, pas seulement d’une mise à jour.
Verdict
Si vous exploitez Zimbra Collaboration, corrigez immédiatement vers la 10.1.20, désactivez le module zimbra-snmp (ou le paramètre snmp_notify) s’il n’est pas indispensable, puis traitez l’investigation comme une tâche distincte de la mise à jour : fouillez /var/log/zimbra.log pour les lignes Service status change, vérifiez les trois arborescences web pour des fichiers récents créés par zimbra, et révoquez les secrets depuis une machine saine si le moindre marqueur apparaît.
Si vous n’utilisez pas Zimbra, retenez le pattern, pas le produit : un module de supervision SNMP « optionnel » activé par défaut, alimenté par des données d’origine réseau, devient une surface d’exécution de commandes. Sur tout serveur de messagerie exposé, désactivez ce qui ne sert pas, et traitez l’e-mail entrant comme ce qu’il est — une entrée non fiable, même quand il n’atterrit « que » dans un journal de supervision.
Références
- CISA — Known Exploited Vulnerabilities Catalog, CVE-2026-73570, ajouté le 21 août 2026
- NVD — CVE-2026-73570, publié le 13 août 2026
- CERT Polska — Aktywnie wykorzystywana podatność w Zimbra Collaboration Suite (145/2026), 17 août 2026
- Zimbra — Zimbra Security Advisories, consulté le 22 août 2026