Zimbra CVE-2026-73570 exploitée avant sa divulgation

Selon Microsoft, des attaquants ont commencé à exploiter une faille d'injection de commandes de gravité élevée dans Zimbra Collaboration Suite (ZCS) dans les semaines qui ont suivi la publication d'un correctif, mais avant que la vulnérabilité ne soit rendue publique.

La vulnérabilité, référencée CVE-2026-73570, affiche un score CVSS de 8,9. Elle touche les versions de ZCS antérieures à la 10.1.20 et permet à des attaquants non authentifiés d'exécuter du code à distance sur les serveurs de messagerie vulnérables.

Comment fonctionne la faille

Le problème se situe dans la façon dont ZCS gère les notifications SNMP. Le SNMP (Simple Network Management Protocol) sert couramment à surveiller et administrer des équipements et des services réseau. Dans les versions concernées, des données non fiables traitées lors de ces notifications ne sont pas correctement filtrées, ce qui ouvre la voie à une injection de commandes système.

L'exploitation suppose deux conditions : le paquet optionnel zimbra-snmp doit être installé et les notifications SNMP doivent être activées. Si c'est le cas, un attaquant peut déclencher la faille en envoyant des requêtes SMTP spécialement conçues, SMTP étant le protocole qu'utilisent les serveurs de messagerie pour envoyer et recevoir les e-mails.

Une attaque réussie permet à l'intrus d'exécuter du code avec les privilèges de l'utilisateur Zimbra, sans avoir besoin de s'authentifier au préalable.

Un décalage entre correctif et divulgation

Zimbra a publié le correctif le 20 juillet dans ZCS 10.1.20. La divulgation publique a suivi le 13 août. Le 17 août, CERT Polska, l'équipe nationale polonaise de réponse aux urgences informatiques, a averti que la faille était exploitée et a publié des indicateurs de compromission (IoC).

Les constatations de Microsoft montrent que les attaques ont commencé plus tôt.

"Entre le 28 juillet et le 7 août, après la mise à disposition d'un correctif le 20 juillet mais avant la divulgation publique du 13 août, Microsoft a observé deux outils de scan distincts, hors des canaux habituels, sondant le point d'injection vulnérable", a indiqué l'entreprise.

Cette reconnaissance précoce n'a livré aucune charge malveillante. Il s'agissait plutôt de tests légers destinés à vérifier que des commandes pouvaient être exécutées via le chemin vulnérable. Ce même chemin d'exécution a ensuite servi lors de l'exploitation proprement dite.

Des webshells jusqu'aux droits root

Lors des attaques qui ont suivi, les intrus ont déposé des webshells JSP dans des répertoires d'applications accessibles publiquement. Ils ont également téléchargé et exécuté du contenu avec wget ou curl, lancé des processus en arrière-plan et mis en place des reverse shells interactifs.

"Plusieurs webshells JSP ont été déployés dans les chemins applicatifs de Jetty et de mailboxd, avec des copies supplémentaires sur des nœuds de messagerie voisins. Cela offrait des voies d'accès alternatives selon les différentes configurations de Zimbra et réduisait la dépendance à un seul webshell", a expliqué Microsoft.

Une fois dans la place, les attaquants ont :

• cartographié les clusters Zimbra et relevé les caractéristiques de l'environnement
• vérifié la présence de l'identité SSH de Zimbra
• élevé leurs privilèges jusqu'à root à l'aide d'outils Zimbra légitimes
• installé un second mécanisme de persistance sous la forme d'un service systemd baptisé zimlog.service

Les attaquants cherchaient aussi des identifiants. Selon Microsoft, ils ont visé les secrets centralisés de service et d'authentification de Zimbra, puis se sont servis des informations de connexion dérobées pour lancer des requêtes LDAP authentifiées qui leur ont renvoyé des secrets de grande valeur.

L'identité SSH propre à Zimbra a été utilisée pour rebondir vers d'autres nœuds du cluster. Des rappels HTTP et HTTPS ont confirmé l'exécution des commandes, et les attaquants ont fini par déployer "un agent d'accès à distance complet offrant un shell interactif, des opérations sur les fichiers dans les deux sens et un proxy SOCKS5".

Ce que doivent faire les administrateurs

Il est conseillé aux organisations qui utilisent ZCS de :

• passer à la version 10.1.20 ou ultérieure
• désinstaller le paquet optionnel zimbra-snmp s'il n'est pas nécessaire
• désactiver la configuration vulnérable des notifications SNMP
• restreindre l'accès au SNMP et au SMTP
• rechercher des signes de compromission dans leurs environnements

L'exploitation ayant commencé avant la divulgation, appliquer le correctif ne suffit peut-être pas. Les serveurs exposés entre fin juillet et la date d'installation de la mise à jour doivent être examinés à la recherche de webshells dans les chemins Jetty et mailboxd, de services systemd inattendus comme zimlog.service et d'une utilisation inhabituelle de l'identité SSH de Zimbra entre les nœuds du cluster.

Notre analyse

Le point le plus marquant de cette affaire, c'est la chronologie. Les attaquants sondaient le code vulnérable environ une semaine après la sortie du correctif, et bien avant le moindre bulletin public. Cela laisse penser que quelqu'un a étudié le correctif de près, une pratique souvent appelée "patch diffing", et a retrouvé la faille à partir des modifications. Pour les défenseurs, c'est un rappel qu'une publication discrète ne fait pas gagner beaucoup de temps. Le délai entre un correctif et son exploitation semble se réduire, une tendance qui s'inscrit dans la hausse plus générale des divulgations de vulnérabilités et de la rapidité d'exploitation que nous suivons.

Les webmails et plateformes collaboratives auto-hébergés restent des cibles de choix. Ils sont exposés sur Internet, traitent des communications sensibles et stockent des identifiants qui peuvent ouvrir une bien plus grande partie du réseau. L'activité post-exploitation observée ici, des requêtes LDAP aux déplacements latéraux via SSH, montre que les attaquants visaient bien plus qu'une simple boîte mail. Cela rappelle les récentes attaques par injection SQL contre Roundcube, un autre cas de logiciel de messagerie entraîné dans des campagnes actives.

Microsoft n'a attribué cette activité à aucun groupe précis, et on ignore combien d'organisations ont été touchées. Il faudra voir si CERT Polska ou d'autres équipes nationales partagent davantage de données sur les victimes, et si les IoC relient cette campagne à des acteurs connus. En attendant, les administrateurs devraient considérer tout serveur Zimbra non corrigé fin juillet comme potentiellement compromis jusqu'à preuve du contraire, et se demander si des composants optionnels comme zimbra-snmp ont vraiment besoin d'être installés.