Windows 11 October 2025 Patch Breaks Localhost HTTP/2 and WinRE USB Input

Microsoft shipped a security-focused cumulative on October 14 that was supposed to harden Windows 11 — and within days a wave of breakages ranging from developer tooling to the recovery environment forced an emergency out‑of‑band patch and a lot of frantic troubleshooting across desktops and enterprise fleets.

Overview​

The October 14, 2025 cumulative update for Windows 11 — distributed as KB5066835 — introduced several high‑impact regressions on upgraded machines. The two most consequential problems were: (1) a kernel‑mode networking regression that broke HTTP/2 loopback (localhost/127.0.0.1) connections and (2) a Safe OS / Windows Recovery Environment (WinRE) problem that left USB keyboards and mice unresponsive while inside recovery. Microsoft acknowledged the WinRE input issue and published an out‑of‑band cumulative update, KB5070773, on October 20, 2025 to restore WinRE USB support and to roll the security fixes and corrections back into a safe cumulative for affected systems.
This feature unpacks what happened, why it matters for developers and IT teams, the practical mitigations you should apply now, and the larger operational lessons for update testing and recovery planning. Where appropriate, claims are cross‑checked against multiple independent reports and Microsoft’s own support pages; any claim that cannot be fully verified from official or corroborated community reporting is explicitly called out.

---

Background: the October servicing wave and why it mattered​

Microsoft’s October servicing wave (the October Patch Tuesday cumulative) was unusually large and urgent, addressing many CVEs and security problems. KB5066835 combined the latest servicing stack update (SSU) with the monthly cumulative (LCU) and applied to Windows 11 24H2 and 25H2 builds. The combined package model means routine rollback via the standard wusa /uninstall path is not always straightforward, because the SSU component prevents a clean wusa uninstall in many cases. That packaging detail is operationally important for admins who might need to revert quickly.
Within hours and days of rollout, support forums and independent outlets reported a set of reproducible regressions tied to that same release. Two of those regressions — the HTTP.sys/localhost failure and WinRE input loss — are particularly worrying because they target fundamental developer workflows and recovery tooling respectively. Multiple outlets and community threads captured the symptoms, reproduced them, and shared interim mitigations while Microsoft investigated.

---

What broke, technically​

Localhost and HTTP.sys (kernel HTTP listener) regression​

• The symptom: applications and browsers trying to reach loopback addresses (127.0.0.1) over HTTP/2 suffered immediate connection resets or protocol errors such as ERR_HTTP2_PROTOCOL_ERROR or ERR_CONNECTION_RESET. That behavior hit IIS, IIS Express, .NET HttpListener clients, Visual Studio debugging sessions, and other tools that rely on the kernel‑mode HTTP listener (HTTP.sys). Several independent technical writeups point to changes affecting HTTP.sys and HTTP/2 negotiation as the proximate cause.
• Why it mattered: many local workflows — from debugging web apps to local sign‑in callbacks for OAuth flows — rely on loopback HTTP endpoints. Where those endpoints fail, developer productivity collapses and some production management consoles that leverage local endpoints can also be impacted.
• Confirming voices: multiple technical reporters and community investigators reproduced the issue and recommended either uninstalling the offending updates or applying temporary mitigations such as disabling HTTP/2 for local listeners. Independent coverage and technical analysis repeated the same pattern: a change in the HTTP stack created a regression for loopback HTTP/2.
• Key caveat: community reports indicate fresh clean installs of Windows 11 24H2/25H2 sometimes did not show the problem — suggesting the bug often surfaced in upgrade scenarios where older components or preview packages (for example, KB5065789) were present. That nuance points toward an interaction/regression rather than a core, universal flaw in a fresh OS image. This claim is consistent across community reporting but the exact internal root‑cause analysis (the precise code change in HTTP.sys) remains the vendor’s to publish; Microsoft had not published a detailed post‑mortem at the time of the emergency fix.

WinRE (Windows Recovery Environment) USB input failure​

