Zimbra sous attaque zéro-clic: CVE-2025-66376 vole les identifiants et accède aux boîtes aux lettres sans interaction utilisateur

Un groupe d'espionnage soutenu par l'État russe a depuis des mois exploité une vulnérabilité inconnue dans le client web classique de Zimbra de lire des boîtes aux lettres occidentales sans avoir besoin d'interaction au-delà de la vision de la victime du message: il suffit que le courrier soit rendez-vous dans une session authentifiée pour que l'explosion soit déclenchée. Ce scénario « basé sur la vue » ou zéro clic augmente le risque opérationnel parce que le contrôle est entre les mains du contenu HTML du courriel, et non dans une action explicite de l'utilisateur.

Techniquement, la défaillance identifiée comme CVE-2025-66376 est un site cross-site stocké dans l'UI classique de Zimbra qui abuse de la gestion de@ importationdans CSS pour reconstruire un< svg onload =... >fragmentaire - une technique appelée par un certain "tag-splitting" - et ainsi exécuter JavaScript avec les permissions de la session Web affectée. La charge utile décrite par les chercheurs vole le jeton CSRF, les mots de passe que le navigateur auto-complet, les codes de récupération 2FA et utilise les API internes de Zimbra pour extraire des données de la plate-forme et de la boîte aux lettres.

L'explosion a affecté Zimbra Collaboration Server dans les versions précédentes de 10.0.18 et 10.1.13; le fabricant a publié des correctifs le 6 novembre 2025 et, plus tard, la vulnérabilité a été incluse dans le catalogue des vulnérabilités exploitées connues de la CISA. Pour les références techniques publiques sur la vulnérabilité, voir l'onglet CVE dans le NVD et dans MITRE: CVE-2025-66376 NVD feuille et CVE-2025-66376 Feuille MITRE.

Le code malveillant, identifié par certains fournisseurs comme "ZimReaper", exfiltre les données à travers des consultations DNS avec des sous-domaines longs et aléatoires, génère un fichier TGZ avec jusqu'à 90 jours de courrier et, d'une manière inquiétante, crée un mot de passe d'application appelé ZimbraWeb par Demande de Mot de passe CreateAppSpecification. Ces mots de passe permettent l'accès IMAP / POP / SMTP sans nécessiter 2FA, et survivent aux changements de mot de passe conventionnels si non explicitement révoqués.

La campagne a été observée en attaquant des organisations gouvernementales, de défense, de transport et de financement dans plusieurs régions; l'analyse publique est associée à des groupes d'acteurs nommés de manière différente (LAUNDRY BEAR, Void Blizzard, TA488, CL-STA-1114), mais l'attribution exacte n'est pas le point central pour les défenseurs : La chose critique est que l'exploitation persistante peut laisser des lettres de créances et des portes arrière qu'un simple patch ne élimine pas.

Du point de vue de la réponse et de l'atténuation, il y a deux fronts obligatoires : appliquer le patch et supposer que les comptes qui visualisent des messages malveillants peuvent être compromis. Mettre immédiatement à jour les instances touchées à au moins 10.1.13 si l'on utilise la branche 10.1 et apporter les déploiements 10.0 à une branche supportée; le patch arrête de nouvelles expéditions malveillantes, mais ne révoque pas les identifiants déjà exfiltrés.

Fonctionnellement, traiter comme potentiellement compromis toutes les boîtes aux lettres qui pendant la période de campagne ouvrent ou prévisualiser les messages dans l'UI classique. Parmi les actions essentielles: restaurer les mots de passe, invalider les sessions actives, régénérer et forcer la livraison de nouveaux codes 2FA / scratch, et révoquer tout mot de passe spécifique à l'application appelé ZimbraWeb. Rechercher dans / opt / zimbra / log / audit.log dans CreateAppSpecificPassword et dans les comptes aveczimbraPrefImapEnableddans TRUE qui n'ont aucune justification opérationnelle.

La détection et la surveillance devraient inclure des alertes DNS pour les requêtes aux domaines et sous-domaines observés dans la campagne (recherches de sous-domaines aléatoires et de longs modèles), l'audit d'appels SOAP inhabituels tels que GetScratchCodesRequest, et l'analyse HTML de messages reçus mais non ouverts: le modèle fragmenté de@ importationqui reconstitue le< svg en charge >est détectable par les règles YARA publiées par les fournisseurs.

N'oubliez pas que l'exploit profite de la confiance du navigateur dans l'auto-complété et dans les identifiants stockés : considérez des politiques temporaires qui désactivent l'auto-complété dans l'accès web aux webmails d'entreprise, restreignent l'utilisation de l'UI classique, et appliquent des contrôles de navigation tels que les proxys qui peuvent assainir ou bloquer le HTML actif dans la poste. Dans les environnements critiques, l'atténuation immédiate peut inclure temporairement désactiver l'aperçu HTML pour confirmer le nettoyage et les correctifs.

La leçon stratégique est claire : vulnérabilités de rendu de courrier sont critiques parce qu'ils transforment le client de courrier en une façade qui donne les permissions de l'utilisateur à un attaquant sans clics supplémentaires. Pour l'équipement de sécurité, il faut combiner le stationnement agile avec l'inventaire des pouvoirs, la surveillance DNS et du journal, et les procédures de récupération qui comprennent la révocation des pouvoirs persistants et la vérification des paramètres d'accès (IMAP / SMTP / POP) après le patching.

Si votre organisation utilise Zimbra, prioriser la mise à jour, exécuter les vérifications de compte décrites, et coordonner l'enquête avec votre CSIRT ou les fournisseurs de réponse. La politique de communication interne devrait avertir les utilisateurs potentiellement touchés de travailler ensemble à la rotation des pouvoirs et à l'identification des règles ou messages manquants. La défense efficace de ce type de campagne combine le patch, le nettoyage des comptes et le contrôle des canaux de courrier plutôt que de compter sur un seul remède technique.