Zimbra CVE-2026-73570: fonctionnement non authentifié via SMTP avec zimbra-snmp affiche les coquilles web et les données

Au cours des dernières semaines, une campagne a été enregistrée qui a profité d'un échec de sécurité dans Zimbra Collaboration Suite pour exécuter le code sans authentification, installer des shells web et, dans plusieurs cas, extraire des données des boîtes mail. La vulnérabilité identifiée comme CVE-2026-73570 (CVSS 8.9) affecte les installations avec le paquet Zimbra-snmp optionnel et les notifications SNMP activées; selon l'analyse publique, l'opération est effectuée par une requête SMTP spécialement construite sans besoin d'identification ni d'interaction utilisateur. Zimbra a publié un patch en juillet 2026 (version 10.1.20) et des organismes de sécurité - y compris Microsoft et CERT Polska - ont documenté l'activité active avant et après correction.

Techniquement, ce qui est rapporté dans les analyses est Commande OS injection non authentifiée sur le chemin qui reçoit ou traite les notifications SNMP associées au service Zimbra. Un attaquant qui peut envoyer des messages au serveur vulnérable peut conduire à l'exécution de commandes avec les privilèges du compte de service Zimbra, qui a permis de déployer des shells web JSP sur Jetty / boîte aux lettres, télécharger des binaires par wget / curl, ouvrir des shells inversés et établir des mécanismes de persistance (cron, systemd, memfd _ create, sh keys, shell boot files, etc.). Microsoft a décrit une chaîne d'attaque complète qui inclut la découverte de l'environnement (zmprov), l'escalade des privilèges en modifiant les configurations PAM / sudo, la récupération des secrets par zmlocalconfig, le mouvement latéral profitant de l'identité SSH de Zimbra et l'exfiltration au moyen d'outils tels que AzCopy au stockage en nuage.

Faits confirmés : CVE-2026-73570 existe et a été corrigé dans Zimbra 10.1.20; l'opération peut être activée via SMTP sans authentification lorsque les notifications zimbra-snmp et SNMP sont actives; les acteurs ont déployé des shells web JSP, des shells inversés et des outils d'accès à distance (par exemple Zimclient2) et collecté des identifiants et des données de boîte aux lettres dans plusieurs environnements selon la télémétrie Microsoft. Le CERT Polska et la CISA ont émis des avertissements publics et la CISA a ajouté une vulnérabilité à son catalogue de vulnérabilités exploitées connues, avec des délais d'atténuation pour les organismes fédéraux.

Informations estimées ou encore incertaines: L'attribution des intrusions n'est pas confirmée publiquement, ni l'extension totale du succès des exfiltrations dans tous les incidents (dans au moins un cas une tentative de transfert à Azure Blob avec AzCopy a été observée, mais l'achèvement de la copie n'a pas été confirmé). En outre, bien que Microsoft a décrit des techniques spécifiques observées (modification de / etc / pam.d / sudo, création de zimlog. service, utilisation de rsync entre noeuds, etc.), tous les hôtes touchés n'ont pas présenté chaque étape du flux d'attaque.

À qui ça sert ? Toute organisation qui a Zimbra exposé au trafic SMTP et avec le paquet zimbra-snmp installé et les notifications SNMP activées peuvent être compromises. En particulier, les déploiements avec des nœuds mailbox/MTA accessibles sur Internet et des configurations de clusters avec une identité SSH partagée sont plus vulnérables à l'exploration latérale et au vol de secrets de service.

Conséquences réelles observées: installation de portes arrière persistantes, escalade des privilèges de service zimbra, vol de secrets (jetons, clés de préauthentification, secrets 2FA), suppression des tables de base de données Zimbra et archivage du contenu de la boîte aux lettres. D'un point de vue opérationnel, cela peut signifier la perte de la confidentialité du courrier, l'engagement de l'identité des services et la réutilisation des titres de compétence pour faire vivre d'autres systèmes dans le même environnement de confiance.

