En bref
Le 6 août 2026, CISA a publié ICSA-26-218-01 pour ABB Ability Zenon, la plateforme SCADA, HMI et IIoT utilisée dans l'énergie, l'eau, l'industrie manufacturière et l'agroalimentaire. L'avis recense 13 vulnérabilités, avec un CVSS v3 allant jusqu'à 7,8, et décrit l'impact comme un contournement de la sécurité, un arrêt des systèmes, l'exécution d'actions non autorisées ou la compromission de données.
Ce qui frappe, c'est l'endroit où ces failles se logent. Aucune ne se trouve dans la logique de contrôle de Zenon. Les 13 sont toutes dans une base de données MongoDB 4.2 que les services IIoT d'ABB embarquent dans la plateforme. La plus récente, CVE-2025-14847, permet à un client non authentifié de lire une zone mémoire non initialisée via un en-tête compressé malformé. Les autres sont des failles de MongoDB Server datant de 2020 et 2021, du contournement d'autorisation au déni de service.
Cette distinction change votre manière de réagir. Vous ne pouvez pas mettre à niveau une base de données qu'ABB livre à l'intérieur de son produit. Elle évolue au rythme du cycle de publication d'ABB, qui, sur un système validé, critique pour la disponibilité, peut être lent. La réponse utile n'est donc pas d'attendre, mais de changer ce qui peut atteindre le composant.
Ce que dit l'avis
Directement tiré de l'avis et des fiches CVE :
- Produit : ABB Ability Zenon. Le composant concerné, ce sont les services IIoT d'ABB avec MongoDB 4.2, répertorié pour toutes les versions de cette configuration.
- Les failles : 13 CVE. Une est nouvelle, CVE-2025-14847, une lecture du tas sans authentification. Les autres sont des CVE de MongoDB Server datant de 2020 et 2021, dont CVE-2020-7921 (une faille du sous-système d'autorisation qui permet de contourner une liste d'autorisation d'adresses IP), CVE-2020-7925 (une faille d'analyseur qu'un attaquant non authentifié peut atteindre), et une série de bugs de déni de service et d'accès mémoire (CVE-2020-7928, 7929, 7923, 7924 et CVE-2021-20330, 32036, 32040, 20333, 20328, 20334).
- Gravité : CVSS v3 jusqu'à 7,8.
- Ce que cela permet, selon CISA : contourner la sécurité, arrêter des systèmes, exécuter des actions non autorisées ou compromettre des données.
- Comment on l'atteint : les bugs exposés sur le réseau exigent un attaquant capable d'ouvrir une connexion vers la base de données. Certains n'exigent aucun compte.
- Remédiation : ABB fournit des consignes dans l'avis. CISA ajoute sa recommandation habituelle pour l'ICS : garder le système hors de l'internet public, l'isoler du réseau d'entreprise et faire passer les accès distants par un chemin contrôlé.
CISA n'a signalé aucune exploitation connue de ces failles. À lire comme une exposition à refermer, pas comme un incendie à éteindre.
Pourquoi cela se répète
Oubliez le nom d'ABB : c'est le portrait de n'importe quelle plateforme OT. Aucun de ces produits n'est un binaire unique. Les éditeurs y embarquent des bases de données, des historiens de données, des serveurs web, des courtiers de messages et des runtimes de langage pour livrer des fonctionnalités plus vite, et chacun apporte ses propres vulnérabilités dans votre usine.
Le problème, c'est le calendrier. Vous ne pouvez pas remplacer le MongoDB embarqué sans risquer le support et une nouvelle validation de la plateforme qui en dépend. Le vrai correctif arrive quand ABB reconstruit et relivre, et en OT cela peut prendre du temps face à un système certifié que personne ne veut redémarrer. Entre-temps, le composant continue son travail : il répond sur un port, sur un réseau, exactement comme prévu.
Une base de données de la génération 4.2 qui traîne des CVE vieilles de cinq ans dans une plateforme de 2026, ce n'est pas de la négligence. C'est l'écart normal entre le moment où une dépendance publie un correctif et celui où un éditeur peut l'intégrer en toute sécurité dans un produit industriel. L'exposition est inscrite dans la façon dont les logiciels OT sont assemblés, si bien que le correctif seul aura toujours un temps de retard.
Ce qui est réellement exploité
Sous la liste des CVE, le risque est simple. Un attaquant atteint une base de données qui n'aurait jamais dû être accessible, et dialogue avec elle. Pour les failles sans authentification, c'est toute l'attaque. Pas de malware, pas de chaîne de zero-day, pas de compte volé. Un accès réseau et une requête forgée.
C'est pourquoi le conseil de CISA dans cet avis est le même qu'elle répète dans presque tous : ne pas exposer le système, l'isoler, et placer les accès distants derrière un chemin contrôlé. Les bugs, c'est à ABB de les corriger. L'accessibilité, c'est à vous.
La question qui vaut la peine d'être posée sur votre propre réseau n'est pas de savoir si MongoDB est corrigé. C'est ce qui peut actuellement ouvrir une connexion vers les services IIoT, et si vous le verriez si quelque chose le faisait. Sur un réseau d'usine à plat, la réponse est en général tout ce qui se trouve sur le sous-réseau, et non.
Le contrôle qui délimite vraiment le problème
Vous refermez cela sans le correctif en rendant le composant accessible uniquement via un point d'application.
Un proxy industriel se place sur le chemin d'accès aux services IIoT d'ABB Ability Zenon et arbitre chaque session qui les atteint. Concrètement :
- La base de données cesse de répondre à des clients quelconques sur le sous-réseau. Le seul accès passe par une session que le proxy a déjà authentifiée, ce qui prive les failles sans authentification de ce dont elles ont le plus besoin : un appelant non authentifié.
- Chaque session est rattachée à une personne ou à un service nommé, limitée à ce que le travail exige, avec la MFA gérée au niveau du proxy. Rien n'est modifié sur la pile ABB, donc rien n'a besoin d'être corrigé, revalidé ou redémarré pour que cela tienne.
- Chaque session qui touche les services IIoT est journalisée, si bien que la question « le remarquerions-nous ? » a enfin une réponse.
- Il n'installe rien sur la plateforme. C'est un conduit IEC 62443 entre la zone de contrôle et tout ce qui se trouve au-dessus, soit l'idée de la DMZ industrielle ramenée à un seul composant embarqué.
Cela ne remplace pas le correctif. Appliquez la remédiation d'ABB quand votre processus de gestion des changements le permet. Ce que cela vous fait gagner, c'est un temps que le correctif ne peut pas offrir : l'exposition est refermée maintenant, elle reste refermée jusqu'à la prochaine CVE de composant embarqué dont vous n'avez pas encore entendu parler, et rien de tout cela ne touche un système certifié que vous ne pouvez pas vous permettre de perturber. Le fonctionnement est détaillé dans ce qu'est un proxy industriel, et le volet audit dans la micro-segmentation OT avec intégration SIEM.
L'avis Johnson Controls, en bref
CISA a diffusé un second avis le même jour, ICSA-26-218-02, pour le communicateur d'alarme réseau Johnson Controls TL280, dans l'industrie manufacturière critique. La faille est constituée d'identifiants codés en dur dans le firmware (CVE-2026-27871, CVSS v3 4,1), et Johnson Controls la corrige par une mise à jour du firmware.
Enjeu moindre, boîtier différent, forme familière. Vous ne pouvez pas dé-coder en dur un identifiant dans le firmware d'un autre. Ce que vous pouvez faire, c'est vous assurer que l'équipement ne répond que sur un chemin qui authentifie et journalise quiconque se connecte, de sorte qu'un identifiant statique fuité ne vaille pas une porte ouverte. Deux avis, un jour, le même geste de fond.
Par où commencer cette semaine
- Repérez ABB Ability Zenon et ses services IIoT dans votre environnement, et notez quels segments peuvent actuellement ouvrir une connexion vers eux.
- Vérifiez que la base de données n'est pas accessible depuis le réseau d'entreprise ou internet. Si elle l'est, refermez cela en premier.
- Appliquez la remédiation d'ABB selon votre processus de gestion des changements habituel et suivez-la, mais ne laissez pas la date du correctif être la seule chose entre un client non authentifié et le composant.
- Déplacez les services IIoT derrière un point d'application pour que l'accès soit lié à une identité, en moindre privilège et journalisé.
- Faites la même vérification sur les autres composants embarqués de votre pile SCADA et HMI. Le prochain avis nommera une autre base de données ou un autre runtime, et la réponse ne changera pas.
ICSA-26-218-01 est une bonne occasion de corriger quelque chose de plus large qu'un seul composant. En OT, vous pouvez rarement corriger la faille selon votre propre calendrier, alors vous fixez plutôt les conditions de ce qui peut l'atteindre.