Invoke-WebRequest Hangs

On December 9, 2025, Microsoft shipped a security update that changes how Invoke-WebRequest behaves in Windows PowerShell 5.1. This change is important for anyone who uses PowerShell for automation, monitoring, configuration management, or CI/CD pipelines.

The short version:
Invoke-WebRequest no longer runs automatically in all cases. It now displays a security confirmation prompt before processing web pages unless you specify safe parameters.

If your script suddenly started hanging, this change is almost certainly why.

The video version:
I released a short (less than 5 minute) video explaining all of this – Invoke-WebRequest Just Started Asking Questions

This post covers:

What changed
Why Microsoft made this change
How it affects scripts and automation
What you need to update to make your scripts reliable again

What Changed?

Before this update, Invoke-WebRequest used the old Internet Explorer HTML parser (mshtml) to produce a full DOM, which could process or run scripts contained inside a page as part of parsing. This behavior was not obvious to most users, but it did create security risks.

Old behavior (before December 2025)

PowerShell parsed HTML using Internet Explorer components.
Any JavaScript embedded in the page could execute during parsing.
No prompts, no warnings.

New behavior (after December 2025)

Running this command:

Invoke-WebRequest "https://example.com"

Now shows a security prompt:

SECURITY WARNING: Script Execution Risk

The downloaded content may contain scripts that could run during HTML parsing.
Do you want to continue?

[Y] Yes  [N] No  (Default is "No"):

If you press Enter (or choose No), PowerShell cancels the command and suggests using safer parameters:

Operation canceled due to security concerns.
Re-run the command with -UseBasicParsing for safe processing.

Important details:

Choosing Yes continues with the old behavior (full DOM parsing with script risk).
Choosing No cancels the command.
Automation will hang, because scripts do not respond to interactive prompts.

Why This Change?

PowerShell DOM parsing was historically tied to Internet Explorer components, which were never designed for secure, modern automation. Those components could run page scripts during parsing, which is an obvious security concern, especially in enterprise environments.

Microsoft’s solution was to introduce:

A confirmation prompt so users must explicitly acknowledge risk.
A safe-path alternative using -UseBasicParsing.

This update ensures that scripts do not silently execute downloaded content without some form of consent or explicit configuration.

Who Is Affected?

Highly affected

Enterprise automation
Scheduled tasks
CI/CD pipelines
Monitoring systems
Configuration management tools
Admin scripts that fetch web pages or HTML

NOT affected

PowerShell 7+
Invoke-RestMethod
Invoke-WebRequest already using -UseBasicParsing

If you rely on non-interactive automation, you must update your scripts.

How to Fix Your Scripts

To prevent the prompt and avoid unexpected hangs, you must explicitly choose a safe parsing mode.

Option 1: Use `-UseBasicParsing`

This is the recommended fix for existing scripts that rely on Invoke-WebRequest.

Invoke-WebRequest "https://example.com" -UseBasicParsing

What this does:

Avoids the DOM parser.
Avoids any script execution risk.
Avoids the prompt.
Produces consistent output for automation.

Option 2: Switch to `Invoke-RestMethod`

If your target is not HTML, such as JSON, XML, or REST APIs, then Invoke-RestMethod is often the better tool.

Invoke-RestMethod "https://api.example.com/data"

Invoke-RestMethod does not use the Internet Explorer HTML parser and does not trigger this prompt.

Option 3: Upgrade to PowerShell 7+

PowerShell 7 does not use DOM parsing so it is safe with or without the -UseBasicParsing switch.

What Happens If You Do Not Update?

1. Scripts will hang indefinitely

Your automation will get stuck waiting at the security prompt:

Do you want to continue?

2. Monitoring and scheduled tasks will fail silently

Tasks may appear to run but never complete because they are blocked on user input that never arrives.

3. CI pipelines may stall until timeout

Your pipeline might sit and wait until a timeout triggers, making failures harder to diagnose.

4. You may experience inconsistent behavior across servers

Only patched systems will exhibit the new prompt, so behavior may differ between machines depending on which updates they have installed.

Best Practices Moving Forward

Always include -UseBasicParsing when using Invoke-WebRequest in automation.
Prefer Invoke-RestMethod for API or structured data calls.
Avoid using Windows PowerShell 5.1 for HTML parsing in security-sensitive contexts when possible.
Audit existing scripts to search for Invoke-WebRequest usage without safe parameters.

Find Affected Script

I put together a script that you can use to search a local directory or you installed modules for affected code. Simply download the Search-CmdletParameterUsage.ps1 from my Gist and run it locally to find affected scripts.

# Search for Invoke-WebRequest usage in a specific folder and its subfolders
.\Search-CmdletParameterUsage.ps1 -FolderPath 'C:\Scripts' -Recurse

You can quickly scan a folder of scripts with a command like this:

# Search for Invoke-WebRequest usage in a specific folder and its subfolders
.\Search-CmdletParameterUsage.ps1 -FolderPath 'C:\Scripts' -Recurse

Conclusion

This update introduces a security prompt to prevent silent script execution when using Invoke-WebRequest with full DOM parsing. It is a significant security improvement, but it can break existing automation unless you explicitly opt into safer parsing modes.

To keep your scripts working reliably:

Add -UseBasicParsing to Invoke-WebRequest calls used in automation.
Switch to Invoke-RestMethod for API and structured data scenarios.
Use raw content retrieval or file output when HTML parsing is not required.

Making these updates now will ensure your scripts remain consistent, predictable, and secure across all systems that receive the December 2025 update.

For more details you can refer to the Microsoft KB article : PowerShell 5.1: Preventing script execution from web content