Windows PowerShell now warns when running Invoke-WebRequest scripts

Recent Windows PowerShell behavior changes are causing more warnings around scripts that use Invoke-WebRequest as part of a download-and-execute workflow. Even when your script is legitimate, PowerShell (and often endpoint security tooling) can treat this pattern as higher risk.

This guide is a practical, reference-style walkthrough: identify the exact warning, understand what typically triggers it, then update your scripts to download safely, validate content, and avoid execution patterns that security controls flag.

As an Amazon Associate I earn from qualifying purchases.

Source URL validation note: you didn’t provide a source URL in your request, so there’s nothing to validate here. If you paste the warning text or the URL your script pulls from, I can help map it to the right fix path.

What changed and why PowerShell warns

The warning usually appears when PowerShell detects a pattern that resembles “remote content execution.” The common red flag isn’t that Invoke-WebRequest is inherently malicious—it’s that Invoke-WebRequest is often used to fetch a payload and then execute it immediately (for example, piping into Invoke-Expression).

In many environments, this is triggered by a combination of:

• PowerShell runtime updates (Windows PowerShell 5.1 and newer PowerShell 7+ releases).
• Defender for Endpoint / ASR rules and other EDR heuristics.
• Script block and security logging that makes suspicious download+execute flows stand out.
• Enterprise hardening via Group Policy / AppLocker / Constrained Language Mode.

If your script only downloads data and does not execute remote code, you generally should be able to remove the trigger by restructuring the workflow.

Prerequisites and environment checks

Before changing anything, capture your runtime details. Different versions behave differently and warnings may originate from different layers.

Check which PowerShell you’re running

1. Open PowerShell or Windows PowerShell.
2. Run:

$PSVersionTable | Format-List *

Look for:

• PSVersion (e.g., 5.1 vs 7.x)
• PSEdition (Desktop vs Core)
• CLRVersion

Check execution constraints

1. Run:

Get-ExecutionPolicy -List

If you see policies like AllSigned or RemoteSigned, your “download and run” fix might also need signing.

Identify the warning you’re seeing

PowerShell warnings vary by environment. The key is to capture the exact message text and the call stack line that triggered it. That tells you whether it’s PowerShell itself, logging, or an EDR rule.

Collect the important details

1. Copy the full warning text.
2. Record these values:

• PowerShell version from $PSVersionTable
• What line calls Invoke-WebRequest
• Whether the downloaded result is executed (common: Invoke-Expression, iex, Invoke-Command, or Start-Process on a downloaded file)
• The URL host (example: raw.githubusercontent.com, company.portal, CDN domain)

Common trigger patterns

These are the patterns most likely to cause warnings:

• Invoke-WebRequest ... | Invoke-Expression
• Invoke-WebRequest ... -OutFile "C:\Temp\x.ps1" ; & "C:\Temp\x.ps1"
• IWR ... -UseBasicParsing combined with deprecated/legacy behavior
• Downloading from an untrusted domain or dynamic query string endpoints

Why warning-triggering patterns are risky

Security controls are designed to stop “living off the land” style abuse. When a script fetches remote code and then executes it immediately, an attacker only needs to compromise the URL, redirect target, or upstream account to swap in a malicious payload.

Even if you trust the source today, supply chain issues happen. That’s why the safer fix is usually: download → verify → then run (or avoid executing entirely).

Fix options (choose the safest approach)

There isn’t one universal fix because the warning can come from different controls. But you can almost always reduce or eliminate the trigger by changing the workflow structure.

Replace IWR with a safer download workflow

If your goal is to retrieve text/JSON, avoid “execute remote string.” Keep Invoke-WebRequest for data retrieval, and move execution to verified local content.

Download to a file with explicit destinations

If you truly need a remote file, save it to a known path using -OutFile, restrict permissions, and validate integrity before running it.

Validate content before execution

