Windows 11 October 2025 KB5066835 Breaks Localhost HTTP/2 — Fixes & Rollback

Microsoft’s October cumulative for Windows 11 has knocked the “machine can talk to itself” assumption off balance: after Patch Tuesday’s KB5066835 landed, a wave of developers, sysadmins and vendors reported that localhost-hosted web sites and developer workflows stopped responding, typically producing ERR_HTTP2_PROTOCOL_ERROR or ERR_CONNECTION_RESET when hitting 127.0.0.1 / ::1. The immediate community triage points to a regression in the OS HTTP stack (HTTP.sys) that breaks HTTP/2/TLS negotiation on loopback interfaces; practical mitigations exist — from a quick Defender intelligence update to a reversible registry toggle that disables HTTP/2 — but each carries real trade‑offs, and some environments required rolling back the cumulative update entirely to restore functionality.

---

Background / Overview​

The October 14, 2025 Patch Tuesday cumulative (KB5066835) shipped as Microsoft’s regular rollup for Windows 11 (24H2 and 25H2 builds), packaging security fixes, quality improvements and new features. Within hours of broad rollout, reports surfaced from developers and vendors that IIS, IIS Express and other local HTTP listeners stopped accepting connections on loopback, breaking debugging, CI agents and desktop apps that embed local web servers. The problem shows up as protocol‑level failures during TLS/HTTP/2 negotiation — browsers report HTTP/2 protocol errors; Visual Studio cannot attach to IIS‑hosted projects; some third‑party management apps stop talking to their local services. Microsoft’s KB page lists the update and its contents but did not initially include a consolidated known‑issue note addressing the localhost regressions.
Why this matters: HTTP.sys (the kernel‑mode HTTP listener in Windows) is a shared plumbing layer. When it mis‑negotiates HTTP/2 or mishandles TLS frames on loopback, the impact ripples to every user‑mode process that relies on that stack — IIS, IIS Express, services using HttpListener, and vendor apps that expose local HTTP endpoints. That’s why a single patch can suddenly block many unrelated local workflows.

---

What’s actually failing — technical snapshot​

Symptoms seen in the field​

• Browsers show ERR_HTTP2_PROTOCOL_ERROR or ERR_CONNECTION_RESET for http://localhost or https://localhost.
• Visual Studio projects using IIS / IIS Express fail to start or attach; developers see HttpListenerException and broken debug flows.
• Third‑party desktop and enterprise products that embed local web servers (examples reported by vendor forums) lose connectivity.
• Some systems show firewall anomalies or missing inbound rules after the update, adding complexity to triage.

Likely root domain (community consensus)​

Community triage and Microsoft community engineers converge on an HTTP/2/TLS negotiation regression inside HTTP.sys as the most plausible locus of failure: the OS HTTP stack appears to reject or reset certain loopback HTTP/2 connections that previously succeeded. That assessment is consistent across multiple independent community posts and vendor replies, though Microsoft had not (at time of initial reporting) published a detailed low‑level post‑mortem; treat the exact, line‑for‑line code cause as vendor confirmation pending an official technical breakdown.

---

Confirmed and widely used mitigations (with pros & cons)​

The community produced a practical “ladder” of mitigations — try the least invasive first, escalate only as needed.

