TroutTrout
Back to Blog
OT SecurityICS AdvisoriesRemote AccessHMI

Un CVSS 10 sur l'équipement exposé à Internet : Haiwell IoT Cloud HMI Gateway (ICSA-26-225-02)

Trout Team6 min read

La version courte

Le 13 août 2026, la CISA a publié ICSA-26-225-02 concernant la passerelle HMI cloud IoT Haiwell, le boîtier qui relie les HMI de terrain à un service cloud dans les secteurs de l'énergie, de la fabrication critique et du traitement des eaux et des eaux usées. La vulnérabilité, CVE-2026-19188, est une faille d'injection de commandes OS avec un score de base CVSS v3 de 10, le maximum. Une exploitation réussie exécute des commandes arbitraires du système d'exploitation en tant que root, ce qui correspond à un contrôle total du dispositif.

Le nom du produit contient une vérité difficile à ignorer. Il s'agit de la passerelle, le composant dont la seule fonction est d'être accessible depuis l'extérieur de l'installation. Une faille de sévérité maximale sur le composant le plus exposé est le pire endroit où en trouver une, et la portée qui la rend dangereuse est précisément la partie que vous maîtrisez.

Ce que dit l'avis

Directement extrait de l'avis et de l'enregistrement CVE :

  • Produit : passerelle HMI cloud IoT Haiwell, version 3.40.1.12.
  • La faille : CVE-2026-19188, neutralisation incorrecte d'éléments spéciaux dans une commande OS, plus connue sous le nom d'injection de commandes OS.
  • Impact : un attaquant peut injecter et exécuter des commandes OS arbitraires avec des privilèges root.
  • Sévérité : CVSS v3 10, le score maximum.
  • Secteurs et déploiement : énergie, fabrication critique et traitement des eaux et des eaux usées, déployé dans le monde entier.
  • Remédiation : appliquer les recommandations de Haiwell pour le firmware concerné. La CISA ajoute ses directives ICS standard, et cette fois elles résument tout : s'assurer que le dispositif n'est pas accessible depuis internet, le placer derrière des pare-feux, l'isoler du réseau d'entreprise, et acheminer tout accès distant via un chemin contrôlé.

La CISA n'a signalé aucune exploitation active au moment de la publication. Avec un CVSS 10 sur une passerelle adjacente à internet, traitez cela comme une exposition à fermer maintenant, pas plus tard.

Pourquoi cela se répète

Les passerelles cloud constituent la jonction d'un réseau OT moderne. Elles existent pour transporter des données depuis des équipements qui n'ont jamais été conçus pour faire face à internet vers un service qui y réside, et pour cela elles se positionnent là où les deux côtés peuvent les atteindre. Cette position est utile et dangereuse à la fois. Chaque commodité qu'offre la passerelle est aussi une surface d'attaque, et le dispositif est généralement maintenu selon le cycle de firmware du fournisseur, pas le vôtre.

Ainsi, lorsqu'une faille d'injection de commandes touche une passerelle HMI cloud, la surface accessible n'est pas un coin tranquille de l'installation. C'est le seul boîtier que vous avez délibérément connecté à l'extérieur.

Ce qui est réellement exploité

Réduisons le CVE à sa mécanique. Un attaquant capable d'atteindre l'interface de la passerelle envoie une entrée qui est transmise, sans assainissement, dans une commande du système d'exploitation, et la passerelle l'exécute en tant que root. Il n'y a pas d'escalade de privilèges à enchaîner ni de second bug à trouver. Atteindre l'interface, envoyer la charge utile, prendre le contrôle du dispositif. Un CVSS 10, c'est ce que cela donne sur le papier.

La question sur votre propre réseau n'est donc pas seulement de savoir si le firmware Haiwell est à jour. C'est de savoir ce qui peut actuellement ouvrir une connexion vers la passerelle, si cela inclut quoi que ce soit sur internet, et si vous le verriez si quelque chose le faisait.

Le contrôle qui délimite réellement la menace

Vous fermez cette exposition comme le décrit la CISA, en rendant la passerelle accessible uniquement via un point d'application plutôt qu'en la laissant répondre à quiconque la trouve.

