Original publish date: December 9, 2025
KB ID:Â 5074596
Summary
Windows PowerShell 5.1 now displays a security confirmation prompt when using the Invoke-WebRequest command to fetch web pages without special parameters. This prompt warns that scripts in the page could run during parsing and advises using the safer -UseBasicParsing parameter to avoid any script execution. Users must choose to continue or cancel the operation. This change helps protect against malicious web content by requiring user consent before potentially risky actions.
This change primarily impacts enterprise or IT-managed environments where PowerShell scripts are used for automation and web content retrieval. People using devices in personal or home settings generally do not need to take any action, as these scenarios are uncommon outside IT managed deployments.
​​​​​​​What Changed?
-
Previous behavior
-
Full Document Object Model (DOM) parsing using Internet Explorer components (HTMLDocument Interface (mshtml)), which could execute scripts from downloaded content.
-
-
New behavior
-
Security Confirmation Prompt: After installing the Windows updates released on or after December 9, 2025, running the Invoke-WebRequest command (also known as curl) in PowerShell 5.1 will trigger a security prompt (when no special parameter is used). The prompt appears in the PowerShell console with a warning about Script Execution Risk. This means PowerShell is pausing to warn you that without precautions, the web page script content could execute on your system when it is processed. By default, if you press Enter (or choose No), the operation will be canceled for safety. PowerShell will show a message that it was canceled due to security concerns, and suggests re-running the command by using the -UseBasicParsing parameter for safe processing. If you choose Yes, PowerShell will proceed to parse the page using the older method (full HTML parsing), meaning it will load the content and any embedded scripts as it used to. Essentially, choosing Yes means you are accepting the risk and allowing the command to run as it did before, while choosing No (the default) stops the action to protect you.
-
Interactive vs. Scripted Use: The introduction of this prompt primarily affects interactive usage. In interactive sessions, you will see the warning and have to respond. For automated scripts (non-interactive scenarios such as scheduled tasks or CI pipelines), this prompt could cause the script to hang waiting for input. To avoid that, we recommend updating such scripts to explicitly use safe parameters (see below), ensuring they do not require manual confirmation.
-
Take action
Most PowerShell scripts and commands that use the Invoke-WebRequest command will continue to work with little or no modification. For example, scripts that only download content or work with the response body as text or data are not affected and require no changes.Â
If you have scripts that are affected by this change, use one of the following approaches.
No action required if your typical use of the Invoke-WebRequest command is to fetch content (like downloading files or reading static text) and you do not rely on advanced site interaction or HTML DOM parsing. The new default behavior is more secure—scripts embedded in web content will not run without your permission—and this is the recommended configuration for most scenarios.Â
For interactive usage, simply respond No to the new security prompt (or press Enter to accept the default) and re-run your command with the -UseBasicParsing parameter to safely retrieve the content. This will avoid executing any script code in the fetched page. If you frequently fetch web content interactively, consider using the -UseBasicParsing parameter by default in your commands to skip the prompt altogether and ensure maximum safety.Â
For automated scripts or scheduled tasks, update them to include the -UseBasicParsing parameter on Invoke-WebRequest calls. This pre-selects the safe behavior so that the prompt does not appear and your script continues to run without interruption. By doing this, you ensure that your automation runs seamlessly after the update while still taking advantage of the improved security.Â
For scripts or automation that deal with untrusted or public web content and require processing of HTML structures or forms, consider refactoring or updating them for long-term safety. Rather than relying on PowerShell to parse and run potentially dangerous web page scripts, you can:Â
-
Use alternative parsing methods or libraries (for example, treat the web page content as plain text or XML, using regex or XML/HTML parsing libraries that do not execute scripts).
-
Modernize your approach to web interactions, perhaps by using newer PowerShell Core (version 7.x or later) which does not depend on Internet Explorer’s engine and avoids running scripts, or by using specialized web scraping tools that handle content more securely.
-
Limit reliance on Internet Explorer–specific features, since Internet Explorer is deprecated. Plan to re-write parts of your scripts that depend on those features so they can work in an environment where web content is handled safely.
-
The goal with refactoring is to achieve your needed functionality without exposing yourself to security risks, thereby embracing the safer defaults introduced by this change.
If you have a specific need to use the Invoke-WebRequest commands full HTML parsing capabilities (such as interacting with form fields or scraping structured data) and you trust the source of the web content, you can still proceed with the legacy parsing behavior on a case-by-case basis. In interactive sessions, this simply means choosing Yes at the confirmation prompt to allow the operation to continue. You will receive a reminder of the security risk each time you do so. Proceeding without the -UseBasicParsing parameter should be limited to scenarios where you fully trust the web content (for example, internal web applications under your control or known safe websites).Â
Important: This approach is not recommended for scripts running against untrusted or public web content, because it reintroduces the risk of silent script execution that this update is intended to mitigate. Also, for non-interactive automation, there is no built-in mechanism to automatically consent to the prompt, so relying on full parsing in scripts is not advisable (in addition to being risky). Use this option sparingly and only as a temporary measure.
Frequently asked questions​​​​​​​
For most cases, scripts that download files or fetch web content as text will still work; add the -UseBasicParsing parameter to avoid prompts. Scripts using advanced HTML parsing (like forms or DOM) may hang or output raw data instead of structured objects; you will need to switch to basic parsing or modify your script to handle content differently.
Always use the -UseBasicParsing parameter with the Invoke-WebRequest command in PowerShell scripts to ensure safe, non-interactive execution. Â
Yes. Scripts depending on legacy parsing must be updated to opt in or refactor.
The change in PowerShell applicable to both standard updates and hotpatch updates, resulting in the same behavior change.
Yes. PowerShell 7 already uses secure parsing by default.
Contact module owners for support plans. Use opt-in temporarily for trusted content while migrating.
To prepare for and validate this change, we recommend that you:Â
-
Identify scripts using DOM features.
-
Test automation with the new default.
-
Limit legacy opt-in to trusted sources.
-
Plan refactoring for untrusted content.
