Siemens confirme l’exploitation de la CVE-2026-110936 par un binaire signé livré avec une DLL pirate

15 octobre 2026. Siemens publie l’avis SSA-580366 pour la CVE-2026-110936, une faille de side-loading de DLL dans Siemens Software Center. 19 octobre 2026. L’éditeur confirme une exploitation active et publie des indicateurs de compromission : les attaquants diffusent une copie authentique et signée du programme — la version 3.5.8.7 — accompagnée de DLL malveillantes, hors des canaux officiels. 20 octobre 2026. La CISA ajoute la faille à son catalogue KEV, avec une échéance fédérale au 3 novembre. Le point qui compte : un binaire signé, l’un des piliers de la confiance logicielle, est devenu le véhicule de l’attaque.

Pour un RSSI ou un responsable de parc, ce n’est pas un bulletin Siemens de plus. C’est la démonstration concrète que la signature de code ne garantit plus rien quand l’attaquant choisit lui-même le programme signé qu’il distribue.

La faille : une recherche de DLL non contrôlée

La CVE-2026-110936 est classée CWE-427 (Uncontrolled Search Path Element). Concrètement, Software Center — l’application qui télécharge, installe, active et met à jour les logiciels Siemens achetés — charge des DLL depuis un chemin de recherche qu’elle ne contrôle pas. Un attaquant local et authentifié peut placer une DLL spécialement conçue dans un répertoire que le programme parcourt, et obtenir une exécution de code arbitraire avec les privilèges de l’application.

La notation illustre le malaise du CVSS face à ce type de faille. Siemens la cote 6,7 en CVSS v3.1 — un niveau « moyen » — mais 8,4 en CVSS v4.0, soit « élevé ». L’écart vient du vecteur : la faille elle-même est locale (AV:L) et exige des privilèges élevés (PR:H). Pourtant, dans la campagne réelle, ce n’est pas un administrateur qui déclenche la chaîne : c’est une victime trompée par un leurre ClickFix qui colle une commande dans la boîte Exécuter de Windows.

L’attaque : apporter son propre binaire signé

Le mode opératoire est la partie la plus instructive. Selon Siemens, les attaquants n’ont pas modifié le programme : « Le programme Siemens n’a pas été altéré. Le code malveillant se trouve dans les DLL fournies par les attaquants. » Ils ont pris une copie authentique de Software Center 3.5.8.7, dont la signature est valide, et l’ont placée à côté de leurs DLL malveillantes. Le binaire signé sert d’appât de confiance : les outils de sécurité le laissent passer, et le système le charge sans broncher.

Siemens rattache l’activité à la campagne Romulus, une plateforme multi-charges de livraison ClickFix documentée par Forescout Vedere Labs le 15 octobre. Forescout a identifié l’adresse 2.27.248[.]127 — celle que Siemens désigne comme le canal de distribution du paquet malveillant AllMyBasic.msi — parmi six serveurs Romulus. Huntress, qui a signalé la faille via Jose Oregon, avait déjà documenté fin septembre des attaques similaires abusant de programmes signés Canon et Stardock pour charger du code malveillant.

Le détail qui doit alerter : les attaquants distribuent un programme signé Siemens sur des machines qui n’ont jamais installé de logiciel Siemens. La présence de SiemensSoftwareCenter.exe dans les applications au démarrage ou le Planificateur de tâches d’un poste est donc un signal de compromission, pas une preuve de normalité.

Ce que la signature ne protège plus

La leçon dépasse Siemens. La signature de code garantit l’intégrité et l’origine d’un binaire — mais elle ne dit rien des fichiers voisins qu’il charge. Le side-loading de DLL exploite précisément cet angle mort : le programme est signé, mais la DLL qu’il va chercher dans son propre dossier ne l’est pas. C’est la même mécanique que la campagne DOUBLECUP et les abus de programmes signés Canon et Stardock : la signature est un jeton de confiance que l’attaquant loue, pas une défense qu’il contourne.

