Windows PowerShell now warns when running Invoke-WebRequest scripts

[Parkinsond]

Content source

https://www.bleepingcomputer.com/news/security/microsoft-windows-powershell-now-warns-when-running-invoke-webrequest-scripts/

Microsoft says Windows PowerShell now warns when running scripts that use the Invoke-WebRequest cmdlet to download web content, aiming to prevent potentially risky code from executing.

The warning has been added to Windows PowerShell 5.1, the PowerShell version installed by default on Windows 10 and Windows 11 systems, and is designed to add the same secure web parsing process available in PowerShell 7.

PowerShell will alert you that, without precautions, scripts contained in web pages downloaded using the "Invoke-WebRequest' cmdlet could execute on your system. By default, if you press 'Enter' or select 'No,' the operation will be canceled, and PowerShell will suggest rerunning the command with the '-UseBasicParsing' parameter for safer processing.

When choosing 'Yes,' PowerShell will parse the page using the older method (full HTML parsing), allowing the content and embedded scripts to load as before. In short, selecting 'Yes 'means you accept the risk, while choosing 'No' stops the action to protect your system.

Windows PowerShell now warns when running Invoke-WebRequest scripts

Microsoft says Windows PowerShell now warns when running scripts that use the Invoke-WebRequest cmdlet to download web content, aiming to prevent potentially risky code from executing.

www.bleepingcomputer.com

 

[Bot]

This is a nice hardening step from Microsoft, but it’s important to understand what it actually does (and doesn’t) protect you from.

What’s changing in Windows PowerShell 5.1
When you run something like:

Invoke-WebRequest https://example.com

Windows PowerShell 5.1 historically used an old, IE-based HTML parser for full page parsing. That means:

• The content was rendered using legacy Internet Explorer components.
• In some scenarios, embedded scripts and active content could be processed by that engine.

Microsoft is now adding a warning when you use Invoke-WebRequest without precautions, because that old parsing method is more risky.

What the new warning means

When you see the prompt:

• Choosing “No” (default)
  • The operation is cancelled.
  • PowerShell suggests re-running with -UseBasicParsing.
• Choosing “Yes”
  • PowerShell uses the old, full HTML parsing method (with the IE engine).
  • You’re accepting the additional risk of loading the page that way.

So practically:

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

will:

• Download the content using a simpler .NET-based parser.
• Not invoke the legacy IE HTML engine.
• Still give you the raw content to work with (e.g. .Content, .RawContent), but with fewer automatic HTML/DOM conveniences.

How “safe” is -UseBasicParsing?

• -UseBasicParsing is safer for web parsing itself because it avoids the old IE HTML/JS handling.
• It does NOT magically make the downloaded content safe:
  • If you save and execute anything from that content, it’s still as dangerous as before.
  • It mainly reduces risk from the way the HTML page is parsed/rendered.

Impact on real-world usage

• For normal users:
  • If you’re just copy-pasting a one-liner from a random blog to download and run something, this adds a speed bump and a clear warning.
  • The safest choice when in doubt is to press No, review the script, or not run it at all.
• For admins/scripts:
  • Existing scripts that rely on Invoke-WebRequest may now show prompts if they use full HTML parsing.
  • You can suppress the prompt and use the safer model by explicitly adding -UseBasicParsing.
  • PowerShell 7+ already dropped the IE-based parser; this change makes 5.1 behavior closer to that.

Security takeaway

• This is a small but useful hardening measure against risky script usage and legacy IE-based parsing.
• It does not stop an attacker who already has the ability to run arbitrary PowerShell.
• It does help warn users when they’re about to let PowerShell process web pages in a more dangerous way, and nudges them toward basic parsing instead.

So in practice:

• If you trust the site/script and just need the content: use -UseBasicParsing.
• If you’re not 100% sure what the script does or where it comes from: don’t bypass the warning—stop and reconsider running it at all.

 

[Sampei.Nihira]

@Bot

Do you recommend installing Powershell 7 in Windows 11?
If so, why?

 

[Bot]

@Bot

Do you recommend installing Powershell 7 in Windows 11?
If so, why?

Yes, for many Windows 11 users (especially anyone who runs scripts or administers systems), installing PowerShell 7 is a good idea. You can install it without “replacing” Windows PowerShell 5.1 because they run side-by-side.

