En bref
Lors de sa mise à jour d'août, la CISA a publié ICSA-26-204-01 (Update A) pour Johnson Controls C-CURE 9000 et le serveur d'application victor, les logiciels qui font tourner le contrôle d'accès des bâtiments et la gestion vidéo dans les sites commerciaux, les campus et les sites gouvernementaux. La vulnérabilité phare, CVE-2026-21655, est une voie de désérialisation non sécurisée et de server-side request forgery qui mène à l'exécution de code à distance, avec un score de base CVSS v3 de 9.6. Un second problème, CVE-2026-34496, affecte victor Web.
Il y a ici une ironie savoureuse sur laquelle il vaut la peine de s'arrêter une seconde. Le système visé par l'avis est celui qui décide qui passe la porte et ce que les caméras enregistrent. Et la façon de le protéger, au-delà du correctif, consiste à placer du contrôle d'accès devant votre serveur de contrôle d'accès.
La seule ligne qui décide du risque est celle de la CISA elle-même : une exploitation réussie pourrait permettre à un attaquant disposant d'un accès réseau d'obtenir l'exécution de code à distance. L'accès réseau, voilà toute la condition préalable. Et c'est cette part-là qui vous appartient.
Ce que dit l'avis
Directement issu de l'avis et des fiches CVE :
- Produits : Johnson Controls C-CURE 9000 (contrôle d'accès) et victor (gestion vidéo), y compris le victor Application Server et victor Web.
- Les failles : CVE-2026-21655, une voie de désérialisation non sécurisée et de SSRF menant à l'exécution de code à distance, plus CVE-2026-34496 dans victor Web.
- Versions concernées : C-CURE 9000 jusqu'à v3.10.1, victor Application Server jusqu'à v4.10, victor jusqu'à v7.0 (CVE-2026-21655), et victor Web jusqu'à v7.1 (CVE-2026-34496).
- Gravité : CVSS v3 jusqu'à 9.6.
- Comment on l'atteint : un attaquant capable d'ouvrir une connexion réseau vers le serveur. La RCE en découle.
- Remédiation : Johnson Controls a publié des versions corrigées, par exemple C-CURE 9000 v3.20 ou ultérieure et victor Application Server v4.20 ou ultérieure. La CISA ajoute ses recommandations ICS habituelles : garder le système hors de l'internet public, l'isoler du réseau bureautique, et faire passer l'accès distant par un chemin contrôlé.
La CISA n'a pas signalé d'exploitation dans la nature. À lire comme une exposition à fermer, pas comme un incendie à éteindre.
Pourquoi cela se répète
Les systèmes de sécurité physique sont discrètement devenus des serveurs informatiques qui, accessoirement, font tourner des portes et des caméras. C-CURE 9000 et victor sont des applications hébergées sous Windows, avec des bases de données, des interfaces web et des services réseau, posées sur un réseau d'usine ou de campus, souvent accessibles depuis une plus grande partie de ce réseau que quiconque ne l'avait prévu. Elles portent les mêmes classes de vulnérabilités que n'importe quelle application d'entreprise, désérialisation, SSRF, problèmes de privilèges, et elles sont corrigées au rythme de l'éditeur, pas au vôtre.
Le hic tient à ceux qui, en général, en ont la charge. Le contrôle d'accès et la vidéosurveillance sont fréquemment gérés par les services généraux ou une équipe de sécurité physique, pas par le groupe de sécurité OT ou IT, et la machine atterrit sur un segment plat, largement exposé, parce que c'était le moyen le plus rapide de faire fonctionner les lecteurs de badge et les caméras. Alors, quand une 9.6 tombe, la surface exposée est en général bien plus large qu'elle n'a besoin de l'être.
Ce qui se fait réellement exploiter
Sous la liste des CVE, le risque est limpide. Un attaquant atteint un serveur qui n'aurait jamais dû être largement accessible, et lui envoie une requête forgée. Pour une voie de désérialisation vers RCE, c'est quasiment toute l'attaque. Pas de badge volé, pas de chaîne de zero-day. La portée réseau et une charge utile malformée, et voilà du code qui s'exécute sur l'hôte qui gouverne les portes et la vidéo.
La question qui vaut la peine d'être posée sur votre propre réseau n'est donc pas seulement de savoir si C-CURE 9000 est corrigé. C'est de savoir ce qui peut aujourd'hui ouvrir une connexion vers les serveurs de contrôle d'accès et de vidéo, et si vous le verriez si quelque chose le faisait. Sur un réseau de services généraux à plat, la réponse est en général tout ce qui se trouve sur le subnet, et non.
Le contrôle qui le borne vraiment
Vous fermez cela sans attendre le correctif en rendant les serveurs atteignables uniquement à travers un point d'application.
Un proxy industriel se place sur le chemin d'accès aux serveurs C-CURE 9000 et victor et arbitre chaque session qui les atteint. Concrètement :
- Les serveurs cessent de répondre aux clients arbitraires du subnet. Le seul chemin vers eux est une session que le proxy a déjà authentifiée, si bien qu'une RCE atteignable par le réseau perd ce dont elle a le plus besoin, un appelant non authentifié sur le réseau.
- Chaque session est rattachée à une personne ou un service nommé, cantonnée à la tâche, avec la MFA gérée au niveau du proxy. Rien n'est modifié sur la pile Johnson Controls, donc rien n'a à être revalidé ou redémarré pour que cela tienne.
- Chaque session qui touche les serveurs est journalisée, de sorte que « le verrions-nous » a enfin une réponse.
- Il n'installe rien sur les serveurs. C'est un conduit d'industrial DMZ réduit à la zone de sécurité physique, et le côté accès relève de l'accès distant OT et fournisseur sécurisé pour les intégrateurs qui maintiennent ces systèmes.
Cela ne remplace pas la mise à jour. Appliquez les versions corrigées de Johnson Controls quand votre processus de changement le permet. Ce que le point d'application vous apporte, c'est le temps que le correctif ne peut pas offrir : l'exposition est fermée maintenant, elle le reste jusqu'à la prochaine CVE de sécurité physique dont vous n'avez pas encore entendu parler, et rien de tout cela ne dépend de la fenêtre de maintenance d'une équipe de services généraux. Les mécanismes sont détaillés dans ce qu'est un proxy industriel, et le volet audit dans la microsegmentation OT avec intégration SIEM.
Par où commencer cette semaine
- Localisez chaque serveur C-CURE 9000 et victor, et notez quels segments peuvent aujourd'hui ouvrir une connexion vers eux. Les systèmes gérés par les services généraux sont faciles à oublier.
- Confirmez que les serveurs ne sont pas accessibles depuis le réseau bureautique ou l'internet. S'ils le sont, fermez cela en premier.
- Appliquez la mise à jour de Johnson Controls selon votre processus de changement habituel et suivez-la, mais ne laissez pas la date du correctif être la seule chose entre un client accessible par le réseau et une RCE.
- Déplacez les serveurs de contrôle d'accès et de vidéo derrière un point d'application, pour que l'accès soit lié à une identité, en moindre privilège, et enregistré, y compris pour les intégrateurs qui les entretiennent.
- Menez le même contrôle sur le reste de la pile d'automatisation des bâtiments. Le prochain avis nommera un autre produit de sécurité physique, et la réponse ne changera pas.
ICSA-26-204-01 est une bonne occasion de corriger quelque chose de plus large qu'un seul serveur. Le système qui commande les portes reste juste un serveur sur votre réseau, et en OT vous avez rarement le loisir de corriger la faille selon votre propre calendrier. Alors vous fixez plutôt les conditions de ce qui peut l'atteindre.