CVE-2026-73570 : l’injection de commandes Zimbra via SNMP est exploitée — mise à jour vers 10.1.20 et vérification de compromission

Dans Zimbra Collaboration (ZCS) avant la version 10.1.20, un attaquant peut exécuter des commandes du système d’exploitation avec les droits de l’utilisateur zimbra sans authentification, si le paquet optionnel zimbra-snmp est installé et que les notifications SNMP sont activées. Une requête SMTP spécialement conçue, c’est-à-dire un e-mail adressé au serveur dont le contenu arrive sans filtrage dans le traitement des notifications SNMP, déclenche la vulnérabilité. La faille porte l’identifiant CVE-2026-73570 et obtient un score CVSS de 8.9. Zimbra l’a signalée le 26 juin 2026 et corrigée le 20 juillet 2026 avec la version 10.1.20. CERT Polska a averti le 17 août 2026 d’une campagne d’attaques en cours ; l’autorité américaine CISA a ajouté la faille à son catalogue des vulnérabilités exploitées (KEV) le 21 août 2026. La mise à jour est disponible.

L’essentiel en bref

Versions concernées et mises à jour

Seules les installations où zimbra-snmp est installé et les notifications SNMP sont activées sont concernées. Selon CERT Polska, le service swatchdog, qui traite les notifications, s’exécute par défaut. Sans zimbra-snmp, un serveur n’est pas attaquable par cette voie selon la description de l’avis ; la mise à jour vers 10.1.20 corrige également d’autres vulnérabilités (XSS dans le Classic Web Client, contournement des restrictions de transfert, SSRF dans l’intégration Nextcloud, contrôles d’accès dans EWS et pour la délégation de boîtes aux lettres) et est donc pertinente même sans SNMP.

La version installée est affichée par zmcontrol -v en tant qu’utilisateur zimbra (numéro de version, build, plateforme, date de build selon le wiki Zimbra) :

su - zimbra
zmcontrol -v

L’analyse de SecureLayer7 permet de vérifier ainsi si la configuration vulnérable est active :

su - zimbra
zmlocalconfig snmp_notify
zmswatchctl status
grep dosnmp /opt/zimbra/conf/swatchrc

Si snmp_notify est défini sur true et que swatchdog est actif, le serveur est attaquable sur une version antérieure à 10.1.20.

Ce que l’on sait de l’exploitation

Microsoft décrit le déroulement ainsi : swatchdog surveille /var/log/zimbra.log et déclenche un trap SNMP lors des changements d’état des services. Des métacaractères du shell arrivent dans ce traitement via une requête SMTP spécialement conçue ; lors d’un changement d’état, swatchdog transmet la valeur contrôlée par l’attaquant à un appel de snmptrap, qui s’exécute via un shell. Les commandes sont exécutées avec les droits du compte de service zimbra.

Chronologie selon les sources :

1. 26 juin 2026 : Zimbra signale la faille dans un avis de sécurité accompagné d’une mesure temporaire.

2. 20 juillet 2026 : ZCS 10.1.20 est publiée avec le correctif permanent.

3. Du 28 juillet au 7 août 2026 : Microsoft observe des sondages du point d’injection avec deux outils différents.

4. 13 août 2026 : L’entrée CVE est publiée.

5. 17 août 2026 : CERT Polska avertit d’une campagne en cours et publie des indications de vérification.

6. 21 août 2026 : CISA ajoute la faille au catalogue KEV, avec une échéance au 24 août 2026.

7. 30 septembre 2026 : Microsoft publie une analyse des attaques avec des indicateurs.

Selon Help Net Security, la Shadowserver Foundation comptait le 20 août 2026 155 instances Zimbra compromises sur Internet, puis 274 quelques jours plus tard. Plus de 8200 instances n’étaient pas mises à jour à ce moment-là, sans que toutes disposent de la configuration SNMP vulnérable.

Après l’exploitation, les attaquants ont, selon Microsoft, déposé des webshells JSP dans plusieurs répertoires de Jetty et mailboxd, mis en place une persistance via un service systemd, des entrées Cron et des clés SSH, et obtenu les droits root en manipulant la configuration PAM. Ils ont lu des identifiants avec zmlocalconfig -s, interrogé via LDAP les attributs zimbraPreAuthKey, zimbraAuthTokenKey et zimbraTwoFactorAuthSecret, archivé le magasin de courrier avec tar et tenté une exfiltration vers Azure Blob Storage au moyen d’AzCopy ; selon Microsoft, il n’est pas confirmé que le transfert ait été achevé. Microsoft mentionne également un mineur de cryptomonnaie. L’identité des auteurs des attaques est inconnue.