Why PowerShell 7 can be worth installing

• Actively developed and updated
  PowerShell 7 continues to receive new features, bug fixes, and security hardening work. Windows PowerShell 5.1 is essentially “in-box” and mostly in maintenance mode.
• More modern engine (.NET)
  PowerShell 7 runs on modern .NET, which typically means better performance, better networking defaults, and fewer legacy dependencies (compared to the old Windows-only stack used by 5.1).
• Better defaults for web cmdlets (and fewer legacy components)
  In general, PowerShell 7 avoids the older Internet Explorer-based web parsing behavior that historically existed in Windows PowerShell 5.1. That reduces exposure to legacy parsing quirks.
• Improved usability for real scripting
  Many quality-of-life improvements: better error messages in some areas, new parameters/features over time, and a generally more modern scripting experience.
• Side-by-side safety
  You can keep using 5.1 for legacy tasks while using 7 for newer scripts. No need to “switch” everything at once.

Reasons you might NOT want to rely on PowerShell 7 for everything

• Module compatibility
  Some older Windows-only modules/components were written with Windows PowerShell 5.1 in mind and may not work correctly in 7 (or may require extra steps).
• Legacy admin scenarios
  Certain enterprise/older automation (and some vendor scripts) assume 5.1 behavior. In those cases, sticking with 5.1 for that specific task can be the safest path.

Practical recommendation

• Typical home user who rarely uses PowerShell: installing PowerShell 7 is optional. It won’t automatically make your system “more secure” if you never use it.
• Power user / sysadmin / you run scripts or learn PowerShell: install PowerShell 7 and use it as your default shell for new work, while keeping 5.1 available for compatibility.

Security note
No PowerShell version is “safe” if you run untrusted scripts. The main safety rule still applies: only run scripts you understand and trust, and treat copy-paste one-liners from random sites as high risk.

Conclusion: Installing PowerShell 7 on Windows 11 is generally recommended for anyone who actually uses PowerShell, because it’s modern, actively maintained, and works alongside 5.1 without breaking it.

 

[Sampei.Nihira]

@Bot
Installation from the Microsoft Store?

 

[Bot]

@Bot
Installation from the Microsoft Store?

Yes—installing PowerShell 7 from the Microsoft Store is generally a good option on Windows 11, as long as it’s the official listing from Microsoft.

Why the Microsoft Store install is a good choice

• Automatic updates (Store updates will keep PowerShell 7 current without you manually downloading new installers).
• Easy install/uninstall and typically fewer “leftovers.”
• Side-by-side by design (it won’t remove Windows PowerShell 5.1; PowerShell 7 runs as pwsh).

Security/verification tips

• In the Store listing, confirm the Publisher is Microsoft Corporation.
• Avoid third-party “PowerShell” lookalikes or repackaged builds.
• After install, you can confirm you’re running PowerShell 7 by launching pwsh and checking $PSVersionTable.

When you might prefer the MSI/ZIP instead of the Store

• If the Microsoft Store is blocked/disabled by policy.
• If you need a system-wide deployment approach (common in enterprises) with centralized packaging.
• If you want tighter control over update timing (Store auto-updates may be undesirable in some managed environments).

Alternative “official and simple” method
If you prefer not to use the Store UI but still want an official source, Windows 11’s built-in package manager is a good option:

winget install --id Microsoft.PowerShell -s msstore

Conclusion: Microsoft Store is a perfectly reasonable way to install PowerShell 7 on Windows 11, and it’s often the most convenient because of automatic updates—just make sure it’s the official Microsoft listing.

 

[Sampei.Nihira]

@Bot

I said it would be preferable from the Microsoft Store because it will have the right AppContainer, right?

 

[Bot]

@Bot

I said it would be preferable from the Microsoft Store because it will have the right AppContainer, right?

Not necessarily. “From the Microsoft Store” usually means “MSIX-packaged with package identity”, but it does not automatically mean the app runs inside an AppContainer sandbox.

Store app != always AppContainer
There are two common models for Store-distributed apps:

• UWP / sandboxed apps: run in AppContainer by default.
• Packaged desktop (Win32) apps: can be MSIX-packaged but still run as a normal desktop process (medium integrity / “full trust”), unless the developer explicitly configures the package to run in AppContainer. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/msix/msix-container?utm_source=openai))

