Stormshield Network Security : le CERT-FR signale une faille de confidentialité (CVE-2026-31790)

Le pare-feu censé protéger le réseau devient lui-même un point d'exposition. Le 10 juin 2026, le CERT-FR a publié l'avis CERTFR-2026-AVI-0723 documentant une vulnérabilité dans Stormshield Network Security (SNS) — l'appliance de filtrage de l'éditeur français — qui permet à un attaquant de porter atteinte à la confidentialité des données. Pour les organisations qui ont placé un SNS en frontière de leur système d'information, l'avis n'est pas une alerte technique de plus : c'est un signal direct vers l'article 32 du RGPD.

Ce qui s'est passé

L'avis du CERT-FR, daté du 10 juin 2026, s'appuie sur le bulletin de sécurité Stormshield 2026-011 publié la veille par l'éditeur. Il référence une vulnérabilité unique, CVE-2026-31790, dont le risque identifié est une atteinte à la confidentialité des données.

Les systèmes affectés sont les versions 5.x de SNS antérieures à 5.0.6. Le correctif consiste à migrer vers la version 5.0.6, disponible auprès de l'éditeur. Stormshield Network Security est la gamme de pare-feu / UTM la plus répandue de l'éditeur, déployée dans de nombreuses administrations, collectivités, hôpitaux et entreprises françaises soucieuses de souveraineté — ce qui élargit d'autant la surface concernée par cet avis.

Ce n'est d'ailleurs pas le premier passage de la marque dans la veille du CERT-FR : en avril 2026, c'était la console d'administration qui était visée, avec dix vulnérabilités documentées dans Stormshield Management Center, dont de l'exécution de code à distance. Deux avis sur le même écosystème en moins de deux mois : un produit de sécurité, comme tout autre logiciel, vit avec sa propre dette de vulnérabilités.

Pourquoi c'est important

Un pare-feu n'est pas un équipement périphérique anodin : il voit transiter le trafic, héberge des règles de filtrage, des journaux et parfois des secrets d'authentification. Une atteinte à sa confidentialité peut donc exposer des informations qui, directement ou indirectement, se rattachent à des personnes physiques — adresses IP, identifiants, flux applicatifs.

C'est précisément ce que vise l'article 32 du RGPD, qui impose au responsable de traitement et à son sous-traitant de mettre en œuvre des mesures techniques « appropriées » et tenant compte de l'état de l'art. Or l'état de l'art, en 2026, inclut sans ambiguïté l'application diligente des correctifs de sécurité signalés par l'ANSSI. Laisser un SNS en version vulnérable après publication de l'avis, c'est s'écarter de cet état de l'art — et fragiliser sa position en cas de contrôle ou d'incident.

Si la vulnérabilité venait à être exploitée et conduisait à une fuite de données personnelles, l'organisation basculerait dans le régime de la violation de données personnelles : notification à la CNIL sous 72 heures (article 33) et, selon la gravité, communication aux personnes concernées (article 34). Pour les entités régulées par NIS 2, s'ajoute l'obligation de signalement à l'ANSSI dans des délais resserrés. La mécanique est désormais bien rodée — on la retrouve à l'identique sur des avis voisins, qu'il s'agisse des 15 failles SAP ou des vulnérabilités Ivanti traitées récemment.

Ce que ça change pour les organisations

Pour un DPO ou un RSSI, l'avis CERTFR-2026-AVI-0723 appelle une séquence simple mais documentée :

D'abord, inventorier : recenser tous les boîtiers SNS 5.x en service et identifier ceux en version antérieure à 5.0.6. Ensuite, patcher : planifier la migration vers 5.0.6 en priorisant les équipements exposés ou en frontière de réseau. En parallèle, tracer la décision : consigner la date de prise de connaissance de l'avis, l'analyse de risque et la fenêtre de correction retenue — c'est cette traçabilité qui matérialise la conformité à l'article 32 en cas de question de la CNIL. Enfin, surveiller : analyser les journaux du pare-feu pour détecter une éventuelle exploitation antérieure au correctif, et vérifier, lorsque l'équipement est administré par un prestataire, que le contrat de sous-traitance (article 28) couvre bien la gestion des vulnérabilités et les délais d'intervention.

Ce que Leto pense de cette décision

Le réflexe spontané est de considérer qu'un équipement de sécurité « se met à jour tout seul » ou relève uniquement de l'équipe technique. C'est une erreur de gouvernance. Un avis CERT-FR sur un pare-feu est aussi un sujet de conformité : il crée une obligation de moyens documentée au titre de l'article 32, et il fixe le point de départ du compteur en cas d'incident. Notre conviction est simple — la veille de vulnérabilités ne doit pas rester confinée au RSSI : elle doit alimenter une décision tracée, partagée avec le DPO, et reliée à la cartographie des traitements. La bonne nouvelle, ici, c'est qu'un correctif existe et que le risque reste circonscrit à la confidentialité. Encore faut-il l'appliquer vite, et l'écrire.

Sources : CERT-FR — Avis CERTFR-2026-AVI-0723 · Bulletin de sécurité Stormshield 2026-011 · CVE-2026-31790