CVE-2026-73570 : comment la notification SNMP de Zimbra a permis une injection de commandes

CVE-2026-73570 est une faille d’injection de commandes sans authentification dans le chemin optionnel des notifications SNMP de Zimbra. Un courriel spécialement conçu pouvait influencer une valeur d’état ensuite interpolée dans une commande shell ; Zimbra a corrigé l’appel en version 10.1.20. Microsoft a ensuite signalé des outils de scan qui sondent le chemin vulnérable avant la divulgation publique.^{[1], [2], [5]}

Vecteur CVSS

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L^{[5], [10]}

💡 Explication en Langage Simple (ELI5)

Un agent du courrier copie l’étiquette d’une enveloppe dans un ordre de travail. L’ancien procédé transmettait l’ordre entier à un interpréteur de commandes, qui pouvait prendre les caractères de l’étiquette pour de nouvelles instructions. Le correctif transmet au programme de notification une liste d’arguments distincts : l’étiquette reste une donnée.^{[8], [9], [3]}

Concepts Clés et Termes

swatchdog: Processus de surveillance des journaux utilisé ici par Zimbra pour repérer les messages d’état et déclencher des notifications.^[1]
Trap SNMP: Notification envoyée par un système administré à un récepteur de supervision SNMP lorsqu’un événement survient.^[1]
Interpolation shell: Construction d’une commande textuelle analysée par le shell. Des caractères issus de valeurs non fiables peuvent alors modifier son interprétation.^{[8], [7]}
system en forme de liste: La forme multi-arguments de system en Perl lance directement le programme et transmet chaque argument séparément, sans demander au shell d’analyser une chaîne de commande.^{[9], [3]}

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-78
CISA KEV — ajouté le 2026-08-21 — CVE-2026-73570

Analyse de Cause Racine

Le code concerné se trouve dans rpmconf/Conf/swatchrc, fonction dosnmp. Une règle swatch extrait le nom d’un service d’une ligne d’état et le transmet via donotify dans SERVICE ; dosnmp insérait ensuite cette valeur dans une commande entre accents graves contenant $snmptrap. Or les accents graves invoquent un shell : la valeur issue du journal pouvait donc être interprétée comme une syntaxe de commande. Les préconditions documentées sont cumulatives : Zimbra Collaboration Suite antérieur à 10.1.20, paquet facultatif zimbra-snmp installé et notifications SNMP activées. Microsoft indique qu’une entrée SMTP spécialement conçue pouvait atteindre ce chemin. L’entreprise a observé des outils de scan sonder le point d’injection vulnérable du 28 juillet au 7 août 2026, après le correctif du 20 juillet et avant la divulgation publique du 13 août. Le correctif Zimbra remplace la chaîne shell par system(...) en forme de liste, avec l’exécutable et les arguments séparés ; le shell ne participe plus à l’exécution. Cette analyse concerne uniquement le code de notification SNMP et ne signifie pas que toute installation Zimbra ou tout courriel SMTP est vulnérable.^{[1], [2], [3], [5], [7]}

Matrice d’exposition et de correction de CVE-2026-73570

Conditions de déploiement	Le chemin documenté s’applique-t-il ?	Action défensive
Zimbra Collaboration Suite antérieur à 10.1.20 ; paquet facultatif `zimbra-snmp` installé ; notifications SNMP activées.	Les trois conditions sont nécessaires au chemin de notification documenté. Microsoft indique qu’une entrée SMTP spécialement conçue pouvait influencer la valeur d’état du service ensuite traitée par `dosnmp`.	Passez à la version 10.1.20 ou ultérieure. Examinez les journaux pertinents et la télémétrie des processus pour la période d’exposition ; traitez les indicateurs comme des pistes d’enquête, pas comme une preuve de compromission.
Paquet `zimbra-snmp` absent ou notifications SNMP désactivées.	Le chemin de notification `dosnmp` décrit n’est pas actif dans cette configuration. Cela ne prouve pas que le serveur soit exempt d’autres vulnérabilités.	Laissez cette fonctionnalité désactivée ou le paquet absent jusqu’à la mise à jour du serveur. Inventoriez tous les nœuds mailbox et vérifiez la configuration de chacun.
Zimbra Collaboration Suite 10.1.20 ou ultérieur, avec le paquet corrigé par l’éditeur installé.	La construction de commande shell documentée a été corrigée en 10.1.20. Le numéro de version seul ne vérifie ni tous les nœuds ni les modifications locales.	Vérifiez la version et le paquet installés sur chaque nœud, puis appliquez la procédure habituelle de triage pour toute période antérieure réunissant les trois conditions d’exposition.

