Cybersécurité

Stormshield Management Center : la console qui pilote vos pare-feu doit passer en 3.9.4

31 octobre 2026 Alexandre FAUVEL 4 min de lecture Actualité 2 vues

Le 30 octobre, Stormshield et le CERT-FR ont publié chacun un avis sur une faille de Stormshield Management Center (SMC), la console qui administre en un seul endroit tout un parc de pare-feu Stormshield Network Security. Ce n’est pas le pare-feu lui-même qui est touché, mais l’outil qui a la main sur tous les autres. Autant dire qu’on ne laisse pas traîner.

Ce qui est corrigé

Produit : Stormshield Management Center, versions 3.9.3 et antérieures.
Correctif : version 3.9.4.
Référence : CVE-2026-111497, avis éditeur STORM-2026-034, avis CERT-FR CERTFR-2026-AVI-1429.
Risque : exécution de code arbitraire à distance sur le serveur SMC, ou au minimum un plantage du service.
Gravité : élevée, score CVSS 3.1 de base de 8,8. Le vecteur indique un attaquant sur un réseau adjacent, sans authentification ni action d’un utilisateur.

D’après Stormshield, le problème ne vient pas du code de SMC à proprement parler mais du décodeur de compression Brotli intégré à Node.js, sur lequel repose le portail web d’administration. L’éditeur parle d’une écriture hors limites, surnommée « Node2Shell ». Une preuve de concept existe, selon le score temporel de l’avis.

Pourquoi je la classe en priorité

Une console de gestion centralisée, c’est la clé du trousseau. Celui qui prend la main sur SMC peut, en théorie, pousser des règles ou des configurations sur tous les pare-feu qu’elle administre. Dans les architectures que je croise côté sûreté et GTB, ces pare-feu sont justement ceux qui séparent le réseau des caméras, celui du contrôle d’accès ou celui des automates du reste de l’entreprise. Une segmentation bien pensée peut tomber d’un seul coup si son chef d’orchestre est compromis.

Le côté rassurant, c’est le vecteur « adjacent » : l’attaquant doit pouvoir joindre l’interface d’administration de SMC. Si celle-ci n’est accessible que depuis un réseau d’administration dédié, l’exposition est faible. Si elle traîne sur le réseau bureautique, ou pire sur Internet pour « dépanner à distance », c’est une autre histoire.

Ce que je ferais cette semaine

Vérifier la version de chaque SMC dont vous avez la charge, y compris chez les clients en contrat de maintenance.
Planifier le passage en 3.9.4, avec une sauvegarde de la configuration SMC avant l’opération. Si votre SMC tourne sur un hyperviseur, un instantané avant mise à jour ne coûte pas grand-chose.
En attendant, appliquer les contournements de Stormshield : réserver l’accès à l’interface d’administration aux seuls postes d’administration de confiance, ne jamais exposer SMC sur Internet, et, si un reverse proxy ou un WAF est placé devant, rejeter les requêtes portant l’en-tête Content-Encoding: br.
Relire les journaux de SMC et des pare-feu administrés depuis le 23 octobre, date de découverte indiquée par l’éditeur, à la recherche de modifications de configuration que personne n’a demandées.

Mon avis

Ce qui me plaît : l’avis Stormshield est clair, avec un vecteur CVSS complet, des contournements concrets et une version corrigée disponible le jour de la publication. C’est exactement ce qu’on attend d’un éditeur, et c’est aussi ce que le Cyber Resilience Act va bientôt exiger de tous les fabricants de produits connectés.

Ce qui me fait tiquer : ce n’est pas le premier avis CERT-FR sur SMC cette année (le CERTFR-2026-AVI-0816 du 29 juin visait déjà les versions antérieures à 3.9.2), et la cause est cette fois une bibliothèque embarquée. Cela rappelle que nos équipements de sécurité sont aussi des empilements de briques logicielles tierces (Node.js, OpenSSL, PHP…). Un pare-feu ou une console « de sécurité » se maintient comme n’importe quel serveur : inventaire des versions, veille sur les avis, fenêtre de mise à jour prévue au contrat. Si votre contrat de maintenance ne dit rien des correctifs de sécurité, c’est le moment d’en parler 🙂

Et surtout, l’interface d’administration de vos équipements de sécurité n’a rien à faire sur le même réseau que les postes utilisateurs. Un VLAN ou un réseau d’administration dédié, filtré, c’est la mesure qui transforme une faille « élevée » en non-événement.

Sources

Commentaires

Aucun commentaire pour l'instant : lancez la discussion.