• Quick, low‑risk step: install the latest Microsoft Defender Security Intelligence update and reboot.
• Why: multiple affected users reported this restored localhost in some cases. It’s non‑destructive and safe to try on production devices. It’s not a guaranteed or universal fix, and Microsoft has not documented this as an official resolution.
• Temporary, reversible OS‑level workaround: disable HTTP/2 at the Windows HTTP stack (HTTP.sys) via registry.
• Registry values to add (requires Administrator and a reboot):
• Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
• Create DWORD (32‑bit) EnableHttp2Tls = 0
• Create DWORD (32‑bit) EnableHttp2Cleartext = 0
• Effect: forces a fallback to HTTP/1.1 for TLS and cleartext on the OS layer, restoring connectivity for many local services while leaving the cumulative update installed.
• Trade‑offs: this is a blunt, global protocol change — it removes HTTP/2 benefits (multiplexing, header compression, some performance/latency gains) for all apps that depend on the OS HTTP stack. Use only on isolated developer machines or short‑term recovery rings; document and revert after a proper fix arrives.
• Rollback the cumulative update (if mitigation above fails and if risk assessment allows):
• Command (elevated prompt):
• wusa /uninstall /kb:5066835
• Restart
• If still problematic in some environments, some admins had to remove a sibling servicing update (for example KB5065789) — test carefully on non‑production machines first.
• Effect: uninstalling the LCU restored localhost for many affected systems.
• Trade‑offs and caveats: removing a cumulative security update reduces the device’s security posture. Some combined packages that include an SSU might not be removable through wusa; some users reported uninstall errors. Always test, document, and apply compensating controls when rolling back a security update.
• Application‑layer workarounds (longer term, safer for production):
• Run local web workloads on user‑mode servers (Kestrel for ASP.NET Core) and terminate TLS there, or use a local reverse proxy that bypasses HTTP.sys.
• Bind explicitly to 127.0.0.1 (not hostname) where appropriate and use containerization for dev/test so the environment isn’t dependent on system HTTP stack semantics.
• These approaches reduce reliance on kernel‑mode platform behavior and are the preferred long‑term remedy for critical CI/dev hosts.

---

Step‑by‑step: safe triage ladder for dev machines and build agents​

• Reboot and apply the latest Microsoft Defender Security Intelligence (easy, low risk).
• Download or let Windows Update apply the latest definitions, reboot, then test localhost. This resolved some cases without further action.
• If the problem persists, try the registry HTTP/2 toggle (non‑destructive, reversible).
• From an elevated Command Prompt, run:
• reg add "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Tls /t REG_DWORD /d 0 /f
• reg add "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Cleartext /t REG_DWORD /d 0 /f
• Reboot the machine.
• To revert:
• reg delete "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Tls /f
• reg delete "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Cleartext /f
• Reboot.
• Document the change in your change control system and make reversion steps part of the ticket.
• If you cannot tolerate the registry change and the Defender update did not help, test uninstall on a representative non‑production image:
• wusa /uninstall /kb:5066835
• Reboot and test.
• If the service remains broken on that image, test uninstalling siblings (e.g., KB5065789) in an isolated environment. Avoid broad fleet rollbacks without risk mitigation.
• If you roll back, schedule compensating steps:
• Harden network perimeter and endpoint protections temporarily.
• Patch the machines again only after Microsoft issues a targeted fix or Known Issue Rollback (KIR).
• Rebuild or restore from a clean image where appropriate and test re-application of the October updates in a canary ring first.

---

Why this update behaved like a “disaster” for dev workflows​

• Shared kernel plumbing: HTTP.sys lives in kernel land and serves many processes. A change at that layer hits lots of independent apps at once, amplifying impact.
• Upgrade‑path sensitivity: community reproductions show clean installs sometimes do not reproduce the bug while long‑lived upgraded systems do, suggesting stateful interactions with pre‑existing configurations, third‑party drivers, or installed components. That variability complicates both diagnosis and mass remediation.
• Pressure timing: this shipped during a normal Patch Tuesday cadence and collided with active development schedules and CI pipelines — a small timing window but a high impact on productivity.
• Risk tradeoff: uninstalling security updates exposes devices; disabling HTTP/2 has performance implications. Organizations are forced to choose between security posture and developer productivity until a targeted fix is released.

---

Practical advice for teams and organizations​

Short term (next 24–72 hours)​

• Pause automatic deployment of KB5066835 to developer/workstation rings until you test on representative, historically upgraded images.
• Try the Defender intelligence update first on affected machines — it’s low-risk and occasionally effective.
• If immediate developer productivity is at stake and Defender doesn’t help, use the registry HTTP/2 disable on isolated dev machines only; do not roll the registry change out across production fleets without review.