Mesures spécifiques et immédiates à prendre par un administrateur zimbra:

(1) Emplacement ou atténuation: appliquer Zimbra 10.1.20 ou la version contenant le patch dès que possible. Si vous ne pouvez pas vous garer immédiatement, désinstaller zimbra-snmp ou désactiver les notifications SNMP et bloquer l'accès SNMP (ports 161/162) et SMTP (25) à partir de sources peu fiables grâce à des listes de contrôle d'accès ou des pare-feu. Plus d'informations sur les avis et les mises à jour sur la page de sécurité Zimbra: https: / / www.zimbra.com / sécurité /.

2) Vérifier les indicateurs et la persistance: vérifier les enregistrements et le système des signaux observés par les chercheurs. Recherchez le redémarrage inhabituel du service dans / var / log / zimbra.log, les shells web JSP sur les webapps et / tmp routes, les fichiers créés récemment avec des permis publics modifiés temporairement, les services système suspects (par exemple zimlog.service), les entrées de cron inattendues, les clés SSH dans / opt / zimbra / .ssh / autorisé _ clés et / etc / pam.d / sudo modifications. Commandes utiles (exemples):

-i'zimbra '/ var / log / zimbra.log
trouver / opt / zimbra -type f -iname '* .jsp' -mtime -30
stat / etc / pam.d / sudo

3) Rotation des secrets et confinement: prendre l'engagement des clés de service et faire pivoter les principaux secrets de Zimbra (zimbraPreAuthKey, zimbraAuthTokenKey, zimbraTwoFactorAuthSecret), changer les mots de passe des comptes de service, invalider les jetons et considérer la rotation des certificats s'il y a des signes d'exfiltration. Révocer et régénérer les références de service et restreindre l'identité SSH de / opt / zimbra / .ssh / zimbra _ identité sont des étapes critiques. Tout serveur présentant des signes d'engagement doit être isolé du réseau et conservé pour analyse médico-légale.

4) Rechercher des dispositifs d'exfiltration et de transfert de fichiers: surveiller les connexions sortantes en utilisant des outils tels que AzCopy ou des modèles inhabituels pour les services de stockage en nuage. Vérifiez la présence de fichiers archivés localement (p. ex. final.tar.gz mentionné dans la télémétrie) et les appels aux utilitaires réseau qui auraient pu transférer des données. Si vous détectez des tentatives d'ascension vers Azure Blob Storage, vérifiez les journaux et définissez des alertes pour l'URL SAS et le trafic pour bloquer les domaines. La CISA tient un catalogue des vulnérabilités exploitées qui peuvent aider à établir les priorités des actions : https: / / www.cisa.gov / knowledge-exploited-vulnerabilities-catalog.

5) Recouvrement recommandé: si vous confirmez votre engagement, planifiez la reconstruction à partir de sauvegardes propres après élimination légale complète. Ne faites pas confiance pour nettoyer simplement les binaires trouvés; les acteurs ont montré de multiples mécanismes de persistance et de mouvement latéral qui nécessitent une réimagination ou une restauration contrôlée. Documenter et conserver les éléments de preuve pour l'enquête.

Enfin, bien que cette campagne ait été documentée en détail par plusieurs équipes d'intervention, la visibilité est partielle et il peut y avoir des variantes ou des acteurs réutilisant la même défaillance. Maintenir les contrôles de détection des modes de commande anormaux dans les processus Zimbra, limiter les expositions inutiles des services administratifs et mettre à jour les politiques de surveillance pour détecter les changements dans PAM / sudo, les services système et le transfert de grands volumes de poste ou de base de données. Pour plus de contexte et d'avis de sécurité, suivez des sources officielles comme le blog de sécurité de Microsoft : https: / / www.microsoft.com / sécurité / blog / et équipements CERT locaux pour des indicateurs spécifiques.