Une vulnérabilité récemment divulguée de Windows PowerShell permet à des attaquants d’exécuter du code malveillant sur les systèmes concernés, exposant davantage les organisations dans les environnements clients et serveurs Windows.
La vulnérabilité « … permet à un attaquant non autorisé d’exécuter du code localement », a déclaré Microsoft dans son avis.
Des experts du secteur ont également fait part de leur analyse.
« Cela est particulièrement préoccupant pour les scripts qui reposent sur une analyse HTML complète, laquelle peut désormais déclencher des avertissements de sécurité ou échouer complètement », a déclaré Hüseyin Can Yüceel, Security Research lead chez Picus Security.
Olivier Bilodeau, Principal Cybersecurity Researcher chez Flare, a ajouté : « Nous devons suivre cette vulnérabilité de près. Microsoft n’a pas l’habitude d’introduire des changements susceptibles de casser les scripts existants de ses clients, comme le fait ce correctif. Pour l’instant, les informations publiques sont rares, mais on peut imaginer que des pages web spécialement conçues puissent provoquer l’exécution de code côté client lorsqu’elles sont appelées avec Invoke-WebRequest ».
Il a également expliqué : « Le fait que les informations publiques soient disponibles et que la complexité de l’attaque soit faible signifie que cette vulnérabilité attirera l’attention des acteurs malveillants. »
Comprendre les risques liés à PowerShell
CVE-2025-54100 affiche un score CVSS de 7,8 et peut permettre l’exécution de code arbitraire dans certaines conditions.
Dans ce cas, PowerShell ne parvient pas à nettoyer correctement certaines séquences d’entrée, ce qui permet à un attaquant d’intégrer des caractères ou des charges malveillantes qui modifient la structure prévue de la commande.
Une fois traitées, ces commandes spécialement conçues peuvent sortir des règles normales d’analyse et déclencher des chemins d’exécution inattendus, donnant de fait à l’attaquant la possibilité d’exécuter du code arbitraire dans le contexte de l’utilisateur concerné.
Bien que Microsoft estime actuellement faible la probabilité d’exploitation, cette évaluation reflète principalement la nécessité de disposer d’un accès local et d’une interaction de l’utilisateur, par exemple en incitant une victime à exécuter un script malveillant, à ouvrir un fichier altéré ou à lancer une commande spécialement conçue.
Toutefois, la divulgation publique de la vulnérabilité change la donne : les acteurs malveillants ont souvent recours à l’ingénierie sociale pour contourner l’exigence d’un accès local, en particulier dans les environnements où PowerShell est largement utilisé pour les tâches d’administration ou automatisées.
Un autre facteur qui accroît le risque est l’impact étendu de la vulnérabilité sur presque toutes les versions de Windows prises en charge, notamment Windows 10, Windows 11 et les éditions de Windows Server de 2008 à 2025.
Comme PowerShell sous-tend l’administration des systèmes, les workflows DevOps et les outils de sécurité, les failles de sa logique de traitement des commandes peuvent aller jusqu’à permettre des mouvements latéraux ou une élévation de privilèges dans les environnements vulnérables.
La divulgation publique de cette faille, conjuguée à l’utilisation généralisée de PowerShell dans les environnements d’entreprise, rend l’application rapide des correctifs importante.
Même si l’exploitation nécessite des conditions particulières, les attaquants combinent régulièrement plusieurs faiblesses mineures pour obtenir un impact plus large, ce qui renforce la nécessité d’une remédiation proactive.
Comment renforcer la sécurité de PowerShell
Les organisations peuvent réduire les risques liés à PowerShell en adoptant une approche à plusieurs niveaux qui renforce la configuration, durcit les contrôles d’accès et améliore la surveillance.
- Appliquer les dernières mises à jour de sécurité de Microsoft pour toutes les versions concernées de Windows et redémarrer les systèmes si nécessaire.
- Activer les protections avancées de PowerShell, notamment la journalisation des blocs de script, des modules et des transcriptions, ainsi que les autres paramètres de sécurité recommandés.
- Imposer le principe du moindre privilège pour PowerShell, restreindre les comptes administratifs et désactiver les anciennes versions de PowerShell lorsque cela est possible.
- Utiliser des solutions de contrôle des applications telles qu’AppLocker ou Windows Defender Application Control afin de garantir que seuls les scripts approuvés puissent être exécutés.
- Surveiller les activités PowerShell inhabituelles, notamment les commandes encodées, les lancements inattendus de scripts et les comportements suspects d’accès distant.
- Renforcer les stratégies d’exécution de PowerShell et envisager l’utilisation du mode de langage restreint ou de règles d’exécution fondées sur les signatures.
- Former les utilisateurs et les administrateurs à ne pas exécuter de commandes ou de fichiers non fiables et compléter cette mesure par EDR ou des règles de réduction de la surface d’attaque capables de détecter les usages malveillants de PowerShell.
Ensemble, ces mesures aident les organisations à renforcer leur niveau de sécurité PowerShell en combinant mises à jour, durcissement de la configuration et surveillance afin de réduire les abus et d’améliorer la détection des activités inhabituelles.
Le rôle de PowerShell dans les risques auxquels sont confrontées les organisations
La divulgation de CVE-2025-54100 met en évidence les difficultés concrètes auxquelles les organisations sont confrontées pour sécuriser des outils d’administration largement utilisés comme PowerShell.
Comme PowerShell prend en charge l’automatisation et la gestion des systèmes dans de nombreux environnements, les faiblesses de ses fonctionnalités fondamentales peuvent introduire des risques auxquels il est important de remédier, même si leur exploitation est improbable.
À mesure que les organisations développent leurs workflows d’automatisation et de script, le maintien de mises à jour rapides et de pratiques de configuration rigoureuses contribue à éviter que des problèmes isolés n’aient des répercussions opérationnelles plus larges.
tels que les principes de confiance zéro.