La version courte
Le 13 août 2026, la CISA a publié ICSA-26-225-01 concernant AVEVA Enterprise SCADA et Enterprise SCADA HMI, le logiciel de supervision qui pilote les processus industriels dans le secteur de la fabrication critique. La vulnérabilité, CVE-2025-7639, est un problème de désérialisation de données non fiables : une charge utile sérialisée et forgée, envoyée au logiciel, peut être manipulée pour déclencher une exécution de code lors de la désérialisation. Score de base CVSS v3 : 7.1, complexité d'attaque élevée, aucune exploitation publique connue.
La condition préalable est la même que pour tout environnement OT. Un attaquant doit pouvoir atteindre le service SCADA ou HMI pour lui envoyer cette charge utile. C'est cette accessibilité que vous maîtrisez.
Ce que dit l'avis
Directement extrait de l'avis et de l'enregistrement CVE :
- Produits : AVEVA Enterprise SCADA et Enterprise SCADA HMI.
- La faille : CVE-2025-7639, désérialisation de données non fiables entraînant une exécution de code lors de la désérialisation.
- Versions affectées : Enterprise SCADA 2025 et antérieures jusqu'aux niveaux de service pack listés (2024 jusqu'à 2024 SP1 P01, 2023 jusqu'à 2023 SP1, 2022 jusqu'à 2022 SP2 P2, 2021 jusqu'à SP2 P5), ainsi qu'Enterprise SCADA HMI 2024 et 2023 et antérieures.
- Gravité : CVSS v3 7.1, complexité d'attaque élevée.
- Vecteur d'attaque : un attaquant capable de transmettre un objet sérialisé forgé au service. L'exécution de code est le résultat.
- Remédiation : AVEVA a publié des correctifs dans le bulletin de sécurité AVEVA-2026-005. La CISA ajoute ses recommandations habituelles pour les systèmes ICS : maintenir le système hors d'internet, l'isoler du réseau d'entreprise et faire transiter les accès distants par un chemin contrôlé.
La CISA n'a signalé aucune exploitation active. Considérez cela comme une exposition à résorber à votre rythme, non comme un incendie à éteindre.
Pourquoi cela se répète
SCADA et son HMI sont des applications hébergées sous Windows, avec des bases de données et des services réseau, et ils supervisent un processus physique qui ne peut tout simplement pas s'arrêter. C'est toute la tension de la sécurité OT en une phrase. Le logiciel présente les mêmes catégories de failles que n'importe quelle application d'entreprise, la désérialisation en fait partie, mais on ne peut pas le corriger un mardi. Un correctif attend une fenêtre de maintenance validée qui peut être à plusieurs semaines ou plusieurs mois, si le fournisseur le certifie pour votre version. Entre-temps, le processus continue de tourner et le service vulnérable continue d'écouter.
C'est dans cet écart entre « un correctif existe » et « nous pouvons l'appliquer en toute sécurité » que réside réellement le risque OT. Ce n'est pas une défaillance de l'équipe de production. C'est la nature même d'un logiciel qui contrôle des machines que l'on ne peut pas redémarrer à la demande.
Ce qui est réellement exploité
Réduisons le CVE à sa mécanique. Un attaquant capable d'ouvrir une connexion vers le service SCADA ou HMI lui envoie un objet sérialisé forgé, et lors de la désérialisation, cela se traduit par l'exécution de code sur l'hôte qui supervise le processus. La complexité d'attaque élevée relève le niveau d'exigence pour la charge utile, mais le premier ingrédient dont l'attaquant a besoin est simple : un accès réseau au service. Sur un segment OT à plat, la majeure partie de l'installation en dispose.
La vraie question à se poser sur votre réseau n'est donc pas seulement de savoir si AVEVA est corrigé. C'est de savoir ce qui peut actuellement ouvrir une connexion vers les serveurs SCADA et HMI, et si vous le remarqueriez si quelque chose le faisait. Sur un réseau de contrôle à plat, les réponses honnêtes sont généralement « presque tout » et « non ».
Le contrôle qui délimite réellement l'exposition
Vous fermez cette exposition sans attendre la fenêtre de maintenance en rendant le SCADA et le HMI accessibles uniquement via un point d'application.
L'Access Gate se place sur le chemin d'accès à ces serveurs et gère chaque session qui les atteint. Concrètement :
- Les serveurs cessent de répondre à des clients arbitraires sur le sous-réseau. Le seul chemin vers eux passe par une session que la passerelle a déjà authentifiée ; une faille de désérialisation perd ainsi ce dont elle a le plus besoin : un appelant non authentifié sur le réseau.
- Chaque session est associée à une personne ou un service nommé, limitée à la tâche concernée, avec le MFA géré au niveau de la passerelle, et enregistrée. Rien n'est modifié sur la pile AVEVA, donc rien n'a besoin d'être revalidé ou redémarré pour que cela tienne.
- Parce que l'Access Gate est un équipement de calcul sur le réseau, un point d'application sans agent placé devant l'actif plutôt qu'un service cloud, il applique l'identité et le moindre privilège au plus près du serveur SCADA sans rien installer dessus.
Cela ne remplace pas la mise à niveau. Appliquez les correctifs d'AVEVA dès que votre processus de gestion des changements le permet. Ce que le point d'application vous apporte, c'est du temps que le correctif ne peut pas offrir : l'exposition est fermée maintenant, elle reste fermée jusqu'au prochain avis SCADA que vous n'avez pas encore lu, et rien de tout cela ne dépend d'une fenêtre de maintenance. La mécanique est expliquée dans ce qu'est un proxy industriel, le volet segmentation est traité dans la sécurité des réseaux OT, et le volet accès est abordé dans l'accès distant sécurisé OT et fournisseurs pour les intégrateurs qui maintiennent ces systèmes.
Par où commencer cette semaine
- Localisez chaque instance d'Enterprise SCADA et SCADA HMI, et identifiez quels segments peuvent actuellement ouvrir une connexion vers elles.
- Vérifiez que les serveurs ne sont pas accessibles depuis le réseau d'entreprise ni depuis internet. Si c'est le cas, commencez par fermer cet accès.
- Appliquez les correctifs d'AVEVA selon votre processus de gestion des changements habituel et assurez-en le suivi, mais ne laissez pas la date du correctif être le seul rempart entre un client accessible par le réseau et l'exécution de code.
- Placez les serveurs SCADA et HMI derrière un point d'application afin que les accès soient liés à une identité, soumis au moindre privilège et enregistrés, y compris pour les intégrateurs qui les maintiennent.
- Effectuez le même contrôle sur le reste de la pile OT. Le prochain avis concernera un produit différent, et la réponse ne changera pas.
ICSA-26-225-01 est une bonne occasion de corriger quelque chose de plus large qu'un seul serveur. Le logiciel qui pilote le processus reste simplement un serveur sur votre réseau, et en OT, vous avez rarement la possibilité de corriger la faille selon votre propre calendrier. Vous définissez donc les conditions de ce qui peut l'atteindre.