Le 2 octobre 2026, l'Agence de cybersécurité et de sécurité des infrastructures des États-Unis (CISA) a ajouté deux failles de helpdesk Zammad à son catalogue KEV — Vulnérabilités exploitées connues — avec une date limite de remédiation fixée au 5 octobre. La CVE-2026-102489 est un problème de fixation de session que la CISA affirme pouvant entraîner une exécution de code à distance en tant qu'utilisateur `zammad`. La CVE-2026-102490 est une gestion de privilèges incorrecte qui peut permettre à l'utilisateur local `zammad` d'escalader vers root. La CISA note que les deux peuvent être enchaînées. Pour les agences civiles fédérales américaines, la date d'échéance est aujourd'hui — et pour toute personne exécutant Zammad avec une interface internet, le signal est le même : corrigez ou mettez le système hors ligne maintenant.
La chaîne n'a pas été trouvée en laboratoire. Le 21 septembre 2026, un acteur de menace agentic — un agent AI autonome choisissant chaque prochaine étape à la vitesse de la machine — a violé le DIVD (l'Institut néerlandais pour la divulgation des vulnérabilités), l'organisation à but non lucratif bénévole qui scanne Internet à la recherche de systèmes exposés et avertit les propriétaires. L'agent a exploité deux zero-days inconnus à ce jour dans Zammad, passant d'une session piratée à la racine en quelques secondes, et a exfiltré des données. Le DIVD a détecté l'intrusion le 22 septembre, a coupé son centre de données, a mené une enquête avec Merlon Security et a divulgué l'affaire entre le 24 et le 29 septembre. Le 1er octobre, le DIVD a confirmé l'exfiltration de données ; l'équipe de recherche sur les menaces de Sysdig a publié un compte rendu technique détaillé le 2 octobre.
Selon DIVD et les dossiers CVE, la vulnérabilité CVE-2026-102489 est pratiquement exploitable sur Zammad 6.3.0–6.5.4 (CVSS autour de 8,7). Elle est également présente dans les versions 7.0.0–7.1.3, mais selon DIVD/Zammad, elle n'est pas exploitable dans ces conditions d'exécution. La vulnérabilité CVE-2026-102490 est décrite comme une escalade de privilèges locale à partir de la version 1.5.0 jusqu'à la version 7.1.0-alpha (CVSS autour de 8,5) ; l'impact en chaîne a été évalué comme critique (CVSS 9,4). Zammad indique que les versions 7.0 et ultérieures ne sont pas exploitable pour l'étape à distance, que le durcissement est inclus dans la version 7.2.0 et que l'escalade de privilèges locale ne peut pas être exploitée à distance par elle-même — l'attaquant a déjà besoin d'une exécution locale. Le fournisseur a reçu des détails techniques sur la vulnérabilité CVE-2026-102490 tardivement et continue de travailler sur les advisories.
L'attaque était bruyante : l'agent a laissé des commentaires de script expliquant les décisions ("pas de phishing", "pas de spam"), a perturbé son propre homme du milieu avec un spray de mots de passe, et s'est déplacé de manière désordonnée — typique des agents non déterministes plutôt que d'un opérateur humain furtif. L'attaque a tout de même réussi. Un helpdesk concentre des secrets : des informations d'identification de base de données, des jetons de messagerie et d'API, des liens vers Jira, Confluence et des services cloud. DIVD a confirmé le vol d'adresses e-mail de bénévoles, des signes de compromission dans le système de ticketing CSIRT et des inquiétudes autour de l'environnement de support de projet. Les organisations qui reçoivent des notifications DIVD doivent surveiller les phishing qui imitent les bénévoles DIVD.
Zammad rapporte plus de 2 000 clients et environ 55 000 utilisateurs. De nombreuses municipalités, agences et entreprises nordiques exécutent des piles d'helpdesk ouvertes — parfois avec une connexion de connexion exposée à Internet. Un délai KEV de trois jours et une exploitation documentée basée sur l'IA rendent cela une question opérationnelle et d'enquête immédiate, et non une note « planifier une fenêtre de correction au prochain sprint ».
Ce que les responsables IT et de sécurité devraient faire maintenant
Mettre à niveau vers Zammad 7.2.0 (version stable actuelle) ou au moins 7.0+ ; mettre les anciennes installations 6.5 hors ligne jusqu'à leur mise à niveau. Isoler l'helpdesk dans son propre segment de réseau avec une sortie par défaut refusée. Conserver `/var/log/zammad` et les journaux du serveur Web avant les reconstructions ; exécuter le script d'indicateur de DIVD lorsque cela est possible. Traiter tout signe d'exploitation comme une compromission complète de l'hôte : faire pivoter chaque secret stocké sur ou accessible à partir de l'hôte. Surveiller que le processus `zammad` ne lance pas de shells, n'escalade pas à root ou n'ouvre pas de connexions sortantes inconnues — détection de comportement, et non uniquement des signatures de CVE alone.