Use SHA-256 hashes, checksum files, or compare expected length/content type. Better yet, verify Authenticode signatures for PowerShell scripts.

Use Authenticode signatures for scripts

For script-based payloads (.ps1), signature verification is one of the most governance-friendly options. It also reduces operational risk when endpoints change.

Use HttpClient in PowerShell 7+

In PowerShell 7+, Invoke-WebRequest still works, but some environments may prefer System.Net.Http.HttpClient for clearer transport control and improved error handling.

Code patterns you can copy

Below are hardened patterns. Pick the one closest to what your script is doing today.

Pattern A: Download content (no execution)

Use this when you only need to fetch JSON, configuration, or text and then parse it locally.

$uri = 'https://example.com/config.json'

$response = Invoke-WebRequest -Uri $uri -Method Get -UseBasicParsing -ErrorAction Stop

$json = $response.Content | ConvertFrom-Json

Then operate on $json without running remote strings.

Pattern B: Download a file with -OutFile

Use this when you need a local artifact (e.g., .ps1, .exe, .zip), but don’t execute until you’ve verified it.

$uri = 'https://example.com/scripts/agent-install.ps1'

$outFile = Join-Path $env:TEMP 'agent-install.ps1'

$null = Invoke-WebRequest -Uri $uri -OutFile $outFile -Method Get -ErrorAction Stop

Now validate and then run (see the next patterns).

Pattern C: Validate hash then run

This is the most common “enterprise-friendly” approach when you can publish hashes alongside releases.

$uri = 'https://example.com/releases/agent-install.ps1'

$expectedSha256 = '9E9D5A2D1B...YOUR_HASH_HERE...'

$outFile = Join-Path $env:TEMP 'agent-install.ps1'

1. Download:

Invoke-WebRequest -Uri $uri -OutFile $outFile -Method Get -ErrorAction Stop

2. Compute SHA-256:

$actualSha256 = (Get-FileHash -Path $outFile -Algorithm SHA256).Hash

3. Compare and run only if it matches:

if ($actualSha256 -ne $expectedSha256) { throw 'Hash mismatch. Aborting execution.' }

& $outFile

Pattern D: Verify script signature then run

If the remote file is a .ps1 signed with a trusted certificate, you can require signature validity before executing.

$outFile = Join-Path $env:TEMP 'signed-script.ps1'

Invoke-WebRequest -Uri 'https://example.com/signed-script.ps1' -OutFile $outFile -ErrorAction Stop

$sig = Get-AuthenticodeSignature -FilePath $outFile

if ($sig.Status -ne 'Valid') { throw ("Signature invalid: {0}" -f $sig.Status) }

& $outFile

In locked-down environments, this pairs well with AllSigned or RemoteSigned.

Pattern E: PowerShell 7+ HttpClient example

If you’re on PowerShell 7.2+ and want explicit control (headers, timeouts), use HttpClient.

$uri = 'https://example.com/data.json'

$handler = [System.Net.Http.HttpClientHandler]::new()

$client = [System.Net.Http.HttpClient]::new($handler)

$client.Timeout = [TimeSpan]::FromSeconds(30)

$bytes = $client.GetByteArrayAsync($uri).GetAwaiter().GetResult()

$text = [System.Text.Encoding]::UTF8.GetString($bytes)

$json = $text | ConvertFrom-Json

This avoids the “download string then execute” shape entirely.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Troubleshooting when fixes don’t work

If you’ve removed execution of remote strings but still get warnings, the issue is likely one of: environment hardening, redirected content, TLS problems, or a different code path still executes remote data.

TLS/HTTPS negotiation issues

Some older Windows PowerShell setups (5.1) default to older TLS settings depending on OS patch level.

On Windows PowerShell 5.1, you can try forcing TLS 1.2:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Run this before calling Invoke-WebRequest.

Redirect loops and wrong endpoints

If your URL redirects (302/307), security tools may flag the redirect chain or block unknown domains.

