KB5074204: PowerShell Invoke WebRequest Now Prompts for Confirmation (CVE-2025-54100)

Microsoft has issued KB5074204, a targeted security update for Windows PowerShell that ships as a hotpatch for devices on the 24H2 and 25H2 code families (OS Builds 26100.7456 and 26200.7456). The patch introduces a notable behavior change: the legacy PowerShell 5.1 cmdlet Invoke‑WebRequest now presents a confirmation prompt warning about the risk of executing scripts downloaded from the web. The update is scoped to hotpatch‑enrolled devices and installs updated PowerShell resource binaries (file version 10.0.26100.7456), with Microsoft linking the change to a tracked vulnerability (CVE‑2025‑54100) and a companion guidance update for PowerShell 5.1 aimed at preventing script execution from web content.

Background / Overview​

Windows PowerShell has long been a double‑edged sword: an essential automation engine for administrators and DevOps teams, and one of the most heavily abused primitives in attacker toolkits. Web‑facing cmdlets such as Invoke‑WebRequest and Invoke‑RestMethod make it trivially easy to fetch remote content. Attackers commonly combine a single‑line download with an immediate execution pattern (for example, piping remote content into Invoke‑Expression / iex), producing the classic “download and execute” cradles seen in countless intrusion narratives.
Over the last several years Microsoft has hardened PowerShell in multiple ways — script block logging, constrained language enforcement, improvements to execution policy behavior, and guidance on safe usage — yet the convenience of a one‑liner remains a persistent risk. Hotpatch delivery has become Microsoft’s mechanism for delivering narrowly scoped, low‑disruption security fixes between larger cumulative updates. KB5074204 is a hotpatch that focuses specifically on mitigating the risk of silent script execution via a behavioral prompt in PowerShell 5.1’s web cmdlet.

---

What KB5074204 actually changes​

• Applies to:
• Windows 11 Enterprise LTSC 2024
• Windows 11 Enterprise and Education, version 24H2
• Windows 11 Enterprise and Education, version 25H2
• Build targets:
• OS Build 26100.7456
• OS Build 26200.7456
• Release packaging:
• Delivered as a hotpatch (no restart required for hotpatch‑eligible machines except in cases where an active PowerShell session forces a restart).
• Available via Windows Update (for hotpatch devices), Microsoft Update Catalog, and Server Update Services.
• Functional change:
• The Invoke‑WebRequest cmdlet in PowerShell 5.1 now displays a confirmation prompt warning about the security risk of executing scripts obtained from web content; users can choose to continue or cancel.
• Microsoft documents this behavioral change as addressing the vulnerability tracked as CVE‑2025‑54100, and pairs it with guidance updates for PowerShell 5.1 to prevent script execution from web content.
• File changes:
• Updated resource DLLs for PowerShell commands (Microsoft.PowerShell.Commands.Utility.Resources.dll) with file version number matching the OS build (10.0.26100.7456) and dates in early December on the patched package.

These changes are deliberately narrow‑scoped: the patch changes cmdlet behavior to require interactive confirmation in scenarios where web content could lead to script execution. The update is not a platform redesign — it is a tactical countermeasure to a specific, high‑impact misuse pattern.

---

Why this matters: the security case​

PowerShell’s web cmdlets are frequently used in “download‑and‑execute” attack chains. Historically, a short command executed by a user — or injected via social engineering — can fetch remote code and hand it to the runtime without explicit interactive confirmation, enabling rapid privilege escalation or persistence.

• The new confirmation prompt is an intervention that embeds human judgement into a high‑risk operation. When invoked interactively, a user who triggers the prompt is more likely to detect suspicious activity and stop the command.
• By pairing the behavioral change with a CVE and explanatory guidance, the vendor signals that this is a mitigation for a recognized exploitation vector, not just a cosmetic alignment.
• The hotpatch model allows Microsoft to deliver this mitigation quickly to high‑risk deployments without requiring the full restart that comes with a baseline cumulative update.

From a threat‑defense perspective, layering a simple, user‑visible friction point can measurably reduce successful opportunistic abuse. It complements other defenses (EDR protections, script‑block logging, AppLocker, constrained language mode, and execution policy hardening) rather than replacing them.

---

Operational impact: the tradeoffs and risks​

Any change that inserts interactive confirmation into a widely used command will have operational consequences. Administrators and automation authors should weigh the security benefits against potential breakage.
Key operational risks:

• Automation breakage — Non‑interactive scripts, scheduled tasks, CI/CD runners, configuration management systems, and unattended agents that call Invoke‑WebRequest will see interactive prompts unless those scripts are specifically written to suppress confirmation or already use alternative patterns. This will cause errors, hangs, or failed runs.
• Visibility vs. friction — The prompt protects interactive users but can be bypassed inadvertently in environments that set permissive policy or where scripts use automatic acceptance switches. Without guidance, teams may be tempted to blunt the protection by globally lowering confirmation settings.
• Partial rollout and coverage — KB5074204 applies only to devices enrolled in the hotpatch program. Organizations that do not enroll or that manage updates centrally via classic baselines may not receive the change immediately — leaving a mixed environment where behavior varies across similar endpoints.
• False sense of security — The prompt reduces accidental execution risk but it does not prevent all malicious use (for example, scripts executed by system contexts or attacks that avoid Invoke‑WebRequest in favor of API calls). Good hygiene and layered controls remain necessary.

---

Who should prioritize this update​

• Security teams responsible for endpoints and user‑facing systems should treat this as high‑priority mitigation for interactive user scenarios, especially on machines where users browse untrusted content or are likely to run ad‑hoc PowerShell snippets.
• Administrators managing hotpatch‑eligible mission‑critical fleets that require low‑disruption security fixes should include KB5074204 in pilot rings and targeted deployments.
• Teams that rely heavily on automation must plan for compatibility testing: unattended scripts invoking Invoke‑WebRequest should be updated, or the scripts should be migrated to safer patterns (see the mitigation section below).
• Organizations with mixed enrollment (some devices hotpatch‑enrolled, others not) should be particularly mindful: inconsistent behavior across similar endpoints complicates support and can mask drift.

---

Deployment and verification checklist​

Follow this pragmatic, operational checklist before and during rollout:

• Inventory hotpatch enrollment:
• Confirm which devices are enrolled for hotpatching. Hotpatch distribution is limited to enrolled devices; non‑enrolled machines will not receive this hotpatch.
• Pilot on representative devices:
• Include interactive desktops, developer workstations, automation hosts, and any servers that run scheduled scripts which may call Invoke‑WebRequest.
• Pre‑deployment compatibility testing:
• Search your scripts for calls to Invoke‑WebRequest, iex (Invoke‑Expression), piping remote content into the shell, and other one‑liner download/execution patterns.
• Update automation code where needed:
• Replace risky one‑liners with safer patterns (download to a file with -OutFile, validate signatures, scan with AV/EDR before execution, or fetch artifacts from controlled repositories).
• Confirm installation:
• Check the updated file version for the PowerShell command resource DLL (filename Microsoft.PowerShell.Commands.Utility.Resources.dll and file version 10.0.26100.7456 for the patched build).
• Validate OS build and UBR values (winver or registry: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion).
• Monitor logs:
• Watch for failed scripts, hung scheduled tasks, or unusual automation failures over the first 24–72 hours post‑deployment.
• Rollout cadence:
• Use a staged rollout: small pilot → broader pilot → general deployment. Maintain rollback plans (system restore points, uninstall instructions, or MSU packages where applicable).

---

How to mitigate automation breakage​

For scripts and services that must remain non‑interactive, consider the following safe remediation options:

• Replace interactive Invoke‑WebRequest usage with deterministic download patterns:
• Use Invoke‑WebRequest -OutFile to download content to a disk path, then validate the file (check signatures, strong hashes) before any execution step.
• Prefer signed artifacts hosted in internal repositories (artifact servers, package feeds, or private blob storage) and use authenticated APIs instead of arbitrary web fetches.
• Suppress confirmation in controlled scripts:
• Many PowerShell commands support the common parameter -Confirm:$false or respect the preference variable $ConfirmPreference. When used carefully in a trusted automation context, these mechanisms suppress prompts.
• Example pattern: My‑DownloadFunction -Confirm:$false
• Do not use blanket suppression without additional safeguards (signature checks, integrity validation).
• Move to APIs or dedicated agents:
• Where possible, call provider APIs that return structured data rather than HTML blobs that might embed scripts. Use secure token‑based authentication and least‑privilege service accounts.
• Favor Invoke‑RestMethod or modern HTTP clients where appropriate:
• In many cases, automation requires structured JSON rather than raw HTML; Invoke‑RestMethod is often a better semantic match and historically less tied to legacy HTML parsing behavior.
• Increase defensive controls:
• Enforce script block logging, enable AMSI/EDR scanning of script content at launch, and apply AppLocker or Device Guard rules to prevent untrusted script execution.

Note: any suppression of confirmation is an operational decision — apply only when you can guarantee the integrity and origin of fetched content.

---

Testing and observability: what to watch for in the first 72 hours​

• Automation failures and hung jobs where a scheduled task waits for user input.
• Increases in helpdesk tickets: scripts producing “prompting for input” errors will often spawn user support requests.
• Unexpected process trees: attackers sometimes replace standard cmdlets with proxy functions; verify that your PowerShell modules are from trusted locations.
• EDR/AV alerts for blocked downloads or script execution attempts.
• Audit logs for changed confirmation preferences or scripts that override safety variables (e.g., scripts that set $ConfirmPreference = 'None').