• The symptom: after installing KB5066835 some systems could not accept keyboard or mouse input inside WinRE; the recovery UI rendered but the cursor did not move and keystrokes were ignored. Crucially, those same USB HID devices continued to work normally in the full Windows desktop, isolating the fault to the Safe OS/WinRE image. The result: users could not navigate Advanced Startup options (Safe Mode, Reset this PC, Startup Repair) on affected machines unless they had alternative input (PS/2/legacy ports, touchscreen, or pre‑existing external rescue media).
• Microsoft’s response: the vendor added a known‑issues entry to the Release Health/Known Issues and then shipped an out‑of‑band cumulative update (KB5070773) on October 20, 2025 described specifically to fix the WinRE USB problem; the OOB update is cumulative and includes the security fixes from KB5066835 plus the WinRE repair. Microsoft explicitly lists the WinRE USB fix in the KB5070773 release notes.
• Why WinRE problems are severe: WinRE is the primary on‑device recovery path. If WinRE becomes non‑interactive, what would normally be a straightforward repair can become an escalated reinstall — particularly dangerous for home users and remote endpoints without immediate physical support. Multiple industry outlets and community threads stressed that the WinRE failure is not cosmetic; it undermines recoverability.

---

Who was affected — scope and permutations​

• Affected OS branches: Windows 11 versions 24H2 and 25H2 on client machines; some server SKUs also reported similar symptoms in community threads. Microsoft’s KB entries identify those client branches explicitly.
• Deployment variable: the issue appears most commonly on upgraded systems or on machines with a particular set of prior updates (reports frequently mention an interaction with earlier preview updates such as KB5065789). Fresh installations of 24H2/25H2 sometimes avoided the HTTP.sys symptom, which implies the problem often arises in complex upgrade paths. This interaction pattern reduces the chance the bug is present in a clean image, but it heightens the risk for real‑world, heterogeneous fleet upgrades.
• Profiles at risk:
• Developers and dev machines that host local web services or use local OAuth callbacks.
• Admins and support desks relying on WinRE for remote troubleshooting and on‑device recovery.
• Enterprises with broadly automated deployments that pushed KB5066835 systemwide without a pinned validation ring.
• Users with USB‑only input devices and no legacy PS/2 fallback or external rescue media.

---

What Microsoft did — timeline and fixes​

• October 14, 2025 — Microsoft released the October cumulative (KB5066835). It was packaged as a combined SSU+LCU and began rolling via Windows Update.
• October 15–18, 2025 — community and support reports started describing localhost HTTP/2 failures and WinRE USB input loss. Vendors, forums, and reporters reproduced symptoms and shared interim mitigations and rollback steps.
• October 20, 2025 — Microsoft published and began rolling KB5070773 (an out‑of‑band cumulative) that explicitly repairs the WinRE USB issue while carrying forward the security fixes from KB5066835. Microsoft’s KB page describes the WinRE correction as an “improvement” in that OOB page. The fix rolled via Windows Update and is cumulative for the affected builds.
• After the OOB release — community reports and vendor trackers advised administrators to monitor Windows Update and Release Health, and to stage the OOB rollout carefully for recovery‑critical endpoints. Some community mitigations for the localhost issue (uninstalling problem updates, registry toggles disabling HTTP/2 for IIS) were circulated but Microsoft recommended applying the vendor hotfix rather than risky manual edits.

---

Practical mitigation checklist — immediate actions for home users and admins​

Follow this prioritized list to reduce risk and restore recoverability:

• Check Windows Update and apply the KB5070773 out‑of‑band update if you have already installed KB5066835 and experience WinRE input loss or related symptoms. Microsoft’s support page for KB5070773 documents that the update includes the WinRE fix and the security fixes from the October 14 cumulative.
• If you cannot boot into the desktop and WinRE is unresponsive, use alternative input options:
• Connect a PS/2 keyboard (if available) or use touchscreen input on convertible devices.
• Boot from a Windows installation USB to access recovery tools externally.
• Use vendor rescue media or recovery USB drives you created earlier.
• For developer machines with localhost problems:
• Avoid risky registry or system file edits unless you fully understand the change and have a tested rollback.
• If urgent, consider uninstalling KB5066835 (and any implicated preview updates) with caution — but be aware this removes security protections included in the cumulative. On combined SSU+LCU packages, uninstall may require DISM/remove‑package rather than a simple wusa uninstall. Backups and images are advisable before uninstalling.
• For fleets: pause mass deployment of KB5066835 to endpoints that rely on WinRE for on‑device recovery until the OOB fix is validated in a pilot group. Inventory WinRE images (reagentc /info) and keep validated winre.wim copies for rollback. Avoid risky manual workarounds on production endpoints.
• Back up BitLocker recovery keys and critical data. If WinRE is unusable and BitLocker requires a recovery key, having keys accessible will materially shorten support escalations.
• Monitor Microsoft’s Release Health / Known Issues dashboards and update channels for follow‑on guidance and KIR (Known Issue Rollback) notices that may appear as targeted remediation for specific rings.

---

Temporary workarounds? Proceed with caution​

Community posts offered a variety of temporary measures for the localhost problem: disabling HTTP/2 for IIS via the registry, uninstalling the cumulative update (or earlier preview updates), or updating Defender intelligence which in a few cases seemed to alter behavior. Those approaches can reduce the immediate symptoms but they carry tradeoffs:

• Uninstalling the cumulative removes security fixes and may expose the device to vulnerabilities fixed by KB5066835.
• Registry edits are brittle and may have unintended side effects; modifying HTTP/2 behavior can impact performance and compatibility for other services.
• Some reported mitigations worked only for a subset of configurations; reproducibility varied across hardware, drivers, and prior updates.

Because the official vendor fix (KB5070773 for WinRE and subsequent updates that address HTTP.sys issues) is the safest route, the conservative recommendation is to rely on Microsoft’s hotfix/KIR rather than ad‑hoc community workarounds unless you have a tested fallback plan.

---

Unpacking the operational and testing failures​

This episode is more than a hotfix story — it is a case study in the hazards of large, complex servicing changes touching pre‑boot images and kernel plumbing.

• Shared components are fragile: changes that touch kernel subsystems such as HTTP.sys or Safe OS images multiply risk because they affect many independent features (developer tooling, IIS, WinRE). The October update’s breadth meant a single servicing wave touched many interdependent stacks.
• Upgrade scenarios are essential test cases: the problem’s tendency to appear on upgraded systems (and not always on clean installs) highlights a classic testing gap — many labs validate fresh images more thoroughly than long‑lived upgraded endpoints, but real world fleets are dominated by the latter. QA must include long lived upgrade matrices and nightly traces for Safe OS updates.
• Packaging complicates rollback: combined SSU+LCU packaging is a positive for security reliability, but it makes emergency rollback harder for administrators who must fall back to DISM workflows or accept targeted KIRs rather than straightforward uninstalls. That increases the operational cost of a bad patch.
• Communications and triage: Microsoft’s Release Health entry and the out‑of‑band update were the right crisis moves, but the initial disparity between community findings and early vendor notes shows how rapid community triage still fills a critical gap in incident response for complex platform regressions. Industry outlets and vendor sites converged quickly on both the HTTP.sys and WinRE problems as engineers diagnosed and rolled fixes.

---

Strengths in Microsoft’s response — and the gaps that remain​

What Microsoft did well:

• The vendor moved to a targeted out‑of‑band cumulative (KB5070773) when WinRE failures were demonstrated and acknowledged. That OOB patch bundled the recovery fixes and the security work, which reduced the need for a separate manual repair in many cases.
• Release Health was used to flag the known issue and provide admins with a single place to watch for remediation updates.

Shortcomings and risks:

• The regression affected core developer and recovery flows at the same time, showing that even mature platforms can leak operational risk when kernel or Safe OS components are altered without sufficiently broad testing across upgrade scenarios and hardware permutations.
• Some early public guidance did not enumerate all observed regressions (for example, the localhost/HTTP.sys effects reached broad developer tooling quickly), which increased reliance on community investigations and risky ad hoc mitigations. That created friction and risk for teams needing both security and recoverability.