Mitigate by using the final canonical URL and setting a sane redirect limit. For example, check the response headers and confirm you’re not following to a different host.

Proxy and corporate network constraints

In managed networks, WinHTTP/WinINET proxy settings can cause failures that get misreported as content risks.

• Check for proxy requirements (PAC vs static proxy).
• Test with a direct browser and confirm the same endpoint is reachable.
• If needed, configure proxy behavior explicitly (especially in PowerShell 7+).

403/401 auth failures

If you download from an authenticated endpoint and your request is missing headers, the response might be an HTML error page. When your script then tries to parse or run it, you can get misleading warnings.

Fix by using the right auth mechanism:

• API tokens via -Headers
• Client certificates when required
• NTLM/Windows auth (where supported)

Also, validate Content-Type before treating the response as script/JSON.

Execution policy and script signing

If you switch to “download file then run,” ExecutionPolicy can block execution. In many enterprise environments, AllSigned or RemoteSigned is enforced.

Common resolution paths:

• Sign the script you download.
• Host scripts in a trusted internal location so they’re not treated as remote/untrusted.
• Use a proper package/update mechanism rather than ad-hoc downloads.

Common mistakes that keep triggering the warning

• Executing remote content directly (e.g., IWR ... | iex or iex (iwr ...)).
• Executing downloaded files without verification (no hash/signature check).
• Using broad permissions (writing into a shared folder with weak ACLs).
• Accepting redirected content without confirming the destination host and scheme (HTTP vs HTTPS).
• Ignoring response type (parsing HTML error pages as if they were scripts or JSON).

Security and governance considerations

If this warning is showing up at scale, treat it as a governance signal. The goal isn’t just to silence warnings; it’s to make the download-and-execute path auditable and tamper-resistant.

Recommended operational model

• Host releases with immutable URLs (versioned paths) rather than endpoints that change content in place.
• Publish SHA-256 hashes or signed artifacts for every release.
• Use least privilege when writing temp files and when executing downloaded artifacts.
• Prefer “download data” over “download code” whenever possible.

How to document the change

Update your internal runbooks so maintainers know:

• Which domain(s) are allowed
• Expected hash/signing details
• How to rotate certificates or update hashes
• What evidence to capture in troubleshooting (PowerShell version, warning text, URL, file hashes)

FAQs

Does using Invoke-WebRequest by itself cause the warning?

Usually, the warning is tied to how the downloaded content is used. Invoke-WebRequest fetching JSON or configuration for local parsing is less likely to trigger remote-execution heuristics than piping it into Invoke-Expression.

Can I just suppress the warning instead of changing the script?

You can sometimes suppress specific PowerShell messages, but security controls (Defender/EDR/ASR) often still block or log the behavior. The safer approach is restructuring the script to stop remote code execution or add verification (hash/signature).

What’s the safest way to run a script that’s downloaded over the network?

Download to disk using -OutFile, verify integrity (SHA-256) or Authenticode signature, then execute the local file. Avoid running remote text directly via Invoke-Expression.

Will switching to PowerShell 7+ automatically remove the warning?

Not automatically. If the pattern still looks like download-and-execute without verification, warnings may persist. However, PowerShell 7+ can make it easier to adopt better transport and validation patterns.

If my endpoint is blocked, how do I confirm it’s a security heuristic vs a network error?

Compare behavior: check whether you receive an HTML error page, an authentication error, or a normal response. Then confirm the warning correlates with execution attempts (especially Invoke-Expression or directly running downloaded files).

Final Thoughts

PowerShell warnings tied to Invoke-WebRequest scripts are often about intent: when remote content is executed, systems get stricter. The most reliable fix is to redesign the workflow into a verifiable supply chain—download to disk, validate (hash/signature), then run.

If you paste the exact warning text and the relevant lines around your Invoke-WebRequest call, I can tell you which fix path fits best and provide a drop-in rewrite for your script.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.