PowerShell 7 is a classic desktop console app. In general, packaging classic desktop apps as MSIX commonly involves the restricted capability “runFullTrust” (meaning it’s not the UWP-style sandbox). ([learn.microsoft.com](https://learn.microsoft.com/en-us/answers/questions/1219524/how-to-remove-full-trust-capability-on-my-msix-pac?utm_source=openai))

So what do you actually gain from the Store version?
Even if it’s not AppContainer-sandboxed, the Store version is still attractive because:

• It’s an official Microsoft distribution channel.
• You get automatic updates (which is a real security benefit in practice).
• MSIX packaging tends to provide cleaner install/uninstall behavior and reliable package identity. ([learn.microsoft.com](https://learn.microsoft.com/lv-lv/windows/apps/package-and-deploy/packaging/?utm_source=openai))

How to verify whether PowerShell 7 is actually AppContainer on your PC
You can inspect the installed package manifest:

• Find the installed Store package:
  

  Get-AppxPackage Microsoft.PowerShell | Select Name, PackageFullName, InstallLocation

• Open the manifest at:
  

  <InstallLocation>\AppxManifest.xml

• Indicators:
  • AppContainer is typically indicated by settings like uap10:TrustLevel="appContainer" / “partial trust” style configuration. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/msix/msix-container?utm_source=openai))
  • Not AppContainer (full trust) is typically indicated by “full trust” desktop configuration (often alongside the runFullTrust capability in packaged desktop scenarios). ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/msix/msix-container?utm_source=openai))

Conclusion: preferring the Microsoft Store for PowerShell 7 is sensible for authenticity and automatic updates, but you shouldn’t assume it gives you an AppContainer sandbox unless you confirm it in the package manifest.

 

[Parkinsond]

Yes, for many Windows 11 users (especially anyone who runs scripts or administers systems), installing PowerShell 7 is a good idea. You can install it without “replacing” Windows PowerShell 5.1 because they run side-by-side.

Why PowerShell 7 can be worth installing

• Actively developed and updated
  PowerShell 7 continues to receive new features, bug fixes, and security hardening work. Windows PowerShell 5.1 is essentially “in-box” and mostly in maintenance mode.
• More modern engine (.NET)
  PowerShell 7 runs on modern .NET, which typically means better performance, better networking defaults, and fewer legacy dependencies (compared to the old Windows-only stack used by 5.1).
• Better defaults for web cmdlets (and fewer legacy components)
  In general, PowerShell 7 avoids the older Internet Explorer-based web parsing behavior that historically existed in Windows PowerShell 5.1. That reduces exposure to legacy parsing quirks.
• Improved usability for real scripting
  Many quality-of-life improvements: better error messages in some areas, new parameters/features over time, and a generally more modern scripting experience.
• Side-by-side safety
  You can keep using 5.1 for legacy tasks while using 7 for newer scripts. No need to “switch” everything at once.

Reasons you might NOT want to rely on PowerShell 7 for everything

• Module compatibility
  Some older Windows-only modules/components were written with Windows PowerShell 5.1 in mind and may not work correctly in 7 (or may require extra steps).
• Legacy admin scenarios
  Certain enterprise/older automation (and some vendor scripts) assume 5.1 behavior. In those cases, sticking with 5.1 for that specific task can be the safest path.

Practical recommendation

• Typical home user who rarely uses PowerShell: installing PowerShell 7 is optional. It won’t automatically make your system “more secure” if you never use it.
• Power user / sysadmin / you run scripts or learn PowerShell: install PowerShell 7 and use it as your default shell for new work, while keeping 5.1 available for compatibility.

Security note
No PowerShell version is “safe” if you run untrusted scripts. The main safety rule still applies: only run scripts you understand and trust, and treat copy-paste one-liners from random sites as high risk.

Conclusion: Installing PowerShell 7 on Windows 11 is generally recommended for anyone who actually uses PowerShell, because it’s modern, actively maintained, and works alongside 5.1 without breaking it.

Why did not Microsoft replace PowerShell 5.1 by PowerShell 7?

 

[Bot]

Why did not Microsoft replace PowerShell 5.1 by PowerShell 7?

Microsoft didn’t “replace” Windows PowerShell 5.1 with PowerShell 7 mainly because doing so would be a high-risk breaking change for Windows compatibility and enterprise automation.

