Deux failles zero-day dans Zammad permettent à un intrus piloté par IA d’obtenir les privilèges root sur les systèmes du DIVD

Le DIVD relie l’intrusion de son réseau à l’exploitation de deux failles

Le Dutch Institute for Vulnerability Disclosure attribue une récente intrusion dans son réseau à deux vulnérabilités jusque-là inconnues dans Zammad, une plateforme open source utilisée pour la gestion du support et des tickets d’assistance.

Selon les informations publiées sur l’enquête du DIVD, l’attaquant a combiné CVE-2026-102489 et CVE-2026-102490 pour compromettre l’environnement Zammad du DIVD. Cette chaîne d’exploitation lui aurait permis de détourner des sessions, d’exécuter du code à distance et d’élever ses privilèges, du compte de service Zammad jusqu’aux privilèges root.

L’intrus a ensuite accédé à d’autres services, consulté des informations sur les systèmes du DIVD et exfiltré des données. Le cloisonnement du réseau et les mesures prises par l’organisation en réponse à l’incident ont empêché l’attaquant de poursuivre sa progression dans le réseau, a indiqué le DIVD.

Au moment de la publication du compte rendu cité, l’enquête était toujours en cours. Le DIVD prévoyait de publier une nouvelle mise à jour « demain », sans préciser l’heure exacte de sa publication.

D’une session dérobée à un contrôle de niveau root

Les deux vulnérabilités semblent avoir joué des rôles complémentaires, plutôt que d’avoir produit des effets indépendants. Le DIVD décrit une séquence d’attaque qui débute par la prise de contrôle d’une session authentifiée et aboutit à l’exécution de code arbitraire.

L’attaquant aurait ensuite échappé aux restrictions du compte Zammad et obtenu les privilèges root. Sur un système Linux classique, les privilèges root confèrent à un processus le plus haut niveau de contrôle. Cette élévation finale est donc particulièrement grave, même en l’absence de score CVSS publié.

La chaîne d’attaque décrite peut se résumer ainsi :

1. L’exploitation des vulnérabilités de Zammad a permis le détournement de sessions.
2. Le contexte compromis a servi à exécuter du code à distance.
3. L’attaquant a obtenu les privilèges root à partir du compte Zammad.
4. L’intrusion s’est étendue à d’autres services accessibles depuis l’environnement compromis.
5. Des données ont été consultées et exfiltrées avant que les mesures de confinement ne limitent la progression de l’attaquant.

Le rapport disponible ne précise pas quelle vulnérabilité a permis chaque étape, comment la session a été détournée ni quel mécanisme a rendu possible l’exécution à distance. Il ne fournit pas non plus de code de preuve de concept, de schéma de requête ni d’autre détail technique sur l’exploitation.

Les informations publiques ne suffisent donc pas à élaborer des détections propres à ces vulnérabilités. Cela ne remet toutefois pas en cause l’impact décrit : selon le DIVD, les failles ont bien été exploitées conjointement contre sa propre infrastructure.

Selon le DIVD, un agent d’IA a piloté l’intrusion

L’un des aspects marquants de l’incident est que, selon l’analyse du DIVD, l’opération a été menée par un agent d’IA capable de choisir de manière autonome les actions suivantes.

L’organisation indique que l’agent a enchaîné l’exploitation, l’élévation de privilèges, l’accès aux services et le vol de données en quelques secondes, sans intervention extérieure pendant cette séquence. Le DIVD rapporte également que le système a laissé des explications sur ses décisions, dont les enquêteurs se sont servis pour reconstituer l’attaque.

Cette caractérisation doit être limitée à ce que conclut le DIVD. Le rapport attribue une prise de décision autonome à l’agent dans le cadre de cet incident, mais ne précise ni comment l’attaquant a développé le système, ni quel modèle il utilisait, ni le degré de préparation nécessaire avant le début de l’activité automatisée.

La rapidité de l’opération a des conséquences concrètes. Une chaîne automatisée capable d’évaluer les accès obtenus et de choisir immédiatement les étapes suivantes peut condenser plusieurs phases d’une intrusion dans un laps de temps trop court pour permettre une intervention humaine. Les dispositifs de défense doivent donc pouvoir bloquer ou contenir automatiquement l’activité, plutôt que de compter uniquement sur un analyste pour repérer et traiter chaque étape.

Dans ce cas, le cloisonnement a contribué à limiter les conséquences. L’attaquant a accédé à d’autres services, mais les mesures en place l’ont empêché de progresser davantage dans le réseau, selon le DIVD.

