PowerShell 5.1 : Invoke-WebRequest : empêche l’exécution de scripts à partir du contenu web

S’applique à
Win 10 Ent LTSB 2016 Win 10 Ent LTSC 2019 Windows 10 IoT Enterprise LTSC 2021 Windows 10, version 22H2, all editions Windows 11 Home and Pro, version 22H2 Windows 11 Enterprise Multi-Session, version 22H2 Windows 11 Enterprise and Education, version 22H2 Windows 11 IoT Enterprise, version 22H2 Windows 11 SE, version 23H2 Windows 11 Home and Pro, version 23H2 Windows 11 Enterprise and Education, version 23H2 Windows 11 Enterprise Multi-Session, version 23H2 Windows 11 version 24H2, all editions Windows 11 version 25H2, all editions Windows Server 2008 Premium Assurance Windows Server 2008 R2 Premium Assurance Windows Server 2012 ESU Windows Server 2012 R2 ESU Windows Server 2016 Windows Server 2019 Windows Server 2022 Windows Server 2025

Remarque

  • Date de publication d’origine : 9 décembre 2025
  • ID de la Base de connaissances : 5074596

Remarque

Cet article décrit une modification qui affecte principalement les environnements d’entreprise ou gérés par le service informatique dans lesquels les scripts PowerShell sont utilisés pour l’automatisation et la récupération de contenu web. People qui utilisent des appareils dans des contextes personnels ou domestiques n’ont généralement pas besoin de prendre de mesures, car ces scénarios sont rares en dehors des environnements gérés par le service informatique.

Journal des modifications
Modifier la date Modifier la description
20 décembre 2025
  • Ajout de « l’avertissement de sécurité » à la section « Résumé ».
  • Ajout du paragraphe suivant à la section « Résumé » pour plus de clarté :

    La commande Invoke-WebRequest de PowerShell envoie une requête HTTP ou HTTPS à un serveur web et renvoie les résultats. Cet article décrit un changement de renforcement dans lequel Windows PowerShell 5.1 affiche intentionnellement une invite de confirmation de sécurité lors de l’utilisation de la commande Invoke-WebRequest pour extraire des pages Web sans paramètres spéciaux. Ce comportement se produit après l’installation de Windows Mises à jour les clients et serveurs Windows pris en charge le 9 décembre 2025 et après cette date. Pour plus d’informations, consultez CVE-2025-54100.
  • Ajout des puces suivantes à « Pour les scripts automatisés ou les tâches planifiées » dans l’option 1 de la section « Prendre des mesures ».
    • Pour les scripts qui s’exécutent avec l’option no-profile : si le script a de nombreuses occurrences des appels de Invoke-WebRequest, déclarez $PSDefaultParameterValues['Invoke-WebRequest :UseBasicParsing'] = $true en haut du script.
    • Lorsque Invoke-WebRequest est utilisé avec le paramètre -UseBasicParsing, l’analyse du modèle DOM (Full Document Object Model) à l’aide de composants Internet Explorer (HTMLDocument Interface (MSHTML)) n’est pas possible.
  • Ajout de la puce suivante à la puce « Moderniser votre approche des interactions web » de l’option 2 dans la section « Passer à l’action ».
    • Invoke-Webrequest dans Powershell Core (version 7.x ou ultérieure) ne prend pas en charge l’analyse DOM à l’aide des composants Internet Explorer. Son analyse par défaut récupère le contenu en toute sécurité sans exécution de script.

Récapitulatif

Windows PowerShell 5.1 affiche désormais une invite de confirmation de sécurité lors de l’utilisation de la commande Invoke-WebRequest pour extraire des pages Web sans paramètres spéciaux.

Remarque

  • Avertissement de sécurité : Risque d’exécution de script Invoke-WebRequest analyse le contenu de la page Web. Le code de script de la page web peut être exécuté lors de l’analyse de la page.
  • ACTION RECOMMANDÉE : Utilisez le commutateur -UseBasicParsing pour éviter l’exécution de code de script.
  • Voulez-vous continuer ?

Cette invite avertit que les scripts de la page peuvent s’exécuter pendant l’analyse et conseille d’utiliser le paramètre
-UseBasicParsing pour éviter toute exécution de script. Les utilisateurs doivent choisir de continuer ou d’annuler l’opération. Cette modification permet de se protéger contre le contenu web malveillant en exigeant le consentement de l’utilisateur avant des actions potentiellement dangereuses.

La commande Invoke-WebRequest de PowerShell envoie une requête HTTP ou HTTPS à un serveur web et renvoie les résultats. Cet article décrit une modification de renforcement dans laquelle Windows PowerShell 5.1 affiche intentionnellement une invite de confirmation de sécurité lors de l’utilisation de la commande Invoke-WebRequest pour extraire des pages Web sans paramètres spéciaux. Ce comportement se produit après que les clients et serveurs Windows pris en charge ont installé les mises à jour Windows publiées le 9 décembre 2025 et après. Pour plus d’informations, consultez CVE-2025-54100.

