La version courte
Le 20 août 2026, la CISA a publié ICSA-26-232-01 concernant Johnson Controls Simplex Incident Manager, en republiant l'avis de sécurité produit Johnson Controls JCI-PSA-2026-28. La vulnérabilité, CVE-2026-27875, révèle que l'application conserve les identifiants utilisateurs, mots de passe et jetons d'authentification en clair dans la mémoire système pendant son exécution. Toute personne disposant d'un accès local et d'un outil de vidage mémoire peut les lire.
Le score est CVSS v3.1 5.8, niveau moyen. La vulnérabilité n'est pas exploitable à distance, présente une complexité d'attaque élevée, et la CISA ne signale aucune exploitation publique connue. En temps normal, ce serait une note de bas de page.
Lisez-le quand même, et lisez-le pour la classe de vulnérabilité plutôt que pour le score. La collecte d'identifiants n'est jamais le premier geste d'une intrusion. C'est le deuxième. Le score reflète la difficulté d'accès à la faille ; il ne dit rien de ce qui se passe ensuite, quand l'attaquant dispose déjà de ce qu'il lui faut pour l'atteindre.
Ce que dit l'avis
Directement tiré de l'avis et de l'enregistrement CSAF :
- Produit : Johnson Controls Simplex Incident Manager. Simplex est la marque de détection incendie et de sécurité des personnes de Johnson Controls.
- Versions concernées : v2.01 et antérieures.
- La faille : CVE-2026-27875, CWE-316, Stockage en clair d'informations sensibles en mémoire. L'application « stocke les identifiants utilisateurs (tels que les mots de passe et les jetons d'authentification) sous une forme non chiffrée dans la mémoire système pendant son exécution. »
- Qui peut l'exploiter : selon la CISA, « toute personne disposant d'un accès local au système, y compris des attaquants utilisant des outils de vidage mémoire ou des initiés disposant de privilèges élevés. »
- Sévérité : score de base CVSS v3.1 5.8, vecteur
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L. L'impact sur la confidentialité est Élevé ; l'intégrité et la disponibilité sont Faibles. - Statut d'exploitation : non exploitable à distance, complexité d'attaque élevée, aucune exploitation publique connue signalée à la CISA.
- Signalé par : Johnson Controls, à la CISA. Il s'agit d'une divulgation par le fournisseur lui-même, et non d'une découverte de recherche externe.
- Version corrigée : v2.01.01.
- Secteurs concernés : Fabrication critique, Installations commerciales, Services et installations gouvernementaux, Systèmes de transport, Énergie. Déploiement mondial.
Un point à vérifier avant d'ouvrir le ticket de mise à niveau
Le texte de mitigation publié par la CISA contient une contradiction interne. Il indique que Johnson Controls « a publié une version corrigée (v2.01.01) », puis, dans la liste des mesures défensives qui suit immédiatement, précise : « Mettre à niveau Simplex Incident Manager vers la version v1.01.05 ou ultérieure. »
Ces deux affirmations ne peuvent pas être simultanément exactes. La plage concernée est v2.01 et antérieures, donc v1.01.05 se situe dans la plage vulnérable, et non au-dessus. Un lecteur qui suit la deuxième ligne à la lettre installerait une version plus ancienne et enregistrerait le problème comme résolu. Considérez v2.01.01 comme la cible et confirmez auprès de JCI-PSA-2026-28 avant de planifier les travaux.
Ce point mérite d'être signalé, car le texte des avis est souvent copié mot pour mot dans les tickets de changement, et un numéro de version erroné dans un ticket survit bien plus longtemps qu'un numéro de version erroné sur une page web.
Pourquoi un 5.8 mérite dix minutes
Le CVSS répond bien à une question : quelle est la difficulté d'accès à la faille. Il répond mal à une autre : quelle est l'importance de la faille une fois atteinte.
Le vecteur indique ici un accès local, des privilèges faibles déjà obtenus, une complexité d'attaque élevée. En termes de gestion des vulnérabilités, c'est une position confortable. En termes d'intrusion, c'est la description d'un attaquant déjà présent sur l'hôte, ce qui correspond au milieu ordinaire de tout incident réel. Personne n'atteint un magasin d'identifiants comme premier geste. On l'atteint après avoir hameçonné un ingénieur, après un ordinateur portable de sous-traitant, après un service de périphérie non corrigé. Et ce que l'on cherche à ce stade, c'est exactement ceci : un secret réutilisable qui ouvre l'accès au système suivant.
C'est la raison pour laquelle cette classe de vulnérabilité est disproportionnellement utile à un attaquant par rapport à son score. Une faille d'exécution de code à distance vous donne une machine. Un ensemble d'identifiants collectés vous donne toutes les machines qui les acceptent. L'impact sur la confidentialité est évalué Élevé ici pour une bonne raison, même si le score global reste à un niveau moyen.
Il y a aussi la liste des secteurs à considérer. La CISA associe ce produit à l'Énergie, aux Systèmes de transport, à la Fabrication critique, aux Services et installations gouvernementaux, et aux Installations commerciales. Les logiciels de sécurité des personnes et de gestion des incidents sont généralement déployés précisément sur les sites où l'opérateur a le moins de tolérance aux interruptions et le moins de personnel dédié à la sécurité OT.
Le vrai problème : des identifiants qui survivent à la session
CWE-316 n'est pas un bug exotique. De nombreuses applications conservent des secrets en mémoire parce qu'elles en ont besoin pour s'authentifier en aval, et faire mieux exige une ingénierie délibérée : conserver les secrets dans une mémoire protégée, effacer le tampon immédiatement après usage, utiliser un jeton à courte durée de vie plutôt qu'un mot de passe, ne jamais mettre le mot de passe en cache.
Le problème structurel n'est pas qu'une application ait mal géré cela. C'est que l'identifiant était durable, réutilisable et rejouable ailleurs. Supprimez ces trois propriétés et un vidage mémoire ne retourne plus rien d'utile.
C'est le même argument qui traverse la plupart des défaillances d'identité OT, et nous l'avons abordé sous d'autres angles : pourquoi votre réseau OT n'a pas de couche d'identité, comment gérer les mots de passe sur des centaines d'équipements ICS, et MFA pour les comptes de service et les équipements industriels. Dans chaque cas, la solution durable est la même : cesser de distribuer des secrets qui valent la peine d'être volés.
Ce que font réellement les mitigations recommandées
Johnson Controls et la CISA listent six mesures. Elles sont toutes raisonnables, et il vaut la peine d'être précis sur ce que chacune apporte, car elles ne sont pas équivalentes.
| Mesure recommandée | Ce qu'elle prévient réellement | Limite |
|---|---|---|
| Mise à niveau vers v2.01.01 | Les identifiants cessent d'être stockés en clair | Nécessite une fenêtre de changement ; ne fait rien pour les identifiants déjà collectés |
| Restreindre l'accès local au personnel autorisé | Réduit l'ensemble des comptes pouvant accéder à la mémoire | Ne bloque pas un attaquant ayant compromis un compte autorisé |
| Protection des points de terminaison et surveillance des outils de vidage mémoire | Détecte les outils courants | Détection, pas prévention, et ne couvre pas les techniques de type « living-off-the-land » |
| Moindre privilège sur les systèmes hôtes | Élève le seuil pour obtenir les privilèges locaux nécessaires | L'avis note que des privilèges faibles sont déjà suffisants |
| Chiffrement intégral du disque et démarrage sécurisé | Bloque l'analyse hors ligne de la machine | Sans effet pendant l'exécution du système, qui est précisément le moment où la mémoire contient les secrets |
| Journalisation des tentatives d'accès local | Fournit la piste de preuves après coup | Purement rétrospectif |
Remarquez ce que cette liste a en commun : chaque élément, à l'exception de la mise à niveau, concerne la protection de l'hôte. Aucun ne traite ce qui rend l'identifiant précieux, à savoir qu'il fonctionne ailleurs.
La mesure manquante
Ajoutez un septième élément que la CISA ne liste pas, car il est architectural plutôt que spécifique au produit : rendre l'identifiant collecté inutilisable hors de l'hôte.
Concrètement, cela implique trois propriétés :
- Cloisonné. Le compte utilisé sur cette machine s'authentifie sur cette machine et nulle part ailleurs. Ce n'est pas un compte de domaine ayant accès au réseau de contrôle, et il n'est pas partagé avec l'historien, l'HMI, ou le poste de travail d'ingénierie.
- Courtisé. Toute connexion depuis cet hôte vers un autre système nécessite une nouvelle session établie via une passerelle qui effectue sa propre vérification d'identité. La possession d'un mot de passe ne suffit pas à en ouvrir une.
- Lié à un second facteur. La session exige un facteur que l'attaquant n'a pas obtenu depuis la mémoire. Un mot de passe et un jeton extraits d'un processus ne produisent pas à eux seuls une session authentifiée ailleurs.
Avec ces trois propriétés, le vidage mémoire réussit toujours, et il retourne toujours des identifiants en clair. Ils ne mènent simplement nulle part. Le rayon d'action passe de « tous les systèmes qui font confiance à ce mot de passe » à « cet hôte, que vous possédiez déjà ».
C'est le test honnête pour tout contrôle compensatoire sur cet avis : il n'empêche pas l'extraction, il supprime le bénéfice.
Le problème de propriété, encore
Il y a huit jours, la CISA a publié ICSA-26-204-01 pour Johnson Controls C-CURE 9000 et victor, un chemin d'exécution de code à distance CVSS 9.6 dans le contrôle d'accès aux bâtiments et la gestion vidéo. Même fournisseur, même catégorie de système, même situation sous-jacente : les logiciels de sécurité physique et de sécurité des personnes sont devenus une infrastructure IT ordinaire qui contrôle par ailleurs des portes, des caméras et des interventions incendie.
Et ils tendent à relever des installations plutôt que de l'IT ou de la sécurité OT. Ce fossé de propriété produit un ensemble prévisible de conditions : l'hôte se trouve sur un segment large parce que c'était le moyen le plus rapide de le faire fonctionner, il est corrigé selon le cycle du fournisseur plutôt qu'un cycle de sécurité, ses comptes de service sont pratiques plutôt que cloisonnés, et il est absent de l'inventaire des actifs que l'équipe de sécurité maintient réellement.
Deux avis en huit jours pour les systèmes de bâtiment d'un même fournisseur est une raison valable de vérifier si ces systèmes figurent dans votre inventaire. Si vous n'en êtes pas sûr, c'est là le constat, et la découverte passive vous le dira plus vite que de demander autour de vous.
Que faire cette semaine
- Déterminez si vous exploitez Simplex Incident Manager, et à quelle version. S'il ne figure pas dans votre inventaire des actifs, c'est un second constat.
- Planifiez la mise à niveau vers v2.01.01. Utilisez ce numéro de version, et non le v1.01.05 qui apparaît dans la liste des mitigations de l'avis.
- Recensez ce à quoi les comptes de cet hôte peuvent accéder. C'est le moment le plus utile des dix minutes de cet exercice. Si ces identifiants fonctionnent également contre un contrôleur, un historien ou le domaine, la vulnérabilité de sévérité moyenne ne l'est pas dans votre environnement.
- Cloisonnez ces comptes à l'hôte, et supprimez tout secret partagé ou réutilisé.
- Exigez une session courtisée et protégée par MFA pour tout ce qui se connecte depuis cet hôte vers un autre système.
- Restreignez et journalisez l'accès local à la machine, conformément aux recommandations du fournisseur.
- Vérifiez le reste du parc de systèmes de bâtiment pour le même schéma d'identifiants partagés et d'accessibilité étendue. L'avis concerne un produit ; le schéma, lui, est rarement limité à un seul.
La place de Trout Access Gate
Access Gate ne corrige pas CVE-2026-27875. Rien sur le réseau ne peut corriger du clair dans la mémoire propre d'une application, et tout fournisseur vous affirmant le contraire vous vend quelque chose.
Ce qu'il change, c'est la valeur de l'extraction. Access Gate se place dans le chemin de données devant les systèmes qui comptent et exige une session liée à une identité et protégée par MFA pour tout ce qui les atteint. Un identifiant extrait d'un hôte Windows ne produit pas de session, car la session est courtisée au niveau de la passerelle contre une identité distincte, et non accordée sur présentation d'un mot de passe. Chaque tentative est enregistrée, de sorte qu'une tentative de rejeu depuis un hôte inattendu génère une alerte plutôt qu'un succès silencieux.
Le périmètre est étroit et mérite d'être énoncé clairement : cela limite le mouvement latéral, cela ne prévient pas la divulgation. Appliquez la mise à niveau du fournisseur selon votre processus habituel. Consultez OT identity et secure OT remote access pour comprendre le fonctionnement du courtage.
Source : CISA ICS Advisory ICSA-26-232-01, publié le 20 août 2026, republiant l'avis de sécurité produit Johnson Controls JCI-PSA-2026-28. Vérifiez les versions concernées et les versions corrigées auprès de l'avis du fournisseur avant d'agir.