Siemens SICAM 8 : firmware signature bypass et DoS (CERTFR-2026-AVI-0860)

Le CERT-FR a publié le 10 juillet 2026 l'avis CERTFR-2026-AVI-0860 qui répercute le bulletin Siemens SSA-229470 daté du 9 juillet 2026. L'avis couvre plusieurs vulnérabilités des équipements SICAM 8 — famille de RTU/gateways Siemens déployée dans la conduite du réseau électrique et industriel. Les deux failles à traiter en priorité sont un contournement de vérification de signature firmware et un déni de service via l'interface de debug HTTP. Ni palier public d'exploitation en cours, ni PoC public à ce jour.

Produits concernés

D'après l'avis Siemens, deux composants firmware sont vulnérables :

• CPCI85 Central Processing / Communication, embarqué dans les équipements SICAM A8000 CP-8031 et CP-8050, et dans SICAM EGS.
• SICORE Base system, embarqué dans les équipements SICAM A8000 CP-8010 et CP-8012, et dans SICAM S8000.

Ce sont les unités centrales des SICAM 8 : elles hébergent la logique de télé-conduite, les protocoles industriels (IEC 60870-5-104, DNP3, IEC 61850), l'interface web d'administration et le pipeline de mise à jour firmware. Elles sont typiquement déployées sur les postes source, les postes de distribution HTA/BT et dans des installations industrielles process — donc dans le périmètre NIS2 opérateur essentiel pour la plupart des exploitants du domaine énergie en France.

CVE-2026-54799 — bypass de signature du firmware

Le plus critique du lot. Le mécanisme de mise à jour firmware des équipements affectés contient une faille dans la procédure de validation de la signature du paquet firmware. Un attaquant qui a accès au canal de mise à jour peut soumettre un firmware modifié qui passera la vérification et sera installé. La conséquence est une exécution de code persistante au niveau firmware — c'est-à-dire une compromission dont on ne se débarrasse pas par un simple redémarrage ni par une réinstallation du firmware légitime, puisque l'attaquant contrôle le composant qui décide de ce qui est légitime.

Le pré-requis « accès au canal de mise à jour » couvre plusieurs scénarios d'exposition réels :

• interface d'administration web accessible depuis un réseau d'ingénierie mal segmenté ;
• serveur SCADA / poste d'ingénierie compromis en amont, utilisé comme relais légitime pour pousser le firmware forgé ;
• accès physique ponctuel sur un poste, y compris pendant une opération de maintenance sous-traitée.

CVE-2026-54798 — DoS via l'interface de debug HTTP

La seconde faille est un endpoint HTTP de debugging laissé accessible, qui permet à un attaquant authentifié de faire crasher le processus web de l'équipement. La granularité est un déni de service sur la couche web d'administration ; les fonctions de conduite temps-réel (le rôle premier du SICAM) restent en principe assurées, mais l'exploitant perd la visibilité et la capacité de reconfiguration à chaud tant que le processus web est down.

Le CVSS n'est pas encore publié à date sur NVD (CVE-2026-54798, CVE-2026-54799), mais la sévérité opérationnelle est portée par 54799 : la persistance firmware transforme le SICAM en tête de pont durable sur le réseau OT.

Autres points du bulletin

Le bulletin Siemens signale également que la configuration livrée par défaut désactive tous les mécanismes de sécurité OPC UA sur ces équipements. Ce n'est pas une CVE au sens strict — c'est un choix de configuration — mais un défenseur qui a intégré ces équipements en s'appuyant sur la configuration par défaut pour OPC UA n'a aucune authentification ni chiffrement sur la couche métier.

Statut d'exploitation

• Aucune exploitation active documentée à la date de l'avis. Ni Siemens ProductCERT, ni le CERT-FR, ni CISA n'attribuent d'activité en cours à ces CVE.
• Pas de PoC public à ce jour pour 54799 ; le vecteur DoS de 54798 est décrit en clair dans l'avis, ce qui suffit à reproduire.
• Pas de listing CISA KEV à la publication.

Que faire

1. Appliquer les correctifs firmware Siemens via l'outillage prévu (SICAM WEB, SICAM device manager, SIMATIC Manager selon la ligne). Les paquets firmware corrigés sont référencés dans le bulletin SSA-229470 ; les paliers exacts par ligne (CP-8031/8050, CP-8010/8012, EGS, S8000) sont à récupérer sur le portail industry.siemens.com contre authentification client.
2. Restreindre l'accès au canal de mise à jour firmware. Tant que la version vulnérable tourne, la parade opérationnelle est la segmentation : le port web / le service de mise à jour ne doivent être atteignables que depuis le poste d'ingénierie strictement identifié, jamais depuis un LAN bureautique ou un réseau tiers de maintenance à distance.
3. Désactiver l'interface de debug HTTP si votre exploitation ne l'utilise pas. Sur les lignes Siemens SICAM, cette interface est d'usage principalement pendant la mise en service et les investigations de terrain — la laisser active en production sur les équipements exposés est la conjonction qui rend 54798 exploitable.
4. Reconfigurer OPC UA en mode sécurisé partout où le protocole est utilisé effectivement : mode Sign ou SignAndEncrypt, politique de sécurité Basic256Sha256 minimum, certificats émis par une PKI interne et non par les certificats auto-signés par défaut. La documentation Siemens détaille la procédure par ligne.
5. Périmètre NIS2 / opérateur d'importance vitale : consigner l'avis CERTFR-2026-AVI-0860 dans le suivi des mises à niveau réglementaires. Les entités OIV du secteur énergie qui exploitent des postes équipés en SICAM 8 sont directement concernées par le délai de traitement.
6. Vérifier l'intégrité du firmware installé après mise à niveau. Puisque le mode d'exploitation de 54799 est précisément un firmware forgé accepté avant patch, tout équipement dont le canal de mise à jour a pu être atteint avant l'application du correctif doit être considéré comme compromis jusqu'à vérification d'un hash / d'une signature de firmware faite par un chemin de confiance indépendant.

Contexte

C'est le deuxième bulletin Siemens SICAM 8 depuis avril 2026. Le précédent — SSA-246443, répercuté par CISA en ICSA-26-092-01 — traitait deux CVE (CVE-2026-27663, CVE-2026-27664) de type DoS et out-of-bounds write, corrigées par le palier V26.10. Le bulletin 229470 vise le même socle de produits mais introduit une catégorie qualitativement pire : la signature firmware. Un DoS se répare par un redémarrage ; un firmware forgé installé persiste et se resigne.

Le point structurel : la surface d'attaque des RTU industrielles n'est plus seulement les protocoles bus historiques (Modbus, DNP3) — c'est l'ensemble interface web d'administration + pipeline de mise à jour firmware + OPC UA par-dessus. Cette pile web/moderne, plaquée sur des équipements dont la durée de vie déployée dépasse dix ans, produit précisément le profil de vulnérabilité qu'on retrouve dans le bulletin 229470. Les exploitants OT qui n'ont pas encore intégré un monitoring d'intégrité firmware par chemin de confiance externe (attestation périodique de hash depuis un système hors-bande) sont mal placés pour détecter une exploitation post-compromission.