1) Windows PowerShell 5.1 is part of the OS servicing model
Windows PowerShell 5.1 is an “in-box” Windows component that ships with Windows and is serviced like the OS.

PowerShell 7 is a separately installed product with its own fast release/update cadence. If Microsoft swapped the in-box shell to PowerShell 7, Windows would inherit a lot of compatibility risk and a much more complicated servicing story.

2) Different foundations: .NET Framework vs modern .NET

• Windows PowerShell 5.1 is built on the Windows-only .NET Framework.
• PowerShell 7 is built on modern .NET (cross-platform).

That sounds like a simple upgrade, but it changes runtime behavior, APIs, and module expectations. Lots of older scripts/modules implicitly depend on .NET Framework behaviors and Windows-only components.

3) Compatibility: modules, snap-ins, and “it must not break” automation
A huge amount of Windows/enterprise tooling was written and tested against 5.1 over many years. Replacing it could break:

• Older Windows-only modules (or modules that assume 5.1 behavior)
• Scripts that rely on legacy behaviors (output formatting quirks, parameter binding edge cases, old web parsing, etc.)
• Products that explicitly call “powershell.exe” and expect 5.1 semantics

Microsoft generally treats “default automation shell on Windows” as something that must remain extremely stable for admins and vendors.

4) Some Windows features and management workflows were designed around 5.1
Even where PowerShell 7 can do most tasks, Windows has long-standing management ecosystems built around Windows PowerShell (and, historically, Windows-only dependencies). Microsoft’s approach has been: keep 5.1 for maximum compatibility, offer 7 for modern scripting and new development.

5) Side-by-side is the lowest-risk path
By shipping PowerShell 7 side-by-side:

• Admins can adopt it gradually.
• Legacy scripts keep working in 5.1.
• New scripts can target 7 for improved features and ongoing updates.

Conclusion: Microsoft didn’t replace 5.1 with 7 because the backward-compatibility and servicing risks are too high; side-by-side lets them modernize PowerShell without breaking the massive existing Windows/enterprise automation base.

 

[Sampei.Nihira]

Not necessarily. “From the Microsoft Store” usually means “MSIX-packaged with package identity”, but it does not automatically mean the app runs inside an AppContainer sandbox.

Store app != always AppContainer
There are two common models for Store-distributed apps:

• UWP / sandboxed apps: run in AppContainer by default.
• Packaged desktop (Win32) apps: can be MSIX-packaged but still run as a normal desktop process (medium integrity / “full trust”), unless the developer explicitly configures the package to run in AppContainer. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/msix/msix-container?utm_source=openai))

PowerShell 7 is a classic desktop console app. In general, packaging classic desktop apps as MSIX commonly involves the restricted capability “runFullTrust” (meaning it’s not the UWP-style sandbox). ([learn.microsoft.com](https://learn.microsoft.com/en-us/answers/questions/1219524/how-to-remove-full-trust-capability-on-my-msix-pac?utm_source=openai))

So what do you actually gain from the Store version?
Even if it’s not AppContainer-sandboxed, the Store version is still attractive because:

• It’s an official Microsoft distribution channel.
• You get automatic updates (which is a real security benefit in practice).
• MSIX packaging tends to provide cleaner install/uninstall behavior and reliable package identity. ([learn.microsoft.com](https://learn.microsoft.com/lv-lv/windows/apps/package-and-deploy/packaging/?utm_source=openai))

How to verify whether PowerShell 7 is actually AppContainer on your PC
You can inspect the installed package manifest:

• Find the installed Store package:
  

  Get-AppxPackage Microsoft.PowerShell | Select Name, PackageFullName, InstallLocation

• Open the manifest at:
  

  <InstallLocation>\AppxManifest.xml

• Indicators:
  • AppContainer is typically indicated by settings like uap10:TrustLevel="appContainer" / “partial trust” style configuration. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/msix/msix-container?utm_source=openai))
  • Not AppContainer (full trust) is typically indicated by “full trust” desktop configuration (often alongside the runFullTrust capability in packaged desktop scenarios). ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/msix/msix-container?utm_source=openai))

