PowerShell 5.1 Web Content Parsing: Security Prompt and UseBasicParsing Guide

Windows PowerShell 5.1 now stops and asks for confirmation before it will parse web pages in a way that could execute scripts found in that content — a safety-first change that will affect interactive use and any automation that previously relied on the old, IE‑backed HTML DOM parsing behavior.

Overview​

Windows updates released on and after December 9, 2025 change the default behavior of Invoke‑WebRequest in PowerShell 5.1 so that, when no explicit parsing mode is chosen, PowerShell pauses and displays a security confirmation prompt warning that parsing the page may run scripts found in the page. The default, safe option cancels the operation; if you accept the risk you can continue and allow legacy parsing. Microsoft’s guidance is to use the -UseBasicParsing switch for non‑interactive workflows and to refactor code that depends on full DOM parsing for long‑term safety. This article explains what changed, why Microsoft implemented the prompt, the practical impact on interactive and automated workflows, concrete remediation steps for admins and scripters, and longer‑term migration options to avoid dependency on obsolete IE‑based parsing. It also highlights real risks and common pitfalls that administrators should test for before wide deployment.

---

Background: how Invoke‑WebRequest parsed pages before​

The old model (PowerShell 5.1 and earlier)​

Historically, when you used Invoke‑WebRequest without opting into basic parsing, PowerShell 5.1 attempted to populate a DOM object (the ParsedHtml property) using the Internet Explorer engine (mshtml). That approach offered a convenient DOM-like object model accessible from PowerShell, but it carried two structural problems:

• It relied on an Internet Explorer component that is deprecated and fragile on modern systems.
• DOM population can cause execution of page scripts (or trigger first‑run IE dialogs), creating a trust boundary where untrusted web content could lead to code execution consequences.

Those design facts are why Microsoft and the PowerShell team have moved the web cmdlets toward a “no‑script” default parsing mode in newer PowerShell versions and are now hardening the behavior of PowerShell 5.1 via a Windows update.

The safe alternative: -UseBasicParsing​

The -UseBasicParsing switch instructs Invoke‑WebRequest to not attempt DOM parsing with the IE engine. Instead it returns raw content, headers, status codes and simple properties without executing or loading scripts from web pages. Historically it was a quick workaround for server‑core environments (or when IE hadn’t been initialized for the account running the script), and in PowerShell Core (6+) basic parsing is the default. Microsoft now recommends using -UseBasicParsing as the safe default in PowerShell 5.1 scripts.

---

What Microsoft changed (concise summary)​

• PowerShell 5.1 will now display a security prompt during Invoke‑WebRequest calls that would otherwise trigger DOM parsing with the IE engine, warning that script code might execute during parsing. The default answer is to cancel.
• Interactive users can opt in to legacy behavior by confirming the prompt (not recommended for untrusted pages). For automation, Microsoft recommends explicitly specifying safe parameters so the prompt does not block non‑interactive runs.
• The single recommended mitigation for existing scripts is to update Invoke‑WebRequest invocations to include -UseBasicParsing; for code that truly needs DOM features, refactor to safer parsing libraries or migrate to PowerShell 7+ which avoids IE altogether.

---

Practical impact: interactive sessions vs. automated scripts​

Interactive sessions (admins, pundits, one‑liners)​

• You will see a one‑time prompt when running Invoke‑WebRequest without specifying parsing mode. Pressing Enter (or choosing No) cancels the operation; choosing Yes resumes legacy parsing. This is intentional — it forces a conscious decision when the session would allow DOM parsing of potentially hostile content.
• For frequent interactive tasks where DOM parsing is unnecessary, make a habit of adding -UseBasicParsing to your commands or set a session default (see below). This preserves the convenience of the response object’s essential fields while avoiding script execution risks.

Automated scripts, scheduled tasks, CI/CD pipelines​

• Scripts that run unattended will hang on the security prompt unless updated. Microsoft explicitly warns that this prompt will stop non‑interactive runs if the script does not pre‑select a safe behavior. Administrators must update scripts to include -UseBasicParsing or implement a different parsing solution.
• The required change is typically a one‑line edit: add -UseBasicParsing to every Invoke‑WebRequest call that does not require the ParsedHtml DOM. For scripts that do require DOM features, plan a refactor or migration (see the migration section).

---

Immediate remediation steps (checklist for sysadmins)​

• Inventory scripts that call Invoke‑WebRequest.
• Search repositories, scheduled tasks, and automation platforms for Invoke‑WebRequest usage.
• Prioritize automation runs and service‑account scripts where a prompt could hang execution.
• Quick fix for simple downloads / text retrieval:
• Add -UseBasicParsing to the Invoke‑WebRequest call.
• Example: Invoke‑WebRequest -Uri 'https://example.com/data' -OutFile 'C:\temp\data.html' -UseBasicParsing
• If you must preserve DOM parsing in a trusted, interactive context:
• Leave user workflows to explicitly consent to the prompt when they intentionally run interactive DOM parsing; do not automate consent.
• Document trusted sites and limit usage to internal, controlled endpoints.
• For session‑wide convenience (temporary): set a default parameter for the current session or profile so -UseBasicParsing is applied automatically:
• Example (session or add to user profile):
  $PSDefaultParameterValues['Invoke-WebRequest:UseBasicParsing'] = $true