Déroulement de l'Attaque Étape par Étape

Étape 1

Les préconditions sont réunies

Version antérieure à 10.1.20, paquet zimbra-snmp installé et notifications SNMP activées.^[1]

Étape 2

Le courrier influe sur la supervision

Microsoft signale qu’une requête SMTP pouvait influencer une valeur d’état consignée. Les chaînes d’exploitation et instructions réseau sont omises.^[1]

Étape 3

swatchdog transmet la valeur

Une règle capture le champ du service et le transmet à dosnmp via donotify lorsque les notifications sont actives.^[1]

Étape 4

Le shell interprète les données comme une commande

Avant le correctif, les accents graves Perl transmettaient au shell une chaîne contenant la valeur capturée, sous le compte de service Zimbra.^[1]

Étape 5

10.1.20 retire le shell du chemin

Le correctif appelle snmptrap avec des arguments distincts. Mettez à jour et examinez les instances exposées ; la correction n’exclut pas une activité antérieure.^[1]

Code Source : Vulnérable vs Sécurisé

Les accents graves vulnérables transmettaient au shell une chaîne interpolée. Le correctif utilise system à plusieurs arguments et transmet séparément l’exécutable et chaque argument ; les métacaractères de SERVICE ne deviennent donc pas des instructions shell. L’extrait montre l’appel modifié, pas un exploit exécutable ni une copie intégrale du fichier.^{[3], [4], [8], [9]}

Extrait source: rpmconf/Conf/swatchrc: dosnmp

IMPLÉMENTATION VULNÉRABLE

# Extrait condensé de dosnmp avant correction ; aucune entrée d’exploitation.
sub dosnmp {
    my %args = (@_);
    `$snmptrap $snmpsvctrap $snmpsvcname s $args{SERVICE} $snmpsvcstatus i $statuses{$args{STATUS}}`;
}

PATCH SÉCURISÉ ET ROBUSTE

# Correctif Zimbra 10.1.20 : lancer le programme avec des arguments distincts.
sub dosnmp {
    my %args = (@_);
    system(
        "/opt/zimbra/common/bin/snmptrap",
        "-v", "2c", "-c", "zimbra", $traphost, "",
        $snmpsvctrap, $snmpsvcname, "s", $args{SERVICE},
        $snmpsvcstatus, "i", $statuses{$args{STATUS}}
    );
}

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Mettez à niveau toutes les installations Zimbra Collaboration antérieures à 10.1.20 vers la version 10.1.20 ou ultérieure ; vérifiez les paquets sur chaque nœud mailbox.^{[2], [1]}
✓Recensez les installations de zimbra-snmp et l’état des notifications SNMP. Si le correctif doit attendre, désinstallez le paquet facultatif ou désactivez les notifications selon le cas, et limitez SMTP et SNMP aux systèmes de confiance.^[1]
✓Considérez comme exposées les instances non corrigées accessibles depuis Internet qui remplissent les deux préconditions. Examinez les journaux et la télémétrie des terminaux à la recherche de valeurs d’état inattendues et de processus enfants inhabituels lancés par Perl ou swatchdog.^{[1], [6]}
✓En cas d’exposition avant correctif, conservez les journaux, délimitez les nœuds mailbox concernés, recherchez la persistance et l’activité des comptes, et faites tourner les secrets si les preuves ou l’exposition le justifient.^{[1], [6]}
✓En revue de code, interdisez l’exécution de chaînes shell contenant des valeurs provenant de journaux, de courriels ou d’autres entrées externes. Préférez les API à vecteur d’arguments ; validez strictement toute interface qui dépend encore du shell.^{[8], [9], [7], [3]}
✓Ajoutez un test de régression vérifiant que la valeur du service est transmise comme un argument littéral sans lancer de shell ; utilisez des chaînes bénignes comportant des métacaractères dans un banc d’essai isolé.^{[3], [9]}