Qu’est-ce qui a changé ?

  • Comportement précédent

    • Analyse complète du modèle DOM (Document Object Model) à l’aide de composants Internet Explorer (HTMLDocument Interface (MSHTML)), qui pourraient exécuter des scripts à partir du contenu téléchargé.
  • Nouveau comportement

    • Invite de confirmation de sécurité : Après l’installation des mises à jour Windows publiées le 9 décembre 2025 ou après, l’exécution de la commande Invoke-WebRequest (également appelée curl) dans PowerShell 5.1 déclenche une invite de sécurité (lorsqu’aucun paramètre spécial n’est utilisé). L’invite s’affiche dans la console PowerShell avec un avertissement sur le risque d’exécution de script

      Cela signifie que PowerShell est en pause pour vous avertir que sans précautions, le contenu du script de page web pourrait s’exécuter sur votre système lors de son traitement. Par défaut, si vous appuyez sur Entrée (ou choisissez Non), l’opération est annulée pour des raisons de sécurité. PowerShell affiche un message indiquant qu’il a été annulé pour des raisons de sécurité et suggère de réexécuter la commande en utilisant le
      -UseBasicParsing pour un traitement sécurisé. Si vous choisissez Oui, PowerShell procède à l’analyse de la page à l’aide de l’ancienne méthode (analyse HTML complète), ce qui signifie qu’il charge le contenu et les scripts incorporés comme avant. En gros, choisir Oui signifie que vous acceptez le risque et autorisez la commande à s’exécuter comme avant, tandis que choisir Non (valeur par défaut) arrête l’action pour vous protéger.

    • Utilisation interactive vs. scénarisée : L’introduction de cette invite affecte principalement l’utilisation interactive. Dans les sessions interactives, vous verrez l’avertissement et devrez réagir. Pour les scripts automatisés (scénarios non interactifs tels que les tâches planifiées ou les pipelines CI), cette invite peut entraîner le blocage du script en attente d’entrée. Pour éviter cela, nous vous recommandons de mettre à jour ces scripts pour utiliser explicitement des paramètres sécurisés (voir ci-dessous), en veillant à ce qu’ils ne nécessitent pas de confirmation manuelle.

Gérez activement vos projets

La plupart des scripts et commandes PowerShell qui utilisent la commande Invoke-WebRequest continueront à fonctionner avec peu ou pas de modifications. Par exemple, les scripts qui téléchargent uniquement du contenu ou fonctionnent avec le corps de la réponse en tant que texte ou données ne sont pas affectés et ne nécessitent aucune modification.

Si certains de vos scripts sont affectés par cette modification, utilisez l’une des approches suivantes.

Option 1 : utiliser la nouvelle valeur par défaut sécurisée

Pour l’extraction de contenu, aucune action n’est requise si votre utilisation habituelle de la commande Invoke-WebRequest consiste à récupérer du contenu (comme le téléchargement de fichiers ou la lecture de texte statique) et que vous ne vous appuyez pas sur l’interaction avancée du site ou l’analyse DOM HTML. Le nouveau comportement par défaut est plus sécurisé : les scripts incorporés dans le contenu web ne s’exécuteront pas sans votre autorisation, et il s’agit de la configuration recommandée pour la plupart des scénarios.

Pour une utilisation interactive, il vous suffit de répondre Non à la nouvelle invite de sécurité (ou d’appuyer sur Entrée pour accepter la valeur par défaut) et de relancer votre commande avec le paramètre -UseBasicParsing pour récupérer le contenu en toute sécurité. Cela évitera d’exécuter tout code de script dans la page récupérée. Si vous récupérez fréquemment du contenu Web de manière interactive, envisagez d’utiliser le paramètre -UseBasicParsing par défaut dans vos commandes pour ignorer complètement l’invite et assurer une sécurité maximale.

Pour les scripts automatisés ou les tâches planifiées, mettez-les à jour pour inclure le paramètre -UseBasicParsing sur les appels Invoke-WebRequest . Cette opération permet de présélectionner le comportement sans échec afin que l’invite n’apparaisse pas et que votre script continue de s’exécuter sans interruption. Ce faisant, vous vous assurez que votre automatisation s’exécute en toute transparence après la mise à jour tout en tirant parti de la sécurité améliorée.

  • Pour les scripts exécutés avec l’option -NoProfile : si le script comporte de nombreuses occurrences des appels Invoke-WebRequest , déclarez $PSDefaultParameterValues['Invoke-WebRequest :UseBasicParsing'] = $true en haut du script.
  • Lorsque Invoke-WebRequest est utilisé avec le paramètre -UseBasicParsing, l’analyse du modèle DOM (Full Document Object Model) à l’aide de composants Internet Explorer (HTMLDocument Interface (MSHTML)) n’est pas possible.
Option 2 : refactorisation des scripts pour une sécurité à long terme