---

Long‑term takeaways for administrators and power users​

• Treat recovery images as production artifacts. Keep versioned, checksummed winre.wim files and a validated USB recovery image for each golden configuration. Practice recovery drills occasionally rather than assuming the desktop is a sufficient fallback.
• Expand testing matrices to include upgraded endpoints, not just fresh installs. Include developer toolchains, local loopback flows, and Safe OS paths in acceptance criteria.
• Staged rollouts and canary rings matter. For enterprise fleets, deploy large security cumulatives to a limited pilot ring that includes varied hardware profiles (consumer laptops, docked workstations, servers) before wide deployment.
• Prefer vendor hotfixes or Known Issue Rollbacks over manual system‑file edits. If manual mitigations are tried, maintain documented rollback steps, verified images, and a communications plan for users.
• Keep recovery paths accessible: BitLocker keys, external backups, and rescue media are the practical difference between a long evening on a helpdesk ticket and a quick, offline restore.

---

Fact checks and verifiability notes​

• Microsoft’s KB pages confirm the October 14 cumulative (KB5066835) and the October 20 out‑of‑band fix (KB5070773) and identify affected OS builds and the WinRE USB input symptom explicitly. The KB pages are the canonical vendor statements for the fixes and known issues.
• Independent coverage from multiple outlets documented the localhost/HTTP.sys regression and the WinRE input failure; those reports corroborate the core facts and reproduceable symptoms reported by community labs. Examples include Windows Latest, Windows Central, The Verge, and other independent technical blogs. Cross‑referencing these reports shows convergent verification of the two primary regressions and of Microsoft’s subsequent OOB fix.
• Where claims remain community‑sourced rather than vendor‑proven: the precise single‑line root cause in the HTTP.sys codebase (for example, the exact code change or driver file line) has not been published as a formal Microsoft post‑mortem at the time of writing. Community technical analyses point to HTTP.sys and HTTP/2 negotiation changes, but the definitive root cause and code diff remain with Microsoft’s internal engineering disclosures — those details should be treated as plausible technical triage rather than confirmed code‑level causation until Microsoft publishes a post‑mortem. Treat such low‑level assertions with caution.

---

Final verdict — what this means for you​

The October servicing episode is a strong reminder that critical OS updates can and do change the operational surface in ways that matter to developers and admins alike. The damage was real: local developer workflows were impeded and, in many cases, the recovery environment became non‑interactive — a dangerous state for non‑technical users. Microsoft’s rapid OOB release for the WinRE symptom was the correct emergency response; however, the incident exposes testing and upgrade validation gaps that organizations must address.
Pragmatically: if you installed KB5066835 and are seeing WinRE or localhost failures, prioritize applying Microsoft’s KB5070773 OOB update and prepare recovery media now. If you manage fleets, slow down broad deployment until you’ve validated fixes in a pilot group and have recovery images on standby. Above all, treat this as a systems‑engineering signal: recovery tooling matters as much as patching, and the two must be tested together.
(Community threads and admin guidance captured the operational playbook and immediate mitigation suggestions while Microsoft pushed the OOB fix; those community findings helped many readers and administrators bridge the gap before vendor patches were broadly available.)

---

Quick checklist (two‑minute version)​

• Check Windows Update now — apply KB5070773 if your system shows signs of the issue.
• Create a Windows installation USB and back up winre.wim and BitLocker keys.
• If you’re a developer and localhost endpoints fail, do not apply registry hacks on production machines; use an isolated test device to evaluate fixes or rollback options.
• For enterprise admins: pause mass rollout until you’ve tested the OOB fix on representative hardware and have a rollback plan.

This episode will be discussed at length in post‑mortems and vendor QA reviews. For now, act deliberately: restore recoverability first, re‑validate security via vendor fixes second, and treat this as a catalyst to harden both your update discipline and your recovery playbooks.

---

Source: touchreviews.net "Emergency Windows Update Declared a ‘Total Disaster’—Is Your PC at Risk?" - Touch Reviews