Encourage teams to collect example failure logs and to keep an evidence trail (package installation records, file versions) for audit and troubleshooting.

---

Critical analysis: strengths, limitations, and residual risk​

Strengths

• User‑centric friction: The confirmation prompt is a low‑complexity, high‑impact intervention that disrupts a common attack vector without complex infrastructure changes.
• Fast delivery via hotpatch: Hotpatches reduce the time to mitigate high‑priority threats for eligible devices and minimize scheduled downtime.
• Paired guidance: Linking the behavioral change to a documented vulnerability and companion guidance helps defenders understand the intent and adopt complementary mitigations.

Limitations and risks

• Automation compatibility: The most significant tradeoff is compatibility with unattended automation. Administrators must proactively update scripts, or they will face failures.
• Limited scope: The hotpatch targets one command’s interactive behavior. Attackers can substitute other techniques (native APIs, custom HTTP clients, compiled binaries) to achieve the same end.
• Rollout fragmentation: Because the change is available only to hotpatch‑enrolled devices at first, organizations will face inconsistent endpoint behavior across fleets, complicating support and standardization.
• Potential for misuse of overrides: Administrators may disable or globally weaken confirmation settings to restore automation quickly, which negates the security benefit.

Residual risk remains: the prompt reduces accidental or naive misuse of web‑downloaded scripts by interactive users, but it does not solve the underlying problem of insecure workflows, lax artifact provenance, or privileged execution patterns. The true mitigation is a combination of developer discipline (signed artifacts and secure registries), defensive tooling (EDR and AMSI), and runtime controls (AppLocker/LLM constraints, script block logging).

---

Practical, numbered action plan for IT teams (priority sequence)​

• Inventory: run a scripted search for all usages of Invoke‑WebRequest, iex, and download‑and‑pipe patterns in your organization’s automation repositories and scheduled tasks.
• Identify hotpatch enrollment: produce a list of hotpatch‑enrolled hosts to map which systems will receive KB5074204 automatically.
• Pilot: select a small, representative pilot group that includes at least one automation host, one developer workstation, and one standard PC.
• Test scripts: run automation scripts in a controlled test environment after applying the patch; check for interactive prompts and address failures immediately.
• Harden: require that downloaded scripts are signed and validated before execution; update automation to download + validate + execute (three‑step flow), not fetch‑and‑eval.
• Rollout: proceed with staged deployment after successful pilot validation, monitoring telemetry and incident queues for 72 hours.
• Document: update runbooks to show how to check the installed PowerShell resource file version and how to validate hotpatch application state.
• Audit: collect evidence for compliance teams — build/UBR numbers, file versions, and Windows Update history entries for endpoints in scope.

---

Quick commands and checks for administrators​

• Check OS build and UBR (concise):
• Run winver or inspect registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion for CurrentBuildNumber and UBR values.
• Verify updated PowerShell resource file version:
• Use a PowerShell snippet to inspect file version:
• Get-Item "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Utility\Microsoft.PowerShell.Commands.Utility.Resources.dll" | Select-Object -ExpandProperty VersionInfo
• Confirm the FileVersion property equals 10.0.26100.7456 (or the version your build reports).
• Find scripts that call Invoke‑WebRequest:
• Example (search code repos and local scripts):
• Get-ChildItem -Path \Path\To\Repos -Recurse -Include .ps1,.psm1 | Select-String -Pattern "Invoke-WebRequest|iwr|iex" -List
• Suppress confirmation in trusted automation:
• Example: Invoke‑WebRequest -Uri $uri -OutFile $path -Confirm:$false
• Use only in contexts where artifact provenance is verified.

---

Final verdict and recommendation​

KB5074204 is a focused and pragmatic mitigation that raises the bar against an extremely common and effective attacker technique: remote script download and execution via PowerShell web cmdlets. The vendor’s decision to ship it as a hotpatch makes operational sense for hotpatch‑eligible fleets: it delivers rapid protection with minimal disruption.
However, the patch is not a replacement for a robust defense strategy. Its strength lies in adding human‑visible friction at a critical risk point; its weakness is that it forces a choice between productivity and safety for unattended automation. Administrators should treat KB5074204 as an opportunity to tighten automation hygiene:

• Use this update as the impetus to inventory and remediate risky scripts.
• Migrate to safer download/validation/execution patterns and prefer signed artifacts from trusted feeds.
• Pilot the hotpatch, monitor for automation failures, and update runbooks accordingly.

For environments enrolled in hotpatch, apply KB5074204 quickly to protect interactive users, while concurrently executing a measured plan to update automation. For environments not enrolled in hotpatch, schedule a targeted update through your normal change windows and use the same remediation playbook.
The bottom line: KB5074204 reduces a low‑cost attack surface that has led to high‑impact compromises for many organizations, but it must be paired with automation hardening, logging, and deployment discipline to convert a one‑off mitigation into durable, systemic resilience.

---

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