Mesures immédiates

1. Déterminer la version et la configuration avec zmcontrol -v, zmlocalconfig snmp_notify et zmswatchctl status (voir ci-dessus).

2. Vérifier une compromission et sauvegarder les journaux avant toute modification, afin de conserver la possibilité de les analyser (voir la section suivante).

3. Mettre à jour vers ZCS 10.1.20 ou une version ultérieure. Zimbra, CERT Polska, CISA et Microsoft le recommandent unanimement. Les installations sur des branches plus anciennes doivent passer à 10.1.20 ou une version ultérieure.

4. Appliquer le contournement jusqu’à la mise à jour : Microsoft recommande de désinstaller le paquet zimbra-snmp ou de désactiver les notifications SNMP. Les commandes correspondantes figurent sous cette liste.

5. Réduire l’exposition : selon Microsoft, restreindre SNMP et SMTP aux hôtes de confiance, dans la mesure où le fonctionnement du courrier le permet. Sur un MTA qui reçoit des e-mails depuis Internet, SMTP reste accessible ; dans ce cas, la mise à jour ou le contournement sont les mesures efficaces.

Pour désactiver les notifications SNMP, SecureLayer7 indique les commandes suivantes à exécuter en tant qu’utilisateur zimbra :

zmlocalconfig -e snmp_notify=false
zmswatchctl stop

Les traps SNMP sont alors absents en cas de défaillance des services ; la supervision doit être assurée par un autre moyen jusqu’à la mise à jour.

Vérification de compromission

La faille a été exploitée avant la mise à jour de nombreux systèmes. Une mise à jour vers 10.1.20 ferme le vecteur d’attaque, mais ne supprime pas les webshells, services systemd ou clés SSH déjà déposés. Microsoft recommande explicitement de rechercher les mécanismes de persistance redondants et de changer les clés d’authentification de Zimbra.

Journaux et répertoires selon CERT Polska

CERT Polska mentionne deux vérifications :

1. /var/log/zimbra.log pour y trouver des entrées de la forme Service status change: [Payload] changed from stopped to running ou changed from running to stopped, avec des chaînes suspectes à l’emplacement du nom de service.

2. Les fichiers créés par l’utilisateur zimbra au cours des 30 derniers jours, dans /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ et /tmp/. Hive Security propose à cet effet :

find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp -user zimbra -mtime -30 -ls

Les attaques ayant commencé dès la fin juillet selon Microsoft, une période plus longue que 30 jours peut être pertinente.

Autres traces selon Microsoft

Indicateurs réseau

Les adresses sont écrites sous forme neutralisée, comme dans l’analyse Microsoft.

Hashes de fichiers (SHA-256)

En cas de découverte

Toute détection signifie que le système doit être considéré comme compromis. Sauvegardez les journaux et les fichiers concernés avant de supprimer quoi que ce soit. Étant donné que les attaquants ont obtenu les droits root et mis en place une persistance à plusieurs endroits selon Microsoft, une reconstruction sur 10.1.20 ou une version ultérieure est plus sûre que la suppression de fichiers isolés. Les secrets lus doivent ensuite être remplacés : les valeurs de zmlocalconfig -s (notamment les mots de passe LDAP et de base de données), zimbraPreAuthKey, zimbraAuthTokenKey et les clés SSH de l’utilisateur zimbra. Selon Microsoft, zimbraTwoFactorAuthSecret a également été interrogé ; les inscriptions à l’authentification à deux facteurs des utilisateurs doivent donc être recréées. Dans les installations multi-serveurs, la vérification doit concerner tous les nœuds, car les attaquants ont identifié les serveurs de boîtes aux lettres et MTA avec zmprov et utilisé la clé SSH pour se déplacer entre les serveurs selon Microsoft.

Mise en contexte

Les organisations concernées sont celles qui exploitent Zimbra comme serveur de messagerie propre et acceptent directement des e-mails depuis Internet. La faille est accessible via la réception habituelle des e-mails, sans authentification ni action d’un utilisateur. La restriction à zimbra-snmp avec des notifications actives réduit le nombre de systèmes attaquables ; toutefois, les organisations ayant mis en place une supervision SNMP se trouvent précisément dans cette configuration. Selon SecurityWeek, CISA répertorie 18 vulnérabilités Zimbra dans le catalogue KEV, dont quatre datent de 2026 ; de précédentes campagnes contre Zimbra ont été attribuées à des groupes soutenus par des États et à des criminels motivés financièrement. CERT-FR a signalé la faille le 19 août 2026 avec trois autres CVE corrigées dans Zimbra. Aucun avis du NCSC Suisse sur CVE-2026-73570 n’était disponible lors des recherches.