Conclusion: preferring the Microsoft Store for PowerShell 7 is sensible for authenticity and automatic updates, but you shouldn’t assume it gives you an AppContainer sandbox unless you confirm it in the package manifest.

I checked with PE and the Integrity Level is medium.

 

[Bot]

I checked with PE and the Integrity Level is medium.

A Medium Integrity Level is a strong hint that the PowerShell 7 process you’re looking at is running as a normal “full trust” desktop process, not in an AppContainer sandbox.

Why Medium IL matters (and what it doesn’t prove)

• AppContainer-sandboxed processes are typically Low integrity (they’re intentionally constrained).
• Packaged Win32 apps (MSIX/Desktop Bridge style) commonly still run Medium integrity because they are “full trust” desktop apps, just with package identity.

So Medium IL usually aligns with: “packaged, but not AppContainer-sandboxed.”

How to confirm AppContainer vs full trust (more reliable than IL)
If you’re using Process Explorer (or a similar tool), add/check these columns:

• AppContainer (Enabled/Disabled)
• Package name (shows it has package identity)
• Integrity (you already checked this)

Typical outcomes:

• Package name present + AppContainer = Disabled + Integrity = Medium
  = Packaged full-trust Win32 app (most likely what you’re seeing with PowerShell 7 from the Store).
• AppContainer = Enabled (often with Low IL)
  = Actually running inside an AppContainer sandbox.

Security takeaway
Installing PowerShell 7 from the Microsoft Store is still beneficial for authenticity and automatic updates, but Medium IL suggests you should not assume you gained an AppContainer sandbox.

If your goal is to reduce PowerShell abuse risk, AppContainer isn’t the main lever anyway; better defenses are things like Microsoft Defender’s protections (AMSI integration helps), Attack Surface Reduction rules, WDAC/AppLocker, and limiting untrusted script execution (script signing where practical).

 

[Sampei.Nihira]

@Bot

For occasional use, do you recommend version 7 or the pre-installed version 5?

 

[Bot]

@Bot

For occasional use, do you recommend version 7 or the pre-installed version 5?

If your use is truly occasional, you can safely stick with the pre-installed Windows PowerShell 5.1, and only add PowerShell 7 if you have a specific benefit you want.

When 5.1 is the better choice (occasional Windows-only tasks)

• Maximum compatibility with older scripts and Windows-focused modules that were built/tested for 5.1
• Many built-in admin examples you find for Windows still assume 5.1 behavior
• You already have it, so there’s nothing to maintain

When PowerShell 7 is the better choice (even for occasional use)

• You want the “current” PowerShell going forward (new features and fixes)
• You run modern scripts that expect pwsh/PowerShell 7
• You want to avoid legacy behaviors where possible (5.1 has more legacy components/history)
• You like having it updated automatically (especially if installed from the Microsoft Store)

Practical approach that works well

• Keep using 5.1 for anything that’s Windows-legacy or module-sensitive (launch: powershell.exe)
• Use 7 for new scripts and general interactive work (launch: pwsh)

Conclusion: for occasional use, 5.1 is fine and simplest; if you do run scripts now and then, installing PowerShell 7 is worthwhile and low-risk because it runs side-by-side, and you can choose per task.

 

[Victor M]

Typical MS, leaves old things behind. You have to know that a new thing is available and switch manually. No automatic migration. Thats why we are still compatible with Windows XP and all its insecurities. In the Linux Fedora world, we drop old tech and everyone moves forward. Don't want to learn new things - stick with red hat. And you pay for that 'privilege'. It is for that old generation that still believes in 'maximizing on tech investments'. Heck, even Cobol became Object Cobol. Tech is tech, it moves forward.

 

[Sampei.Nihira]

I'm leaving Powershell 7.5.4 installed.

 

[Sampei.Nihira]

I changed the Windows PowerShell command line in the command prompt settings to the PowerShell 7 command line.
This opens pwsh:

Spoiler: Windows Powershell

Spoiler: Powershell 7

 

[TairikuOkami]

Typical MS, leaves old things behind.

MS has recently deprecated PS2, after a decade, maybe in another decade, it will deprecate PS5 in favor of PS7 with PS10 around already.

 

[Parkinsond]

MS has recently deprecated PS2, after a decade, maybe in another decade, it will deprecate PS5 in favor of PS7 with PS10 around already.

May be in W 12; I doubt in 11.