L'Access Gate se place dans le chemin d'accès et gère chaque session qui atteint le dispositif. En pratique :

  • La passerelle cesse de répondre à des clients arbitraires, aussi bien sur le réseau de l'installation que sur internet. Le seul moyen d'y accéder est une session que l'Access Gate a déjà authentifiée, de sorte qu'une faille d'injection de commandes perd sa condition préalable : un appelant non authentifié sur le réseau.
  • Chaque session est liée à une personne ou un service nommé, limitée à la tâche concernée, avec MFA géré au niveau de la porte, et enregistrée, l'accès des fournisseurs et des intégrateurs à la passerelle devient enfin traçable.
  • Parce que l'Access Gate est un composant de calcul sur le réseau, un point d'application sans agent placé devant le dispositif plutôt qu'un service cloud propre, il applique cela sans rien installer sur la passerelle et sans ajouter une autre dépendance exposée à internet.

Cela ne remplace pas le correctif du fournisseur. Appliquez la mise à jour Haiwell dès qu'elle est disponible et validée. Ce que le point d'application vous apporte, c'est ce qu'un CVSS 10 ne vous laisse pas le temps de faire : l'exposition est fermée maintenant, et elle reste fermée face à la prochaine faille d'un boîtier dont la fonction est d'être accessible. La mécanique est détaillée dans ce qu'est un proxy industriel, et le volet accès est couvert dans l'accès distant sécurisé OT et fournisseur.

Par où commencer cette semaine

  1. Localisez chaque passerelle HMI cloud IoT Haiwell et vérifiez si l'une d'elles est accessible depuis internet, directement ou via redirection de port. Si c'est le cas, fermez cela aujourd'hui.
  2. Cartographiez quels segments internes peuvent ouvrir une connexion vers chaque passerelle. Sur un réseau plat, c'est généralement bien plus que ce dont la passerelle a besoin.
  3. Suivez les recommandations firmware de Haiwell et appliquez-les selon votre processus habituel, mais ne laissez pas un CVSS 10 attendre une fenêtre de maintenance sans rien devant lui.
  4. Placez les passerelles derrière un point d'application afin que l'accès soit lié à une identité, soumis au moindre privilège et enregistré, y compris pour le fournisseur.
  5. Effectuez la même vérification sur chaque autre dispositif adjacent à internet dans le parc OT. Le prochain avis nommera une passerelle différente, et la réponse ne changera pas.

ICSA-26-225-02 est un cas limpide parce que le correctif et le point d'exposition pointent dans la même direction. Le boîtier le plus accessible est le plus dangereux à laisser ouvert, vous décidez donc ce qui est autorisé à l'atteindre, et vous consignez cette décision par écrit.

FAQ

Frequently Asked Questions

What is CISA advisory ICSA-26-225-02?
It is an ICS advisory CISA published on 13 August 2026 for the Haiwell IoT Cloud HMI Gateway. It covers CVE-2026-19188, an OS command injection flaw with a CVSS v3 base score of 10, the maximum, that can let an attacker run arbitrary operating-system commands with root privileges. CISA reported no known public exploitation at the time of release.
How serious is the Haiwell IoT Cloud HMI Gateway vulnerability?
It carries the maximum CVSS v3 score of 10. The flaw is OS command injection (CWE-78), and successful exploitation runs commands as root, which is full control of the device. Because the affected product is a gateway built to connect field equipment to a cloud service, the component most likely to be reachable is the one that is most dangerous when compromised.
Which product and version are affected?
Per the advisory, Haiwell IoT Cloud HMI Gateway version 3.40.1.12 is affected by CVE-2026-19188. The product is deployed worldwide across the Energy, Critical Manufacturing, and Water and Wastewater sectors. Check your own firmware against the advisory and Haiwell's guidance.
How do I protect the Haiwell gateway if a fix is not available yet?
Take it off the open network. CISA's own guidance is to ensure it is not accessible from the internet and to isolate it from the business network. In practice that means putting an enforcement point in front of it so the only way to reach the gateway is an identity-bound, recorded session, and the device stops answering arbitrary clients, including anything scanning from the internet.
Why is an internet-facing OT gateway such a common weak point?
Because its function is to be reachable. A cloud HMI gateway bridges field devices to an external service, so it tends to sit where both the plant and the internet can touch it. That makes a command-injection flaw far more dangerous than the same bug on an isolated device: the thing an attacker needs first, network reach, is the gateway's reason for existing. Controlling that reach is the control that actually bounds the risk.