• This ensures every Invoke‑WebRequest call in that session uses basic parsing unless explicitly overridden. Persist that line in your $PROFILE to make it permanent for that account.
• Test changes in a staging environment before rolling to production.
• Validate that the script’s downstream logic does not depend on properties that exist only when DOM parsing is used (such as .ParsedHtml or .Images). If they do, refactor (next section).

---

When -UseBasicParsing is not enough: refactor paths​

If your code relies on DOM features — for example to populate form fields, query complex HTML nodes, or interact with scripts/forms in the page — you have three safe, supported alternatives:

• Modernize to PowerShell 7+ (PowerShell Core): its web cmdlets use basic parsing by default and do not depend on Internet Explorer, eliminating the IE‑based attack surface. Microsoft calls out that PowerShell 7 already defaults to safe parsing.
• Use a dedicated HTML parsing library:
• HtmlAgilityPack (via .NET) or AngleSharp are well‑known, robust HTML parsers that do not execute scripts. The pattern is: fetch raw content with Invoke‑WebRequest (or Invoke‑RestMethod), then parse it with a library that treats HTML as data rather than executable code.
• Rework automation to use APIs:
• If the web service exposes an API (REST/JSON), switch to Invoke‑RestMethod or direct HTTP libraries and parse JSON responses. Where possible, prefer API endpoints to scraped HTML — they are less fragile and inherently safer.

Microsoft’s recommendation is explicit: refactor scripts that interact with untrusted content instead of re‑enabling legacy parsing globally. This is the long‑term, secure approach.

---

Concrete examples and patterns​

Simple download (safe)​

• Before (might trigger prompt):
  Invoke-WebRequest -Uri 'https://example.com/file.zip' -OutFile 'C:\temp\file.zip'
• After (explicit safe mode):
  Invoke-WebRequest -Uri 'https://example.com/file.zip' -OutFile 'C:\temp\file.zip' -UseBasicParsing

Session default (convenience, add to profile)​

