DIVD et Zammad : relier la reprise du support aux versions réellement concernées

Les faits rapportés par DIVD

DIVD indique qu’un attaquant est entré dans son centre de données le 21 septembre 2026 via deux failles zero-day de Zammad. Ce récit désigne le logiciel de support comme point d’entrée. Il n’établit pas une exposition identique pour toutes les organisations utilisant Zammad.

DIVD annonce avoir détecté l’activité malveillante en 19 minutes. Il s’agit d’une mesure rapportée par l’organisation, pas d’un résultat mesuré indépendamment. Le délai de détection doit rester distinct de l’ampleur de la reprise.

La réponse décrite est étendue : DIVD indique avoir arrêté et reconstruit tous les systèmes du centre de données. Les équipes support peuvent s’en servir pour examiner leurs propres capacités de reprise si leurs preuves exigeaient une telle décision. Ce n’est pas une consigne de reconstruction générale des installations.

DIVD affirme que son environnement CVE/CNA séparé ne présentait aucun indice d’accès. L’absence d’indice est la limite formulée. Elle ne doit pas devenir une preuve absolue concernant tous les environnements.

Des conditions d’exploitation différentes

Selon Zammad, CVE-2026-102489 n’est pratiquement exploitable que sur Zammad 6.5 et les versions antérieures, en raison de leur environnement d’exécution. La distinction de versions est essentielle. Nommer uniquement le produit masquerait l’évaluation de l’éditeur.

Zammad précise que CVE-2026-102490 exige un accès préalable au serveur et ne peut pas être exploitée à distance seule. Cette condition diffère de celle d’une faille permettant l’entrée distante. Les deux ne doivent pas être présentées comme des voies équivalentes.

BleepingComputer rapporte que DIVD a identifié les failles enchaînées comme CVE-2026-102489 et CVE-2026-102490. Décrire une chaîne ne supprime pas les conditions nécessaires à chacune de ses étapes.

BleepingComputer indique aussi que DIVD a découvert les failles avec Merlon Security. Cette attribution concerne l’enquête rapportée. Les faits permettent de décrire l’entrée, la réponse et les conditions d’exploitation sans élargir le récit à une autonomie d’attaque non établie.

Une démarche conditionnelle pour les équipes algériennes

L’intérêt local concerne les organisations qui exploitent réellement Zammad. Les faits ne désignent ni installation ni victime algérienne. Commencer par établir la présence du produit, sa version et l’exposition du déploiement.

Comparer cet inventaire aux conditions publiées par l’éditeur. Avant de choisir une mise à jour, consulter les recommandations de version prise en charge pour ce déploiement précis. Rien ici ne justifie de présenter une mise à niveau arbitraire comme un remède universel.

La reprise mérite une revue distincte : qui peut autoriser l’arrêt, quels systèmes faudrait-il reconstruire et sur quelles preuves ? Un délai court de détection ne décrit pas à lui seul le coût ni l’exhaustivité de la reprise.

La précision rend la décision possible

L’intérêt de ce cas tient à ses limites clairement conservées : récit de DIVD, évaluation de l’éditeur liée aux versions et prérequis différents. Pour une équipe algérienne, le résultat utile est une décision d’applicabilité documentée et un plan de reprise adapté.

Questions Fréquemment Posées

Sources et lectures complémentaires

• DIVD
• Zammad
• BleepingComputer
• Un agent d’IA a exploité des failles zero-day de Zammad pour compromettre un organisme néerlandais de divulgation de vulnérabilités — Help Net Security