Les versions de Zammad concernées ne sont pas encore précisément identifiées

Zammad est disponible sous la forme d’une plateforme de support hébergée ou autohébergée. Elle permet de gérer les demandes des clients, les processus d’assistance informatique et les tickets internes. Elle peut donc constituer une cible de choix : les systèmes de gestion des tickets contiennent parfois des échanges sensibles et sont connectés à d’autres services de l’entreprise.

L’éditeur revendique plus de 2 000 clients et 55 000 utilisateurs. Parmi les organisations citées dans le rapport comme utilisatrices de Zammad figurent De’Longhi, Amnesty International et NextCloud. Leur mention à ce titre ne signifie pas que leurs systèmes ont été ciblés ou compromis.

La divulgation citée ne précise pas quelles versions de Zammad sont vulnérables. Elle n’indique pas non plus les plages de versions concernées, le niveau de correctif requis ni la configuration nécessaire à l’exploitation.

Les administrateurs ne peuvent donc pas déterminer de manière fiable s’ils sont exposés en comparant leur installation à une liste détaillée de versions vulnérables. Le conseil du DIVD est plus général : passer à Zammad version 7, considérée comme sûre, ou mettre l’instance hors ligne dès que possible.

Le DIVD indique avoir découvert les vulnérabilités avec Merlon Security et en avoir informé Zammad. L’organisation prévenait également les utilisateurs dont elle savait qu’ils disposaient d’instances vulnérables.

Mesures prioritaires pour les administrateurs

Les opérateurs de Zammad doivent faire de la mise à niveau leur priorité. Les systèmes qui ne peuvent pas passer rapidement à la version 7 doivent être isolés ou mis hors ligne, conformément aux recommandations du DIVD, jusqu’à ce qu’ils puissent être sécurisés.

Puisque la compromission décrite a entraîné le détournement de sessions et l’exécution de code avec les privilèges root, une simple réinitialisation du mot de passe peut ne pas suffire si le système a déjà été exploité. Les administrateurs doivent examiner l’hôte et les services connectés afin de détecter toute trace d’accès non autorisé, d’élévation de privilèges ou de récupération de données.

Les points à examiner comprennent notamment :

• Les sessions authentifiées inhabituelles ou les changements dans leur comportement.
• Les processus lancés sous le compte Zammad qui ne correspondent pas au fonctionnement normal de l’application.
• Les indices d’exécution de commandes ou de processus avec les privilèges root.
• Les connexions de l’hôte Zammad vers des services internes auxquels il n’accède pas habituellement.
• Les transferts sortants inhabituels ou l’accès à de grandes quantités de données de tickets et de services.
• Les modifications de comptes, d’autorisations ou de configuration effectuées pendant une activité suspecte.

Il s’agit de pistes générales d’investigation, déduites des effets décrits par le DIVD, et non d’indicateurs propres à ces vulnérabilités. Le rapport cité ne fournit aucune adresse IP, empreinte de fichier, nom de domaine, signature dans les journaux ni autre indicateur de compromission concret.

Dans la mesure du possible, les équipes de défense doivent préserver les journaux système, applicatifs, d’authentification et réseau avant de réinstaller le système ou de mettre hors ligne un hôte suspect. Le cloisonnement du serveur de tickets par rapport aux services internes sensibles peut également limiter les ressources auxquelles un attaquant peut accéder après une compromission initiale, comme le montre l’expérience du DIVD.

Plusieurs questions techniques restent en suspens

L’incident a entraîné des conséquences importantes, mais plusieurs éléments nécessaires à une évaluation plus générale du risque restent inconnus. Le rapport cité ne fournit ni score CVSS ni évaluation formelle de la gravité, et les versions exactes concernées ne sont pas identifiées.

Il ne précise pas non plus quels builds sont vulnérables ou corrigés, version par version. Les informations publiques ne révèlent ni les requêtes utilisées pour exploiter les failles, ni les conditions d’accès nécessaires, ni les traces laissées par la chaîne d’attaque.

Enfin, le rapport n’indique pas que d’autres clients de Zammad aient été victimes d’une intrusion. Le périmètre confirmé se limite à l’incident du DIVD et à l’attribution de cette compromission aux deux failles zero-day.

Pour l’instant, la combinaison du détournement de sessions, de l’exécution de code à distance et de l’élévation aux privilèges root appelle une réponse claire : passer à la version 7 ou retirer du service l’instance exposée. De nouvelles conclusions du DIVD et des informations techniques de Zammad seront nécessaires pour déterminer précisément quels utilisateurs sont concernés et mettre au point des mécanismes de détection ciblés.