Faille Zammad : un agent IA pirate un service d’assistance en quelques secondes (FAQ)

2

failles « zero-day » enchaînées

secondes

de la session détournée à root

7.2.0

version stable recommandée par Zammad

Le 21 septembre, l’attaquant entre par le Zammad interne du DIVD. Le 22, le DIVD détecte l’intrusion, coupe l’accès à tous les systèmes de son centre de données et lance une enquête avec Merlon Security. Le 24, il avise l’autorité néerlandaise de protection des données et le NCSC, rend l’incident public et signale les failles à Zammad. Le 29, les deux CVE sont publiées. Le 1^er octobre, le DIVD confirme une exfiltration de données.

Parce qu’un outil de billets concentre des secrets : identifiants de base de données, jetons de messagerie et d’API, accès aux systèmes que l’équipe de soutien touche, sans parler du contenu des échanges avec les clients. Selon Sysdig, l’accès root à ce serveur expose tout cela d’un coup. Zammad revendique plus de 2 000 clients et 55 000 utilisateurs.

CVE-2026-102489 : détournement de session menant à l’exécution de code comme utilisateur zammad. Exploitable sur les versions 6.3.0 à 6.5.4; présente aussi en 7.0.0 à 7.1.3, mais non exploitable en pratique selon le DIVD (CVSS 8,7).

CVE-2026-102490 : élévation de privilèges locale de zammad vers root, que le DIVD décrit comme présente de la 1.5.0 à la 7.1.0-alpha (CVSS 8,5). Zammad précise qu’elle ne peut pas être exploitée à distance seule : l’attaquant doit déjà avoir un pied sur le serveur.

Enchaînées, le DIVD les note 9,4 (critique).

La vitesse. L’agent choisissait chaque étape après la précédente, à vitesse machine. Le DIVD le décrit comme « bruyant et très, très brouillon » (traduction) : il commentait ses propres scripts, et sa pulvérisation de mots de passe a même perturbé sa propre attaque de l’homme du milieu. Ce bruit a permis une détection en moins d’un jour… ce qui était déjà trop tard. Un agent mieux conçu fera moins de bruit.

Selon l’analyse préliminaire rapportée par Sysdig : les adresses courriel DIVD des bénévoles (exfiltration confirmée), possiblement leurs coordonnées, et une partie du système de billets du CSIRT. D’autres environnements (Jira, Confluence, Google Workspace, Slack, code source…) étaient encore sous enquête au 1^er octobre. Aucun groupe n’a revendiqué l’attaque. Conséquence directe : attendez-vous à des courriels d’hameçonnage se faisant passer pour le DIVD.

• Mettez à jour vers Zammad 7.2.0 (version stable recommandée par l’éditeur) ou mettez l’instance hors ligne. Les versions 6.5 et antérieures ne reçoivent plus de correctifs.
• Avant de reconstruire, conservez /var/log/zammad et /var/log/nginx, et passez-y le script de détection publié par le DIVD.
• Tout signe d’exploitation = serveur entièrement compromis : changez tous les identifiants et jetons stockés sur ce serveur ou accessibles depuis lui.
• Isolez l’outil dans son propre segment réseau, avec sorties Internet bloquées par défaut.

Les sources consultées ne disent pas si la version hébergée de Zammad est touchée : demandez-le à votre fournisseur. Pour tout outil en mode SaaS, la leçon reste la même : MFA sur tous les comptes, jetons d’API limités au strict nécessaire, et pas de mots de passe en clair dans les billets. Le même réflexe vaut pour les serveurs maison oubliés, comme on l’a vu avec Warlock et SharePoint.

Une faille zero-day n’a pas de signature, mais ses comportements en ont : un compte de service qui ouvre un terminal, devient root ou contacte une destination inconnue. Ce sont ces signaux qu’il faut surveiller en continu, avec une réponse rapide prévue d’avance (isoler le serveur, couper l’accès). Pour d’autres exemples d’agents IA utilisés par des attaquants, voir notre article sur la tentative contre Bibliothèque et Archives Canada.