Une faille de Cross-Site Scripting (XSS) stockée dans le client web classique de Zimbra permet d'exécuter du code JavaScript arbitraire dans le navigateur d'un utilisateur Zimbra lorsqu'il ouvre un email spécialement conçu. La vulnérabilité a été découverte et signalée par le Google Threat Analysis Group (TAG), l'équipe de Google qui suit les activités des groupes de menace soutenus par des états. Elle a été corrigée dans Zimbra Collaboration Suite version 10.1.19, publiée le 8 juillet 2026. Aucun CVE n'a encore été attribué à la date de publication de cet article.
La signification de la découverte par Google TAG va au-delà du contexte technique. TAG se concentre sur les groupes de menace sponsorisés par des états et sur les outils qu'ils utilisent. Quand TAG signale une vulnérabilité dans une plateforme de messagerie d'entreprise, cela indique que la faille a retenu l'attention de groupes avec des ressources et des objectifs d'espionnage, même si TAG n'indique pas avoir observé une exploitation active de cette vulnérabilité spécifique. L'historique de Zimbra avec des groupes APT rend cette signification encore plus concrète.
Une XSS stockée (aussi appelée XSS persistante) diffère d'une XSS réfléchie en ce que le payload malveillant est stocké sur le serveur et servi à toute victime qui accède au contenu infecté, sans nécessiter que la victime clique sur un lien malveillant spécialement construit. Dans le cas de Zimbra, l'email malveillant arrive dans la boîte de réception de la victime. Quand celle-ci ouvre l'email dans le client web classique de Zimbra, le code JavaScript inclus dans l'email s'exécute dans le contexte de la session Zimbra de la victime.
Les capacités accessibles à un attaquant depuis ce point d'exécution incluent : la lecture des emails et des pièces jointes dans la boîte de réception et dans d'autres dossiers de la boîte aux lettres, la modification des paramètres du compte (changement de mot de passe de récupération, ajout d'une adresse de transfert pour exfiltration continue), le vol du token de session pour permettre un accès persistant depuis l'extérieur du réseau de la victime, et la lecture des contacts, calendriers, et autres données stockées dans Zimbra.
Le vol de token de session est l'impact le plus critique dans ce contexte. Un token de session Zimbra valide permet à l'attaquant d'accéder à la boîte aux lettres de la victime depuis n'importe quel endroit, sans connaître le mot de passe et sans que l'authentification à deux facteurs ne soit un obstacle, puisque le token représente une session déjà authentifiée. Si la durée de vie du token est longue (plusieurs heures ou jours), l'attaquant peut maintenir un accès continu à la boîte aux lettres après l'exécution initiale du payload.
Zimbra Collaboration Suite propose plusieurs interfaces client. Le client web moderne (basé sur Vue.js) et les clients de messagerie desktop (Outlook, Thunderbird via IMAP/SMTP) ne sont pas affectés par cette faille. Seul le client web classique est vulnérable.
Ce périmètre d'impact a des implications pratiques pour les organisations qui utilisent Zimbra. Si le déploiement a migré tous les utilisateurs vers le client web moderne, l'exposition est nulle. Si le client classique est encore utilisé par une partie des utilisateurs, c'est la population exposée. Certaines organisations maintiennent le client classique pour des raisons de compatibilité avec des navigateurs plus anciens, pour des utilisateurs habitués à l'interface historique, ou parce que certaines fonctionnalités spécifiques ne sont disponibles que dans le client classique.
L'identification des utilisateurs accédant à Zimbra via le client web classique peut être faite en analysant les logs du serveur Zimbra : les requêtes vers le client classique ont un chemin d'URL distinct de celles vers le client moderne. Cette analyse permet de quantifier la population exposée et de prioriser les actions de mitigation selon que zéro, quelques dizaines, ou des centaines d'utilisateurs utilisent encore le client classique.
La découverte par Google TAG d'une faille XSS dans Zimbra s'inscrit dans un contexte historique notable. Zimbra est une cible récurrente des groupes de menace avancés, et plusieurs campagnes documentées utilisent des failles XSS dans Zimbra comme vecteur d'accès initial.
Le groupe Winter Vivern, suivi pour ses liens avec des services de renseignement russes et biélorusses, a exploité en 2023 une faille XSS dans Zimbra pour compromettre des comptes d'email de gouvernements européens et d'organisations militaires. Cette exploitation a été documentée par l'équipe de recherche d'ESET, qui a identifié le groupe comme ayant utilisé un payload JavaScript transmis par email pour voler des tokens de session Zimbra dans des gouvernements membres de l'OTAN.
APT29 (Cozy Bear), attribué au SVR russe, a été associé à des campagnes ciblant des installations Zimbra dans le secteur gouvernemental et diplomatique. APT28 (Fancy Bear), attribué au GRU russe, a également été documenté comme ayant utilisé Zimbra comme vecteur dans des campagnes de collecte de renseignement. La récurrence de Zimbra dans les rapports d'activité de groupes APT reflète l'attractivité de la plateforme comme cible : elle est utilisée par des gouvernements, des militaires, et des organisations de recherche dans de nombreux pays, et une boîte aux lettres Zimbra compromise peut contenir des communications de valeur stratégique.
Cette histoire contextualise la prudence appropriée face à une faille XSS dans Zimbra découverte par TAG : même si TAG n'a pas observé d'exploitation active, les groupes qui ont historiquement ciblé Zimbra ont la motivation et la capacité de développer rapidement un exploit fonctionnel une fois qu'une vulnérabilité est connue.
La correction est disponible dans Zimbra Collaboration Suite 10.1.19. Les administrateurs Zimbra peuvent vérifier la version installée via la commande zmcontrol -v sur le serveur Zimbra. Pour les déploiements encore sur la branche 10.0.x ou antérieure, la question est de savoir si un backport du correctif sera publié ou si la mise à niveau vers 10.1.19 est la seule voie disponible. Les administrateurs qui n'ont pas reçu de communication directe de Zimbra à ce sujet devraient vérifier le portail de support ou la liste de diffusion de sécurité Zimbra.
Pour les déploiements où la mise à niveau vers 10.1.19 n'est pas immédiatement réalisable, la mitigation à court terme la plus directe est de désactiver le client web classique et de forcer les utilisateurs à migrer vers le client web moderne. Cette mitigation élimine la surface d'attaque (le client web classique) sans nécessiter une mise à jour du logiciel serveur Zimbra. L'impact opérationnel de cette migration doit être évalué selon le nombre d'utilisateurs affectés et leur dépendance aux fonctionnalités spécifiques au client classique.
La vérification dans les logs que des emails inhabituels ont été envoyés à des comptes Zimbra dans les semaines précédant la découverte de la faille est une mesure de réponse rétroactive pertinente, en particulier pour les organisations dont le profil de cible est cohérent avec les intérêts des groupes APT qui ont historiquement ciblé Zimbra. Les emails avec des pièces jointes HTML inhabituelles ou avec des corps d'email contenant des scripts JavaScript encodés sont des indicateurs à rechercher dans les logs d'inspection du contenu des emails.
La faille Zimbra illustre une catégorie de risque qui reçoit moins d'attention que les vulnérabilités de serveur ou les attaques de phishing classiques : les failles XSS dans les clients de messagerie d'entreprise. Contrairement à une XSS dans une application web publique, où les victimes doivent être attirées vers une URL malveillante, une XSS dans un client de messagerie s'exécute automatiquement quand l'utilisateur ouvre un email. L'email lui-même est le vecteur de livraison, et la livraison est quasi-garantie dès lors que l'email passe les filtres anti-spam : l'utilisateur ouvre son email dans le cadre de son travail habituel, sans qu'aucune action suspecte lui soit demandée.
Cette caractéristique rend les XSS dans les clients de messagerie particulièrement précieuses pour les groupes d'espionnage : elles permettent un accès non interactif aux boîtes aux lettres d'entreprise, sans nécessiter que la victime clique sur un lien, installe un logiciel, ou prenne toute autre action qui pourrait éveiller la méfiance. L'email arrive, la victime l'ouvre comme elle ouvre ses autres emails, et l'accès est établi.
Pour les équipes de sécurité qui gèrent des déploiements de messagerie d'entreprise, qu'il s'agisse de Zimbra, de Microsoft Exchange avec Outlook Web App, ou d'autres plateformes avec des interfaces web, la maintenance des correctifs de sécurité sur ces composants devrait être traitée avec la même urgence que les correctifs de serveurs web exposés. La surface d'attaque présentée par un client web de messagerie non patché est une surface d'attaque directement accessible depuis internet, déclenchée par une action aussi banale que l'ouverture d'un email.
Le Cross-Site Scripting comme classe de vulnérabilité est documenté depuis la fin des années 1990 et figure régulièrement dans le top 10 de l'OWASP depuis sa création. Les mécanismes de prévention sont bien connus : validation et échappement des entrées utilisateur avant insertion dans le DOM, Content Security Policy (CSP) pour restreindre l'exécution de scripts, utilisation d'APIs DOM plutôt que d'innerHTML. Pourtant, des failles XSS continues d'apparaître dans des logiciels d'entreprise matures comme Zimbra. Comprendre pourquoi aide à évaluer le risque résiduel qui persistera même après le correctif ZCS 10.1.19.
La raison principale est la complexité des emails. Un email HTML peut contenir des balises imbriquées, des attributs d'événements, des références à des ressources externes, et des constructions CSS, et la spec HTML évolue en permanence. Filtrer correctement ce contenu pour empêcher l'exécution de scripts tout en préservant la mise en forme légitime des emails est un problème difficile. Les parseurs HTML sont nombreux, et la manière dont chaque navigateur interprète le HTML malformé ou ambigu est légèrement différente. Une règle de filtrage qui bloque un payload dans Chrome peut le laisser passer dans Firefox avec une variante légèrement différente du même payload.
Le client web classique de Zimbra représente également un code legacy qui a accumulé des années de fonctionnalités et de corrections. Les bases de code anciennes tendent à avoir des surfaces d'attaque plus larges que les nouvelles implémentations parce qu'elles ont été conçues avant que les meilleures pratiques actuelles en matière de sécurité des applications web ne soient établies, et parce que leur complexité rend difficile l'audit de sécurité exhaustif. La transition des utilisateurs vers le client web moderne est donc une mesure qui réduit cette surface d'attaque structurellement, au-delà de la correction de la faille spécifique.
Pour les administrateurs Zimbra qui gèrent des déploiements où le client web classique est encore utilisé, les actions prioritaires se répartissent selon le délai de réponse possible.
Dans les 24 à 48 heures suivant la lecture de cet article, l'action prioritaire est de vérifier la version Zimbra installée avec zmcontrol -v et de déterminer si la mise à niveau vers ZCS 10.1.19 est réalisable rapidement. Si la mise à niveau est possible, elle devrait être planifiée en urgence. Si elle n'est pas réalisable à court terme, la désactivation du client web classique pour forcer les utilisateurs vers le client moderne devrait être évaluée et préparée.
Dans la semaine suivante, l'analyse des logs d'accès Zimbra pour identifier les utilisateurs qui accèdent encore au client classique donne la population exposée et permet de communiquer spécifiquement avec ces utilisateurs sur la migration vers le client moderne. Pour les organisations dont les Zimbra est un outil critique, le changement de port ou de chemin d'accès au client classique comme mesure temporaire de réduction de l'exposition est une option à évaluer si la désactivation complète n'est pas possible immédiatement.
Dans le mois suivant, la revue rétrospective des logs de filtrage des emails pour identifier des emails avec des payloads suspects reçus dans les semaines précédant la correction devrait être conduite pour les organisations dont le profil de cible est cohérent avec les groupes APT qui ont historiquement exploité Zimbra. Si des emails suspects sont identifiés, un audit des comptes qui les ont reçus pour détecter des modifications de paramètres, des règles de transfert nouvellement créées, ou des accès depuis des adresses inhabituelles est l'étape suivante. Cette investigation rétrospective est particulièrement pertinente pour les organisations gouvernementales, de défense, ou de recherche qui opèrent Zimbra et qui sont dans le périmètre d'intérêt historique des groupes comme Winter Vivern, APT29, ou APT28.
Pendant longtemps, les équipes de sécurité ont traité les clients de messagerie web comme des applications périphériques dont la sécurité était la responsabilité du fournisseur. Cette délégation de responsabilité était fonctionnelle dans un monde où les clients de messagerie web étaient principalement utilisés pour accéder à des comptes personnels. Quand les clients de messagerie web d'entreprise comme Zimbra ou Outlook Web App sont devenus les interfaces principales pour des comptes qui contiennent des communications sensibles, des données contractuelles, et des accès à des systèmes internes via des liens et des pièces jointes, la sécurité de ces clients est devenue une question de sécurité opérationnelle critique.
La faille Zimbra illustre pourquoi la maintenance de sécurité des clients de messagerie web d'entreprise doit être traitée avec la même rigueur que la maintenance des serveurs web exposés. Les deux catégories présentent une surface d'attaque directement accessible depuis internet. Les deux peuvent être compromises par une seule requête malveillante, un email spécialement conçu dans le cas de Zimbra, sans que l'utilisateur ait à effectuer d'action supplémentaire au-delà de son utilisation normale du service. Les deux ont des exploitants historiques qui attendent les opportunités de vulnérabilité non patchées.
La gouvernance de la sécurité pour les déploiements de messagerie d'entreprise devrait inclure : un abonnement aux canaux d'annonce de sécurité du fournisseur (liste de diffusion Zimbra Security Advisories), un processus de déploiement des correctifs de sécurité dans un délai défini (72 heures pour les failles critiques, une semaine pour les failles hautes), des tests réguliers de la configuration de Content Security Policy pour vérifier qu'elle restreint effectivement l'exécution de scripts non autorisés, et une revue périodique des mécanismes de filtrage de contenu email du côté serveur pour vérifier qu'ils interceptent les patterns HTML malveillants connus avant que les emails n'atteignent les boîtes de réception des utilisateurs.
Une Content Security Policy (CSP) bien configurée sur le client web Zimbra peut réduire l'impact d'une faille XSS en restreignant ce que le JavaScript exécuté dans le contexte de la page peut faire. Une politique CSP qui interdit l'exécution de scripts inline, qui restreint les connexions réseau sortantes aux domaines attendus, et qui interdit le chargement de ressources depuis des origines non autorisées ne prévient pas l'exécution du payload XSS, mais peut limiter ce que ce payload peut accomplir : une politique qui bloque les connexions vers des domaines attaquants non listés complique l'exfiltration de tokens de session vers un serveur externe.
La vérification de la politique CSP en vigueur sur le déploiement Zimbra peut être réalisée via les outils de développement du navigateur en inspectant les en-têtes HTTP de réponse du client web. Si les en-têtes CSP sont absents ou trop permissifs, leur renforcement est une mesure de sécurité complémentaire qui s'applique indépendamment du statut de correction de la faille XSS spécifique. Une politique CSP stricte protège contre toutes les failles XSS dans l'application, pas seulement contre celle qui a été identifiée et corrigée dans ZCS 10.1.19.
Pour les équipes qui administrent Zimbra, la configuration de la CSP est typiquement réalisée au niveau du serveur web (Apache ou Nginx) qui sert le client Zimbra, via des en-têtes HTTP ajoutés dans la configuration du virtual host. La documentation de Zimbra couvre la configuration de base, mais la définition d'une politique stricte nécessite une phase de test pour identifier toutes les origines légitimes dont l'application a besoin et les inclure dans la politique sans casser les fonctionnalités existantes. Ce travail, souvent différé parce qu'il nécessite un test approfondi des fonctionnalités, devient urgent dans le contexte d'une vulnérabilité XSS active découverte par une équipe de threat intelligence de Google.
Des ransomwares qui désactivent vos EDR avant de chiffrer, des agents IA manipulés pour exfiltrer vos secrets, des malwares bancaires mobiles en location sur Telegram, des failles XSS dans les messageries d'entreprise : ces menaces n'ont pas de point commun technique, mais elles partagent une caractéristique opérationnelle. Toutes exploitent un angle mort, que ce soit un driver signé non surveillé, une image PNG ignorée par les relecteurs humains, une permission Android mal accordée, ou une mise à jour Zimbra différée. Defendis surveille l'exposition externe de votre organisation, les fuites de credentials liées à votre domaine, et les signaux précurseurs d'activité malveillante dans votre secteur. Quand un groupe de menace commence à cibler des organisations comme la vôtre, vous êtes alerté avant l'impact. Découvrez comment la surveillance continue change les délais de réponse, ou demandez une présentation personnalisée pour votre organisation.