Medium term (1–2 weeks)​

• Build and test a rollback playbook: test uninstall steps on non‑production clones; verify behavior and document fallout (including any dependent services).
• Move critical CI/build agents and developer machines toward user‑mode servers or containerized environments that don’t depend on HTTP.sys semantics for local testing.
• Engage vendor support for any enterprise products that rely on localhost endpoints (some vendors already acknowledged impacts and recommended rollback in affected versions).

Long term (policy & process)​

• Add historically upgraded (long‑lived) images to your validation rings — testing on only clean images will miss upgrade-path regressions like this.
• Maintain documented rollback plans and scripted, auditable reversion steps for critical patches.
• Reduce brittle dependencies on kernel-mode platform behaviors for local dev: containerize, use user‑mode servers, or explicit 127.0.0.1 bindings.

---

Risk analysis — strengths of the mitigations and their liabilities​

Strengths​

• The Defender update and registry toggle are fast and often restore service without a full OS rollback.
• Registry approach is reversible and scriptable, suitable for targeted, ephemeral remediation on developer machines.
• Application‑layer fixes (Kestrel, reverse proxies, containers) are robust long‑term strategies that decrease platform coupling.

Risks & liabilities​

• Uninstalling KBs re‑exposes systems to critical security fixes; companies should plan compensating controls and limit the rollback window.
• The registry workaround disables HTTP/2 globally — potentially affecting performance and compatibility for other applications and remote services using the OS HTTP stack.
• Variability across systems (clean install vs. upgraded image) means there’s no single universal remediation — each environment must be validated individually.

---

What Microsoft has said (and what remains unconfirmed)​

Microsoft’s KB entry confirms the October cumulative (KB5066835) and lists the build numbers and the improvements included, but at the time community reports surged, the KB did not include a consolidated known‑issue note specifically listing localhost regressions; Microsoft community spaces and Microsoft Q&A had active threads where engineers engaged with affected users and recommended rollback as a temporary measure. Treat detailed root‑cause statements about HTTP.sys internals as community-derived analysis until Microsoft posts a formal technical breakdown or issues a Known Issue Rollback (KIR). Monitor Microsoft’s Release Health and KB pages for an official resolution.

---

Bottom line and recommended posture​

The October cumulative (KB5066835) triggered a high‑impact but addressable regression that broke many localhost workflows by altering HTTP/2/TLS behavior in the Windows HTTP stack. The right immediate path is pragmatic: try the least invasive mitigations first (Defender intelligence update), then the reversible registry toggle for dev boxes if needed, and only uninstall the LCU after testing and with clear compensating controls. Longer term, treat this episode as a signal to harden update testing, include long‑lived images in validation rings, and decouple local development workflows from kernel‑mode dependencies where feasible. Document every change, schedule reversion after an official fix, and keep security teams engaged if you temporarily roll back a security update.

---

Quick reference — commands and registry steps​

• Registry toggle (disable HTTP/2 on HTTP.sys):
• reg add "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Tls /t REG_DWORD /d 0 /f
• reg add "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Cleartext /t REG_DWORD /d 0 /f
• Reboot
• Revert registry change:
• reg delete "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Tls /f
• reg delete "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Cleartext /f
• Reboot
• Uninstall cumulative update (test on non‑production first):
• wusa /uninstall /kb:5066835
• Reboot
• If needed, test removing sibling KBs (for example KB5065789) only after validating that action on a test image.

---

This incident is a textbook case of why kernel‑level changes demand conservative rollout and robust rollback plans: when the platform that mediates millions of local connections shifts semantics, the cost is not theoretical — it’s lost developer hours and blocked release pipelines. Follow the triage ladder above, apply the least invasive fix that restores productivity, and prioritize a rapid return to a secure baseline after Microsoft issues an authoritative patch or Known Issue Rollback.

---

Source: HotHardware Windows 11 October Update Breaks Localhost At A Disastrous Time, Here's The Workaround