• Add this to the user or service account profile to make basic parsing automatic for Invoke‑WebRequest in that session:
  $PSDefaultParameterValues['Invoke‑WebRequest:UseBasicParsing'] = $true
  (Persist the same line in $PROFILE to apply it every time that account starts PowerShell.

When DOM is required (refactor pattern)​

• Fetch raw HTML safely:
  $resp = Invoke-WebRequest -Uri 'https://intranet.example.local/page' -UseBasicParsing
• Parse with a library (pseudocode):
  $doc = [HtmlAgilityPack.HtmlDocument]::new
  $doc.LoadHtml($resp.Content)
  $node = $doc.DocumentNode.SelectSingleNode("//div[@id='data']")

This pattern keeps parsing out of the browser engine and prevents script execution.

---

Operational guidance for enterprises​

• Run a short discovery sweep: find all occurrences of Invoke‑WebRequest across codebases and scheduled job definitions, and classify them by whether they need DOM parsing. Use source control search and configuration management data to accelerate discovery.
• Treat the update as a breaking‑change window for legacy scraping code. Plan test cycles and contact module maintainers for third‑party code that relies on ParsedHtml.
• Use group policy / configuration management to roll the PowerShell update to a test ring first, then to production once scripts have been adapted. Microsoft’s support guidance explicitly positions this change as a security hardening and recommends staged rollout.
• Consider blocking mshta.exe or restricting script interpreters in higher‑risk environments and instead provide approved service accounts and hardened automation hosts with controlled profiles for tasks that must interact with trusted HTML only. This aligns with broader PowerShell hardening guidance from the PowerShell team.

---

Known edge cases and migration pain points​

• First‑run Internet Explorer prompts: some service accounts or system contexts have never completed the IE first‑run config. Legacy Invoke‑WebRequest calls could previously produce those dialogs; -UseBasicParsing avoids that, but scripts depending on IE session artifacts will break. This is common in SQL Agent jobs and system service contexts. Test service accounts explicitly.
• Differences in returned object model: switching to -UseBasicParsing changes what properties the cmdlet returns. Scripts that access .ParsedHtml, .Images, or similar DOM‑derived properties will no longer find them. Expect to modify subsequent code that relied on those properties.
• Some legacy internal tools may have been written around behaviors that implicitly relied on scripts running during parsing. Those tools should be refactored or run in a strictly controlled, manual way where the prompt’s confirmation is acceptable. Microsoft warns against re‑enabling legacy parsing broadly.
• Bugs and inconsistent behavior in 5.1: Invoke‑WebRequest has historically shown inconsistent behavior across OS versions because of the IE dependency; this change reduces that class of flakiness but can expose code that had accidentally relied on IE side effects. Test across OS/builds.

---

Detection, monitoring and security context​

This change is part of a broader PowerShell hardening movement: treat web content as untrusted input and avoid executing code from the network without explicit consent. The PowerShell team and security practitioners emphasize:

• Enable Script Block Logging and PowerShell logging in enterprise telemetry to detect suspicious invocations.
• Assume web‑fetched content may be hostile, and require explicit developer/owner sign‑offs for any legacy parsing opt‑ins.
• Use allow‑listing and least privilege for automation hosts that must interact with web content.

---

Cross‑reference and verification​

• Microsoft’s official support note explains the security prompt behavior, the recommended use of -UseBasicParsing, and the suggested migration/refactor options. The article was published alongside the Windows update rollout and documents the behavior for PowerShell 5.1 on supported Windows versions.
• The PowerShell team has long documented the threat model around script execution and the rationale for treating downloaded web content as untrusted input; their security guidance frames this change as consistent with long‑standing security principles for the shell.
• Community resources and Q&A (for example, expert answers on widely used forums) capture the historical behavior of Invoke‑WebRequest using IE’s DOM and the practical role -UseBasicParsing has played as a workaround. Those community discussions also record common migration headaches administrators have encountered. When planning migration, validate behavior in your environment — community reports illustrate the kinds of problems you may see and offer pragmatic fixes.

Note: where community posts describe anecdotal edge cases, treat them as signals to test, not as authoritative guarantees; validate in your lab before applying changes broadly.

---

Recommended next actions (prioritized)​

• Immediately scan automation repositories and scheduled tasks for Invoke‑WebRequest and tag each occurrence as “download/text only” or “requires DOM”.
• For “download/text only”, add -UseBasicParsing and run test suites; commit changes and update deployment artifacts.
• For “requires DOM”, catalog those scripts and plan one of:
• refactor to use a safe HTML parser;
• migrate the job to PowerShell 7 on a host where core is supported; or
• run interactively only after explicit human confirmation (not recommended for automation).
• For service accounts, ensure $PROFILE contains session defaults as appropriate, or centrally manage profile config in automation images.
• Communicate the change to application owners and operators, highlighting that unattended scripts will hang if they are not updated.

---

Final analysis: benefits, tradeoffs, and risk summary​

• Benefits
• Security first: The new prompt prevents silent execution of scripts embedded in web content, closing a class of surprising attack vectors that could be abused by social engineering or malicious web content.
• Consistency with PowerShell Core: Aligns PowerShell 5.1 behavior toward the safer default used in PowerShell 6/7, reducing surprises when migrating to modern PowerShell.
• Tradeoffs / Risks
• Automation breakage: Unupdated unattended scripts will hang; this requires careful inventory and patching before updates roll out broadly.
• Refactoring cost: Scripts that relied on DOM parsing may need non‑trivial rewrites or library additions to preserve functionality without reintroducing risk. Plan and budget for this work.
• Operational friction: Admins used to one‑liners that scrape pages interactively will now need to be explicit about their risk choices, which is safer but initially disruptive.
• Overall assessment
• The change is security appropriate and aligns with long‑term goals (remove dependence on deprecated IE components and avoid executing untrusted page scripts). The immediate operational burden is real but manageable: a disciplined inventory, a few mechanical script edits (adding -UseBasicParsing), and targeted refactoring will resolve the bulk of issues.

---

PowerShell is a powerful automation tool; this update forces a safer default when consuming web content — a change that reduces attack surface at the cost of predictable, manageable migration work for automation owners. Prioritize inventory, apply -UseBasicParsing where DOM parsing isn’t required, and plan a staged refactor or PowerShell 7 migration for the remaining cases.

---

Source: Microsoft Support PowerShell 5.1: Preventing script execution from web content - Microsoft Support

 

[ChatGPT]

Windows PowerShell is now pausing to warn users when web content fetched with Invoke-WebRequest could execute scripts, a defensive change delivered in Microsoft’s December 2025 security updates that aims to block a high‑severity remote code execution path and force explicit, safer choices for automation and interactive use.

Background​

Microsoft shipped the behavior change as part of its December 9, 2025 updates for Windows and PowerShell 5.1, surfaced in KB5074204 and a companion advisory titled “PowerShell 5.1: Preventing script execution from web content.” The update introduces an interactive confirmation prompt when Invoke‑WebRequest (and aliases such as curl) would otherwise perform full DOM parsing with the old Internet Explorer / mshtml engine. This prompt warns about Script Execution Risk and recommends using the -UseBasicParsing switch to avoid running embedded page scripts. The change is explicitly tied to remediation for CVE‑2025‑54100 — a command‑injection / remote code execution issue in PowerShell where parsing a web page could allow code to execute. The CVE was published in Microsoft’s advisories and is listed in the NVD. Microsoft frames the change principally as protection for enterprise and managed environments that run large volumes of automation, while noting the impact on home users is typically limited.

---

What changed (technical overview)​

How Invoke‑WebRequest parsed pages before​

PowerShell 5.1 historically used Windows’ Internet Explorer HTML parsing components (mshtml) when Invoke‑WebRequest performed full HTML/document parsing. That meant the cmdlet could return a rich Document Object Model (DOM) object, allowing scripts to interact with forms, DOM elements, and embedded scripts — behavior some scripts relied upon for scraping or automated site interaction. However, that dependency also meant the cmdlet executed the same parsing pathways that could trigger script execution in page content.

New behavior in PowerShell 5.1 after the update​

After installing the December 2025 PowerShell update, running Invoke‑WebRequest without explicit safe parameters causes PowerShell to display a console confirmation that the fetched page could include script code that might run when parsed. By default the prompt cancels the operation (press Enter or choose No), and recommends re‑running with -UseBasicParsing to safely fetch content without executing embedded scripts. Choosing Yes allows legacy, full DOM parsing to proceed (and with it, the previous risk). This confirmation appears in interactive sessions; non‑interactive scripts that don’t opt in to safe parsing can hang awaiting input.

---

Why Microsoft made the change​

• To close or mitigate a remote code execution vector tied to HTML parsing and command injection (CVE‑2025‑54100). The change shifts the secure default toward not executing page scripts implicitly.
• To reduce silent execution of scripts embedded in web content when tools fetch pages for automation or scraping.
• To push administrators and script authors toward explicit, safer parsing choices or modern tooling (PowerShell 7+ or dedicated HTTP libraries).

This is a deliberate movement away from implicit “rich” parsing toward a safer, explicit model that requires authors to choose legacy behavior only when they trust the content.

---

What administrators and script authors need to know​

Immediate operational impact​

• Interactive users in consoles will see a confirmation prompt when using Invoke‑WebRequest (including the curl alias). For most one‑off fetches, users can choose No and re‑run with -UseBasicParsing to fetch content safely.
• Automated scripts, scheduled tasks, CI pipelines, or any non‑interactive processes calling Invoke‑WebRequest without -UseBasicParsing may hang or fail because the updated cmdlet will pause for confirmation. Administrators must update automation to avoid unexpected failures.
• Scripts that depend on legacy DOM parsing (forms, complex scraping using mshtml) will require refactoring or explicit opt‑in to legacy behavior on trusted content.

Recommended quick fixes​

• Add -UseBasicParsing to Invoke‑WebRequest calls where you only need the response body, headers, or to download files:
• Example: Invoke‑WebRequest -Uri 'Example Domain' -OutFile 'page.html' -UseBasicParsing
• For JSON APIs or REST endpoints, prefer Invoke‑RestMethod which returns parsed objects for API responses and is generally safer for data interactions.
• For complex HTML parsing or scraping, migrate to non‑mshtml parsers (e.g., HTML Agility Pack, AngleSharp, or simple regex/XML parsing when appropriate), or run scripts on PowerShell 7+ which does not use the legacy IE engine.

Detection: find affected scripts quickly​

• Search repositories and file shares for common patterns:
• In PowerShell codebases: search for Invoke‑WebRequest, iwr, curl (the alias), wget (alias).
• Example command to find occurrences in a codebase:
• Get-ChildItem -Recurse -Filter *.ps1 | Select-String -Pattern 'Invoke-WebRequest|iwr|curl\s|wget\s'
• Audit scheduled tasks and services that execute PowerShell scripts to ensure they won’t block on the new prompt.

---

Exact behavior of the confirmation prompt​

The update surfaces a console message warning that parsing the web page could run script code and recommends -UseBasicParsing to avoid script execution. The default action (press Enter or No) cancels, instructing the user to re‑run with the safer switch; selecting Yes resumes legacy full parsing. Administrators should assume that any script not explicitly using -UseBasicParsing may be impacted and update accordingly.

---

The curl alias — why it matters​

PowerShell 5.1 (the Windows built‑in PowerShell) historically provides aliases such as curl, wget, and iwr that map to Invoke‑WebRequest. That means shell users typing curl on older Windows PowerShell may actually be invoking Invoke‑WebRequest, and the new confirmation behavior applies to those invocations too. This aliasing changed in PowerShell Core / PowerShell 7+, where curl is the actual curl.exe utility if present. Check your environment: use Get‑Command curl or call curl.exe explicitly if you need the native curl binary.

---

Security analysis and threat scenarios​

What was the risk?​

The core issue addressed is that full DOM parsing using mshtml could result in script execution paths that an attacker could exploit by serving crafted web content, leading to command injection or code execution on the host that performed the fetch. That vulnerability has been tracked as CVE‑2025‑54100 and assessed as high severity by vendors and public vulnerability trackers.

Realistic attack vectors​

• A malicious actor controls or poisons a web endpoint that is routinely scraped by automated processes or scheduled tasks. When the task fetches and parses the page using legacy DOM parsing, embedded malicious script elements could be executed, enabling arbitrary actions.
• Supply‑chain or internal intranet attacks where poorly protected automation engages with internal web services that an attacker can compromise or spoof.

How the update reduces risk​

By requiring user consent before full parsing and promoting -UseBasicParsing, the change prevents silent execution of page scripts. For automation, the recommended pattern is to explicitly opt for safe parsing (thus avoiding the prompt and the execution path) or migrate to tooling that never evaluates page scripts as code. That reduces the attack surface significantly for both public and internal content retrieval tasks.

Limitations and residual risks​

• Choosing Yes at the prompt or embedding legacy parsing in scripts still leaves environments exposed; Microsoft recommends restricting legacy usage to trusted internal pages only.
• If administrators globally disable prompts or automate interactive consent via unsupported hacks, they could reintroduce the vulnerability. Any such workaround should be considered risky and temporary.
• The update mitigates the class of exploit associated with this parsing path, but other vectors remain — such as malicious modules, unsafe deserialization, or insecure remoting — and require separate controls.

---

Migration guidance: concrete steps and patterns​

Short term (next 24–72 hours)​

• Inventory: Run a search for Invoke‑WebRequest and aliases across your script repository and scheduled tasks.
• Patch: Ensure machines are updated with the December 2025 security rollups that include KB5074204 and the PowerShell advisory. Confirm which hosts have hotpatches applied.
• Update automation: Add -UseBasicParsing to non‑interactive Invoke‑WebRequest calls or replace them with safe alternatives.

Medium term (weeks)​

• Refactor scripts that depend on DOM features:
• Replace mshtml‑dependent logic with HTML parsers that do not execute scripts.
• For REST APIs and JSON endpoints, switch to Invoke‑RestMethod for native parsing of response data.
• Test: Run unit and integration tests on staging environments with the updated behavior to catch functional regressions.

Long term (months)​

• Migrate to PowerShell 7.x (PowerShell Core): modern PowerShell versions do not rely on IE/mshtml and provide cross‑platform consistency and improved security models.
• Adopt libraries for scraping: use HtmlAgilityPack, AngleSharp, or robust headless browsers with controlled JavaScript execution where necessary (but only when trusted).
• Implement defensive coding standards: avoid reliance on shell aliases in scripts, prefer explicit cmdlet names, and document the parsing intent in code.

---

Sample conversions and code snippets​

• Download a page safely (no DOM parsing):
• Invoke‑WebRequest -Uri 'Example Domain' -OutFile 'page.html' -UseBasicParsing
• Query a JSON API (use Invoke‑RestMethod):
• $data = Invoke‑RestMethod -Uri 'https://api.example.com/data' -UseBasicParsing
• Detect alias usage and replace in bulk (example scan):
• Get‑ChildItem -Recurse -Filter *.ps1 | Select‑String -Pattern '(^|\s)(Invoke‑WebRequest|iwr|curl\s|wget\s)' | Group‑Object Path
• If you must preserve DOM behavior for trusted internal pages, prefer manual inspection and limit the operation to a controlled environment rather than rolling legacy parsing into broad automation.

---

Testing and validation​

• Test in an isolated environment before rolling changes wide: spin up a test host, apply the security update, and run common automation tasks to identify blocking points.
• Create a minimal test script that replicates your production behavior and add assertion checks to validate whether the response object shape has changed after switching to -UseBasicParsing.
• For CI/CD pipelines, add a test stage that runs at least once with the updated PowerShell runtime so pipeline breakage is caught early.

---

Practical recommendations for Windows administrators​

• Treat this update as a required operational change: prioritize patching and inventorying scripts in the same maintenance window.
• Standardize on explicit command names and parameters in scripts to reduce ambiguity introduced by aliases.
• Implement logging around all web‑fetch operations so any change in response content or failures due to the prompt are visible and traceable.
• If third‑party modules or vendor scripts use Invoke‑WebRequest without explicit parameters, contact vendors for updates or wrap the module calls with safe parsing options.

---

Critical assessment — strengths and tradeoffs​

Strengths​

• The new default tightens security posture without requiring immediate large‑scale refactoring for many simple use cases (download-only and API calls).
• It forces explicit opt‑in for legacy behavior, reducing accidental code execution and raising administrator awareness.
• Aligns PowerShell 5.1 behavior closer to PowerShell 7.x security expectations and modern HTTP handling patterns.

Tradeoffs and risks​

• Automation brittleness: existing scheduled tasks and unattended scripts may break or hang, requiring administrative intervention to update scripts.
• Potential performance or functionality loss: -UseBasicParsing deliberately returns fewer DOM conveniences; scripts relying on mshtml features will need rework.
• Administrative overhead: large organizations with many legacy scripts face nontrivial effort to identify and correct all affected code paths.
• User confusion: interactive users who expect legacy behavior may inadvertently opt into risky parsing by selecting Yes; organizations should train helpdesk and operations teams about the change.

---

Unverifiable or open items to watch​

• Some third‑party scripts and community modules might document behaviors or workarounds that are not centrally maintained; administrators should treat those as unverified and test before deploying.
• Any claim about the total number of affected systems or scripts across the ecosystem is inherently unverifiable without direct telemetry; conclusions about global impact should therefore be qualified until organizations run their own inventories.

---

Final verdict and action checklist​

Microsoft’s decision to prompt on Invoke‑WebRequest full parsing is a pragmatic security hardening that protects against a concrete remote code execution vector while nudging the community toward safer parsing practices and modern PowerShell usage. The update reduces silent risk at the cost of short‑term operational work to update automation.
Action checklist:

• Patch endpoints with KB5074204 and companion advisories.
• Inventory scripts for Invoke‑WebRequest, iwr, curl (alias), and wget usages.
• Update non‑interactive automation to include -UseBasicParsing or migrate to safer alternatives.
• Test and refactor DOM‑dependent scripts using modern parsing libraries or move to PowerShell 7+.
• Educate operators and document any trusted exceptions where legacy parsing is permitted.

This change is the kind of small, targeted hardening that pays off: it clamps down on a specific attack surface while giving administrators a clear path to remediation. The work required to adapt will be real for many organizations, but the alternative — continuing to allow implicit script execution when fetching web content — is a higher risk than the migration burden.

---

PowerShell administrators and script authors should treat the December 2025 updates as both a patch and an invitation to modernize web‑fetch patterns: explicit is safer, and safer is what the web environment now demands.

---

Source: Windows Report Windows PowerShell Now Warns About Risky Web Scripts

 

[ChatGPT]

Microsoft has quietly released KB5074204, a targeted security update for Windows PowerShell 5.1 that injects a behavioral safeguard into the frequently abused web‑facing cmdlet pipeline: after installation, the Invoke‑WebRequest command now displays an explicit confirmation prompt warning of the risk that scripts embedded in retrieved web content could execute during parsing; users must explicitly continue or cancel the operation. This hotpatch, published on December 9, 2025, applies only to devices enrolled in Microsoft’s Hotpatch program for the Windows 11 servicing families referenced in the advisory and ships as updated PowerShell binaries tied to OS build reporting numbers.

Background and overview​

PowerShell has been a cornerstone of Windows automation for well over a decade. Its flexibility and deep system access make it indispensable for administrators and developers — and equally valuable to attackers who weaponize small, one‑line download‑and‑execute patterns such as piping remote content into Invoke‑Expression (iex). Microsoft’s December hotpatch responds to that predictable attack surface with a narrow, behavior‑level mitigation: interrupt the silent download‑and‑parse flow so a human operator must consciously accept the risk before the runtime proceeds to parse HTML and any embedded script content. The vendor frames the change as a fix tied to CVE‑2025‑54100 and documents companion guidance for preventing script execution from web content in PowerShell 5.1. This update is not a general‑purpose hardening of PowerShell or a change to execution policy. It is a tactical mitigation delivered as a hotpatch to Hotpatch‑enrolled SKUs and servicing tracks: Windows 11 Enterprise LTSC 2024, and Windows 11 Enterprise and Education versions 24H2 and 25H2, advanced to file and build versions listed in the KB. The install footprint is deliberately small — resource DLLs and the Microsoft.PowerShell.Commands.Utility module are updated — and Microsoft reports no known issues at publication time.

---

What KB5074204 actually changes​

The functional change — Invoke‑WebRequest prompts​

• Behavioral shift: After installing KB5074204, invoking Invoke‑WebRequest to retrieve and parse web pages in PowerShell 5.1 will result in a modal confirmation prompt. The prompt warns that scripts embedded in the page could run during parsing and suggests safer alternatives (for example, using the -UseBasicParsing parameter to avoid HTML/script parsing). Users must explicitly accept to continue.
• Why this matters: Historically, Invoke‑WebRequest could parse a page’s HTML and execute or trigger embedded script activity (through legacy parsing paths). Attackers have used that to make “download and run” cradles where a single command fetches a remote payload and hands it to the interpreter without human intervention. This confirmation inserts a user‑visible friction point into an otherwise silent operation, raising the probability that suspicious activity is halted by an operator rather than executed automatically.

Packaging and scope​

• Hotpatch delivery only: The KB explicitly states the update applies only to devices enrolled in the Hotpatch program. Hotpatching is Microsoft’s low‑disruption channel for narrowly scoped security fixes that can be applied without a system restart on eligible devices (subject to session constraints). Non‑Hotpatch devices will not receive this hotpatch via the same path.
• Target OS builds and files: The published file list includes updated PowerShell resource DLLs and a Microsoft.PowerShell.Commands.Utility.dll with file version 10.0.26100.7456 (and corresponding ARM64 versions), with timestamps in early December 2025. Administrators can use those file attributes and reported OS build numbers (CurrentBuildNumber and UBR) to verify installation.

Security linkage​

• CVE mapping: Microsoft ties the behavioral change to CVE‑2025‑54100 and references additional guidance in KB5074596, “PowerShell 5.1: Preventing script execution from web content,” which expands on safer usage and migration options. The public KB does not claim broad exploitation but frames this as a mitigation for a recognized risky pattern.

---

Why this change is significant (and immediately useful)​

Reducing the low‑cost, high‑impact abuse pattern​

Attackers thrive on low‑friction primitives. A short PowerShell one‑liner that downloads a remote script and executes it (often via iex) is one of the simplest paths to compromise, lateral movement, or persistence. The new confirmation prompt forces an explicit step in that chain, converting silent automation into a moment that can be observed, questioned, or blocked by a human operator or an automation monitoring agent. That single change can measurably reduce successful opportunistic abuse, particularly against non‑targeted phishing campaigns and commodity scripts.

Complements existing Windows defenses​

The mitigation is additive, not replacement‑grade. It works alongside:

• EDR and endpoint protections that detect suspicious download patterns.
• Script Block Logging and transcription features that produce forensic evidence.
• Constrained Language Mode, AppLocker, or Windows Defender Application Control (WDAC) for policy enforcement.
• Migrating to PowerShell 7.x / PowerShell Core, which provides different cmdlet behaviors and improved security controls for modern scripting.

Administrators should view the hotpatch as an additional layer that reduces the probability of human error leading to immediate remote code execution.

---

Operational impact and risks​

Automation breakage is the primary operational risk​

The change inserts an interactive prompt into a widely used command. That interaction is excellent for reducing the human‑factor risk but is harmful to unattended automation. Common practical impacts include:

• Unattended scripts and scheduled tasks that call Invoke‑WebRequest will hang or fail if run under contexts that cannot respond to interactive prompts (for example, scheduled tasks running as SYSTEM or services).
• CI/CD pipelines and deployment scripts that scrape web pages or fetch remote artifacts and expect immediate parsing will stall.
• Legacy web-scraping toolchains that relied on Invoke‑WebRequest’s parsing and DOM behavior may require refactoring.

Community guidance and practical checklists recommend inventorying scripts, identifying those that rely on interactive one‑liners, and applying remediation steps before deploying the hotpatch broadly.

Hotpatch eligibility and servicing fragility​

Because KB5074204 is delivered only to Hotpatch‑enrolled devices, coverage is not universal. Hotpatch enrollment requires specific licensing and baseline conditions; misapplied updates from other servicing channels can change a device’s servicing track and remove Hotpatch eligibility. Recent servicing incidents have shown that multi‑channel complexity (LCU, SSU, Hotpatch, OOB fixes) can be brittle and, in rare cases, require remediation. Administrators should confirm enrollment and verify that the hotpatch will actually reach the intended fleet before relying on it as the only mitigation.

UX and training considerations​

• User confusion: Operators seeing the new prompt may be uncertain how to respond. Clear messaging and internal training are necessary — explain that the prompt is expected behavior after the update and that choosing “No” is the safest default for unknown pages.
• Security vs. convenience tradeoff: For interactive support technicians, the extra click is minor; for automation owners, it can mean rework. The organization must weigh convenience loss against the reduced attack surface.

---

Concrete, prioritized recommendations for administrators​

Apply the following checklist to plan, pilot, and deploy KB5074204 safely across your estate.

• Inventory the estate for Hotpatch eligibility:
• Query licensing, enrollment policies (Intune/Windows Autopatch/Azure Update Manager), and baseline OS builds to determine which devices will receive the hotpatch. Hotpatch applies only to certain SKUs and devices enrolled for Hotpatch.
• Discover automation that calls Invoke‑WebRequest:
• Use code‑search across repositories, scheduled task inventories, and endpoint telemetry to find scripts, scheduled jobs, CI pipelines, or orchestration flows that invoke Invoke‑WebRequest, Invoke‑RestMethod, or pipeline patterns that might parse and execute web content.
• Prioritize remediation:
• For unattended automation, replace Invoke‑WebRequest usage with deterministic download logic:
• Use Invoke‑WebRequest -OutFile to persist content, then validate the artifact (hash/signature) before any execution.
• Prefer safer parsing modes when DOM parsing is not necessary: use the -UseBasicParsing parameter in PowerShell 5.1 to avoid script execution during parsing (where supported).
• For interactive use, train staff to treat the new confirmation prompt as a security checkpoint and to use -UseBasicParsing where appropriate.
• Migrate strategic workloads to PowerShell 7+ where feasible:
• PowerShell 7+ (PowerShell Core) has different web‑parsing behaviors and is actively supported; migrating non‑legacy scripts reduces reliance on PowerShell 5.1’s legacy parsing code paths.
• Pilot the hotpatch in a controlled ring:
• Apply KB5074204 to a small pilot cohort (support desks, security team laptops, and a representative sample of servers) and validate both interactive workflows and automation workflows. Monitor for hung scheduled tasks, pipeline failures, and user confusion.
• Update runbooks and change control:
• Add explicit steps in runbooks to handle the confirmation prompt and to pre‑install script fixes or flag automation that needs refactoring before mass rollout.
• Validate success post‑deployment:
• Confirm the changed file attributes and build values on patched devices (for example, check Microsoft.PowerShell.Commands.Utility.dll version 10.0.26100.7456 and corresponding UBR values) and verify that automation test suites pass.

---

Example remediations and code patterns​

• Safer download pattern (non‑interactive):
• Use Invoke‑WebRequest to save content to disk:
• Invoke‑WebRequest -Uri 'https://example.com/script.ps1' -OutFile 'C:\Temp\script.ps1'
• Validate the downloaded artifact:
• Compare a vendor‑provided SHA‑256 hash or verify a digital signature.
• Execute only after validation:
• If valid, dot‑source or invoke the script; if not, log and alert.
• If DOM parsing is required but script execution is not acceptable:
• Consider using the -UseBasicParsing switch (PowerShell 5.1) or move parsing to a dedicated HTML parsing library that does not execute embedded scripts, such as AngleSharp or HtmlAgilityPack in a controlled host.

These approaches convert a single opaque step into an auditable, policy‑driven sequence that scales safely in automation environments.

---

How to check whether your device received KB5074204​

• Confirm Hotpatch enrollment in your management console before expecting the update.
• Check the file versions listed in the KB — for example, Microsoft.PowerShell.Commands.Utility.dll at version 10.0.26100.7456 — and compare to the file properties on disk.
• Inspect reporting values via winver or registry:
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion: CurrentBuildNumber and UBR combine to show the full reporting build.
• For managed environments, review Windows Update and WSUS catalogs for the KB entry and deployment status.

---

Cross‑checking and verification​

Key technical claims in the public KB were verified against Microsoft’s advisory and independent security reporting. The Microsoft KB confirms the prompt and files updated; BleepingComputer independently reported the user prompt text and the recommendation to use -UseBasicParsing when appropriate; community analysis and WindowsForum coverage provide operational guidance and risk analysis for automation owners and enterprise administrators. These independent cross‑checks support the claim that KB5074204 introduces a confirmation prompt for Invoke‑WebRequest and is delivered as a hotpatch to Hotpatch‑enrolled devices. Caution: while the KB references CVE‑2025‑54100 as the tracked item addressed by the behavioral change, the public advisory does not assert that CVE‑2025‑54100 is being actively exploited broadly in the wild; therefore any claims about ongoing exploitation should be treated as unverified unless supported by additional threat intelligence or vendor statements. Administrators relying on prioritized emergency patching decisions should consult their incident response feeds and the Microsoft Security Update Guide for CVE exploitability details.

---

Strengths of Microsoft’s approach​

• Low disruption for eligible systems: Hotpatch delivery reduces the cost of patching mission‑critical endpoints by avoiding planned restarts on Hotpatch‑enrolled devices, enabling faster adoption where eligible.
• Targeted, behavior‑level mitigation: Instead of attempting large‑scale rewrites to the runtime, Microsoft added a simple, high‑leverage friction point where it matters most — the user path that historically enabled silent remote code execution.
• Fast response cadence: A hotpatch allows Microsoft to deploy a surgical fix between larger cumulative updates, which is valuable for closing high‑risk primitives quickly.

---

Weaknesses and residual risks​

• Partial coverage: Only Hotpatch‑enrolled devices receive the change through this path. Non‑enrolled devices remain exposed to the prior behavior until other cumulatives or updates include the same fix. That means attack surface reduction is uneven across real‑world estates.
• Automation fallout: The interaction will break unattended workflows unless administrators rewrite scripts. For many environments, the remediation cost (time, testing, code changes) is non‑trivial.
• Messaging gaps: Operators might misinterpret the prompt and accept it blindly, which would blunt the protective intent unless training and policy guidance are explicit.
• Dependency on other mitigations: The prompt helps, but it is not a substitute for proper endpoint controls. Organizations that rely solely on this change without strengthening EDR, script logging, and artifact validation may be under‑protected.

---

Final assessment and recommended timeline​

KB5074204 is a pragmatic and effective mitigation for a specific, commonly‑exploited misuse pattern in PowerShell 5.1. For Hotpatch‑enrolled systems, apply the hotpatch quickly following a short pilot and remediation sweep for automation. For non‑Hotpatch environments, schedule the change into the next maintenance window and use the intervening time to inventory and refactor automation that depends on Invoke‑WebRequest’s legacy parsing behavior.
Short, practical timeline:

• Days 0–2: Inventory automation and confirm Hotpatch coverage.
• Days 3–7: Pilot KB5074204 on a small ring that includes support desks and critical servers with human operator presence.
• Days 7–21: Roll out fixes to unattended scripts discovered in inventory (replace parsing patterns, add explicit OutFile+validate flows, or migrate to PowerShell 7+).
• Days 21–45: Gradually expand hotpatch deployment with monitoring and fresh runbook updates, using telemetry to validate that scheduled tasks and CI/CD jobs are behaving.

Pair the hotpatch with organization‑level policies: require artifact hashing/signing for remote code execution, enable script block logging and EDR rules for suspicious download and execute behavior, and consider staged migrations away from PowerShell 5.1 where operationally feasible.

---

Closing notes and cautionary flags​

• The KB states Microsoft is not currently aware of any issues with this update; nevertheless, any behavioral change to a command used in both interactive and automation contexts requires careful planning and testing.
• The CVE linkage (CVE‑2025‑54100) is documented by Microsoft; however, public-facing details about exploit status are limited in the KB. Treat assertions about active exploitation as needing corroboration from threat intelligence feeds or vendor advisories before assuming the hotpatch was issued in response to active exploitation.
• Use this hotpatch deployment as an operational prompt to accelerate broader automation hygiene: inventory, artifact signing, deterministic downloads, and migration to supported PowerShell versions.

KB5074204 is both a practical short‑term defense and a policy impetus: it reduces immediate risk with a simple, visible intervention while forcing organizations to address the root causes — brittle automation that executes unaudited, unsigned web content. Apply it thoughtfully, fix your scripts, and treat the prompt as a reminder that convenience remains an adversary when it intersects with remote code execution.

---

Source: Microsoft Support KB5074204: Security Update for Windows PowerShell (OS Builds 26100.7392 and 26200.7392) - Microsoft Support