Silverlight a officiellement atteint sa fin de support le 12 octobre 2021. Pourtant, en 2026, nous continuons de trouver le runtime installé sur des postes de travail en production, souvent sans que les équipes IT en aient conscience. Ce décalage entre la perception (« Silverlight a disparu ») et la réalité terrain (le composant tourne encore sur des machines Windows LTSC) crée une surface d’attaque silencieuse que les politiques de patch management classiques ne couvrent plus.
Silverlight sur Windows LTSC : la zone grise du patching
Sur les systèmes Windows LTSC encore supportés par Microsoft, Silverlight peut continuer à s’exécuter même si le plug-in n’est plus maintenu. L’OS reçoit ses mises à jour de sécurité normalement, mais la couche applicative Silverlight reste figée à sa dernière version publiée, sans correctif futur.
Cette configuration génère un faux sentiment de sécurité. L’administrateur voit un système à jour dans WSUS ou SCCM, alors qu’un composant non patché persiste en local. Les scanners de vulnérabilités classiques ne remontent pas toujours ce type de dette technique, car Silverlight n’apparaît plus dans les flux de mises à jour Microsoft.
Nous recommandons d’intégrer une requête spécifique dans vos outils d’inventaire logiciel pour détecter la présence de sllauncher.exe ou des DLL associées sur l’ensemble du parc. Un simple script PowerShell ciblant les répertoires d’installation par défaut suffit à cartographier l’exposition réelle.
CVE anciennes et exploitation active : le vrai risque Silverlight en 2026
Une vulnérabilité datant de 2013 ou 2016 reste opérationnellement dangereuse en 2026 dès lors que le composant n’est plus patché. Les bulletins de sécurité récents confirment cette réalité : des CVE vieilles de plus de dix ans sont ajoutées au catalogue KEV (Known Exploited Vulnerabilities) de la CISA sur la base d’exploitations constatées dans la nature.
Le cas de MS15-034 (CVE-2015-1635), une vulnérabilité HTTP.sys avec un score CVSS de 10, illustre le mécanisme. Cette faille de 2015 est encore régulièrement trouvée lors de scans sur des réseaux d’organisations en 2026. Le parallèle avec Silverlight est direct : les CVE associées au runtime (comme CVE-2013-0074) suivent la même logique d’exploitation tardive.
Pourquoi les attaquants ciblent les composants obsolètes
L’effort d’exploitation est minimal. Les PoC (proof of concept) sont publics depuis des années, les signatures IDS sont souvent désactivées car jugées « trop anciennes », et le composant vulnérable ne figure plus dans le périmètre de surveillance actif. C’est précisément cette combinaison qui rend l’attaque rentable.
Un attaquant qui obtient une exécution de code via un composant Silverlight non patché se retrouve sur un poste Windows LTSC potentiellement connecté à un réseau industriel ou à un système d’information critique. Le pivot latéral depuis un composant oublié reste l’un des vecteurs les plus documentés dans les retours d’incident.
Inventaire et remédiation Silverlight : méthodologie de désinstallation
La suppression de Silverlight ne se limite pas à un « Ajout/Suppression de programmes ». Plusieurs points méritent une attention particulière lors de la remédiation sur un parc d’entreprise.
- Identifier les applications métiers qui dépendent encore du runtime. Certains logiciels de gestion, historiquement développés en XAML/Silverlight, utilisent le composant en mode hors navigateur (out-of-browser). La désinstallation du runtime casse ces applications sans avertissement préalable.
- Vérifier les stratégies de groupe (GPO) qui autorisent encore l’exécution de plug-ins obsolètes dans Internet Explorer 11, lui-même en fin de support. Une GPO mal configurée peut réinstaller silencieusement le composant lors du déploiement d’un poste.
- Documenter les exceptions. Si une application critique impose le maintien temporaire de Silverlight, isoler le poste concerné dans un VLAN dédié avec des règles de filtrage réseau strictes et un monitoring renforcé des flux sortants.
- Planifier la migration applicative. Les alternatives techniques (Blazor, frameworks web standards en HTML5/JavaScript) couvrent aujourd’hui l’ensemble des cas d’usage autrefois adressés par Silverlight, y compris le streaming DRM et les interfaces riches.
Durcissement réseau pour les postes encore exposés à Silverlight
Quand la désinstallation immédiate est impossible (contrainte métier, application sans alternative), le durcissement périmétrique devient la seule option viable. Nous observons que les organisations qui gèrent cette dette technique efficacement appliquent systématiquement trois mesures.
- Désactiver le plug-in Silverlight dans tous les navigateurs via GPO, même si le runtime reste installé pour une application out-of-browser. Cela supprime le vecteur d’attaque web (drive-by download, exploitation via page piégée).
- Restreindre les communications réseau du poste aux seuls flux nécessaires à l’application métier. Tout trafic HTTP/HTTPS non identifié doit être bloqué en sortie.
- Activer la journalisation Sysmon sur les postes concernés, avec des règles ciblant les processus enfants de sllauncher.exe et les chargements de DLL inhabituels dans le répertoire Silverlight.
Supervision et détection des comportements anormaux
Un composant sans support éditeur ne génère plus d’alertes dans les flux de threat intelligence classiques. Il faut compenser ce silence par une détection comportementale. Les règles YARA ou Sigma ciblant les binaires Silverlight connus permettent de remonter toute exécution inattendue dans un SIEM.
Toute exécution de Silverlight en dehors du périmètre documenté doit déclencher une alerte de sécurité. Ce principe simple transforme un composant obsolète en indicateur de compromission potentiel.
Migration applicative : sortir définitivement de Silverlight
La migration reste la seule réponse durable. Les applications développées en Silverlight reposent sur du code XAML et du C# côté client, ce qui facilite la transition vers Blazor WebAssembly, le framework Microsoft qui reprend une partie de la pile technologique .NET dans le navigateur.
Pour les applications de type formulaire ou workflow (le cas d’usage le plus fréquent des déploiements Silverlight résiduels), la réécriture en HTML5 avec un framework JavaScript moderne représente souvent un effort modéré. Le code métier en C# peut être conservé côté serveur via une API REST, seule la couche de présentation nécessite une refonte.
Les organisations qui repoussent cette migration accumulent une dette de sécurité dont le coût croît chaque trimestre. Chaque CVE ajoutée au catalogue KEV sur un composant Microsoft ancien rappelle que le risque lié aux logiciels obsolètes ne diminue pas avec le temps, il augmente à mesure que les défenses périphériques s’érodent.