Pour les scripts ou l’automatisation qui traitent du contenu Web non approuvé ou public et nécessitent le traitement de structures ou de formulaires HTML, envisagez de les refactoriser ou de les mettre à jour pour une sécurité à long terme. Plutôt que de vous fier à PowerShell pour analyser et exécuter des scripts de pages web potentiellement dangereux, vous pouvez :

  • Utilisez d’autres méthodes ou bibliothèques d’analyse (par exemple, traitez le contenu d’une page web comme du texte brut ou XML, à l’aide de regex ou de bibliothèques d’analyse XML/HTML qui n’exécutent pas de scripts).

  • Modernisez votre approche des interactions web, peut-être en utilisant le nouveau PowerShell Core (version 7.x ou ultérieure) qui ne dépend pas du moteur d’Internet Explorer et évite d’exécuter des scripts, ou en utilisant des outils de capture web spécialisés qui gèrent le contenu de manière plus sécurisée. Limitez votre dépendance aux fonctionnalités spécifiques d’Internet Explorer, car Internet Explorer est obsolète. Prévoyez de réécrire les parties de vos scripts qui dépendent de ces fonctionnalités afin qu’elles puissent fonctionner dans un environnement où le contenu web est géré en toute sécurité.

    • Invoke-WebRequest dans PowerShell Core (version 7.x ou ultérieure) ne prend pas en charge l’analyse DOM à l’aide des composants Internet Explorer. Son analyse par défaut récupère le contenu en toute sécurité sans exécution de script.
  • L’objectif de la refactorisation est d’obtenir les fonctionnalités dont vous avez besoin sans vous exposer à des risques de sécurité, adoptant ainsi les valeurs par défaut plus sûres introduites par cette modification.

Option 3 : Accepter le comportement hérité (scénarios approuvés uniquement)

Si vous avez un besoin spécifique d’utiliser toutes les fonctionnalités d’analyse HTML de la commande Invoke-WebRequest (telles que l’interaction avec les champs de formulaire ou le scraping de données structurées) et que vous faites confiance à la source du contenu web, vous pouvez toujours procéder au comportement d’analyse hérité au cas par cas. Dans les sessions interactives, il s’agit simplement de choisir Oui à l’invite de confirmation pour permettre à l’opération de se poursuivre. Vous recevrez un rappel du risque de sécurité chaque fois que vous le ferez. Continuer sans le paramètre -UseBasicParsing doit être limité aux scénarios où vous faites entièrement confiance au contenu web (par exemple, les applications web internes sous votre contrôle ou les sites web sécurisés connus).

Important

Cette approche n’est pas recommandée pour les scripts exécutés sur du contenu web public ou non approuvé, car elle réintroduit le risque d’exécution de script silencieux que cette mise à jour est destinée à atténuer. De plus, pour l’automatisation non interactive, il n’existe aucun mécanisme intégré permettant de donner automatiquement un consentement à l’invite, de sorte qu’il n’est pas conseillé de s’appuyer sur une analyse complète dans les scripts (en plus d’être risqué). Utilisez cette option avec parcimonie et uniquement à titre temporaire.

Forum Aux Questions

Ce changement affecte-t-il mes scripts ?

Dans la plupart des cas, les scripts qui téléchargent des fichiers ou extraient du contenu web sous forme de texte fonctionnent toujours. Pour éviter l’invite, ajoutez le paramètre -UseBasicParsing .

Les scripts utilisant une analyse HTML avancée (comme les formulaires ou DOM) peuvent bloquer ou générer des données brutes au lieu d’objets structurés ; Vous devrez passer à l’analyse de base ou modifier votre script pour gérer le contenu différemment.

Comment puis-je éviter la nouvelle invite de confirmation dans mes scripts ?

Utilisez toujours le paramètre -UseBasicParsing avec la commande Invoke-WebRequest dans les scripts PowerShell pour garantir une exécution sûre et non interactive.

Cette modification nécessite-t-elle une action pour les scripts hérités ?

Oui. Les scripts dépendant de l’analyse héritée doivent être mis à jour pour accepter ou refactoriser.

Comment ce changement est-il reflété dans les mises à jour standard et hotpatch ?

La modification dans PowerShell s’applique à la fois aux mises à jour standard et aux mises à jour de patch à chaud, ce qui entraîne le même changement de comportement.

Cette modification s’aligne-t-elle sur PowerShell 7 ?

Oui. PowerShell 7 utilise déjà l’analyse sécurisée par défaut.

Que dois-je faire des scripts ou modules tiers ?

Contactez les propriétaires de modules pour obtenir des plans de support. Utilisez temporairement l’abonnement pour le contenu approuvé lors de la migration.

Comment faire vérifier que mon environnement est prêt ?

Pour préparer et valider cette modification, nous vous recommandons de :

  • Identifiez les scripts à l’aide des fonctionnalités DOM.
  • Testez l’automatisation avec la nouvelle valeur par défaut.
  • Limitez l’acceptation héritée aux sources approuvées.
  • Planifiez la refactorisation du contenu non approuvé.