Conséquence pratique pour la détection : il ne faut pas chasser le binaire — il est authentique — mais le dossier et le comportement. Siemens recommande explicitement de « détecter sur le dossier et le comportement, pas sur l’empreinte du fichier Siemens ». Cherchez SiemensSoftwareCenter.exe exécuté depuis AppData\Local\Programs et lancé par msiexec, ainsi que des DLL inattendues à côté des exécutables Software Center hors du dossier d’installation par défaut.

La réponse : patch auto, indicateurs, chasse comportementale

La remédiation tient en un geste. Siemens affirme que la version 4.0.9.8 s’installe automatiquement au prochain démarrage de l’application. Vérifiez néanmoins les postes où Software Center tourne rarement : une application qui ne démarre jamais ne se met jamais à jour. La version corrigée est aussi téléchargeable sur le site officiel.

Les indicateurs de compromission publiés le 19 octobre sont à bloquer sur les pare-feu, proxies et résolveurs DNS, et à rechercher dans les journaux :

• IP 96.62.218[.]59 — hébergement de charge utile / commande et contrôle (actif) ;
• domaine wizardexpensive[.]com — hébergement de charge utile / C2 (actif) ;
• IP 2.27.248[.]127 — canal de distribution du paquet AllMyBasic.msi (inactif).

En cas de détection, Siemens préconise d’isoler le poste, d’arrêter le processus d’abord, puis de supprimer l’entrée de démarrage et la tâche planifiée, et de réinitialiser les mots de passe. Enfin, formez vos utilisateurs : un vrai contrôle « je ne suis pas un robot » ne demande jamais de coller une commande dans Win+R, la boîte Exécuter ou PowerShell.

Pourquoi maintenant : l’abus de binaires signés se banalise

La CVE-2026-110936 n’est pas un cas isolé : elle s’inscrit dans une tendance que Google Threat Intelligence Group chiffre à 141 vulnérabilités exploitées entre janvier et août 2026, contre 127 sur toute l’année 2025. Les abus de programmes signés — Canon, Stardock, désormais Siemens — suivent la même logique : emprunter la réputation d’un éditeur légitime pour faire passer une charge. Huntress résumait fin septembre la conclusion qui s’impose : « il est très probable que d’autres applications signées soient abusées de la même façon ».

La réponse n’est donc pas un correctif ponctuel, mais un changement d’hypothèse. Le modèle de confiance fondé sur la signature doit être complété par une chasse comportementale : qui lance quoi, depuis quel dossier, avec quels fichiers voisins. C’est ce que les équipes de détection doivent industrialiser — un EDR configuré pour surveiller les side-loading de DLL, pas seulement les signatures. Pour les agences fédérales américaines, la directive BOD 26-04 fixe l’échéance à 3 jours pour les actifs exposés et 14 jours pour les autres, à compter de l’inscription au KEV du 20 octobre.

Verdict

Si votre parc utilise des logiciels Siemens, forcez la version 4.0.9.8 dès maintenant — l’auto-mise à jour ne couvre pas les postes où Software Center ne démarre pas — et déployez les trois indicateurs dans vos outils de détection avant le 3 novembre. Si vous intégrez ou auditez des fournisseurs OT, demandez-leur aujourd’hui même s’ils exécutent Software Center et s’ils ont chassé les indicateurs : la faille est exploitée dans des campagnes ClickFix qui visent des machines sans logiciel Siemens installé, donc votre surface n’est pas limitée aux postes d’ingénierie. La vraie leçon de la CVE-2026-110936 est que la signature de code ne suffit plus : il faut désormais surveiller ce qu’un binaire signé charge, pas seulement ce qu’il est.

Références

• Siemens ProductCERT — SSA-580366, DLL Sideloading Vulnerability in Siemens Software Center (15 octobre 2026, V1.2 du 19 octobre)
• Siemens ProductCERT — Active Exploitation of CVE-2026-110936 in Siemens Software Center (19 octobre 2026)
• CISA — CISA Adds Six Known Exploited Vulnerabilities to Catalog (20 octobre 2026)
• Forescout Vedere Labs — ROMULUS: Analysis of a New Multi-Payload ClickFix Delivery Platform (15 octobre 2026)
• Huntress — Attackers Abuse ChatGPT Custom GPTs to Deliver RAT via ClickFix (28 septembre 2026)