Windows 11 updates disrupt HTTP/2 on localhost (127.0.0.1): what broke and how to mitigate

CyberSecureFox 🦊

Windows 11 users report that recent updates—October cumulative KB5066835 and the September preview KB5065789—cause localhost instability by breaking HTTP/2 connections to 127.0.0.1. After installation, browsers and clients frequently fail the handshake with ERR_CONNECTION_RESET or ERR_HTTP2_PROTOCOL_ERROR, disrupting developer workflows and applications that rely on local web services.

HTTP/2 to 127.0.0.1 fails with connection resets

The failure is specific to loopback HTTP/2 sessions. Instead of establishing a multiplexed stream, the connection is reset during setup, presenting generic transport-layer errors to the client. Because many tools use localhost for authentication callbacks, device checks, or IPC-like workflows, the impact extends beyond test environments to security-sensitive and operational processes.

Affected tools and real-world symptoms

Reports across Microsoft forums, Stack Exchange, and Reddit indicate issues in Visual Studio web-app debugging, SSMS Entra ID sign-in flows, and Duo Desktop/Duo Prompt integrations that depend on local endpoints. A Duo support bulletin notes that on Windows 11 24H2/25H2 with these updates, Duo Prompt may not be able to reach Duo Desktop, causing failed authentication or degraded Zero Trust capabilities (e.g., Trusted Endpoints, Device Health, Duo Passport, Verified Duo Push with Bluetooth Autofill/Proximity Verification).

What likely changed in Windows networking

While Microsoft has not published detailed technical notes, the error pattern points to a regression in the Windows networking stack when handling HTTP/2 on loopback. Because HTTP/2 uses stream multiplexing and Application-Layer Protocol Negotiation (ALPN), even minor changes in HTTP.sys or TLS policy can produce handshake mismatches or resets on 127.0.0.1. Despite being “local traffic,” the consequences reach critical business flows like SSO, compliance checks, and CI/CD pipelines.

Workarounds and temporary fixes IT can apply now

System-level: disable HTTP/2 via registry

Community guidance (e.g., BornCity) shows that disabling HTTP/2 at the OS level stabilizes local connections. Set EnableHttp2Tls=0 and EnableHttp2Cleartext=0 under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters. This forces clients and services back to HTTP/1.1, mitigating resets at the cost of potential performance and feature regressions for components that expect HTTP/2.

Security stack: update Microsoft Defender signatures

Some administrators report improved stability after installing the latest Microsoft Defender definitions, suggesting an interaction between security filtering and HTTP/2 traffic on loopback. Results appear mixed, so treat this as a “try-first” step rather than a guaranteed fix.

Rollback: uninstall the problematic updates

The most reliable remediation reported so far is uninstalling KB5066835 and KB5065789 followed by a reboot. After rollback, 127.0.0.1 again accepts HTTP/2 connections. This option may be unsuitable for tightly managed environments or where the updates address other important issues.

Guidance for enterprise IT and developers

Patch governance and monitoring

Temporarily pause rollout of these patches via WSUS/Intune and use staged deployments. Enhance monitoring for localhost connection errors, and record incidents in your ticketing system. Collect network stack and application logs, including HTTP/2 traces, and track advisories from Microsoft and vendors whose products rely on loopback endpoints.

Application-level mitigations

Where possible, force local clients to HTTP/1.1: use runtime flags (e.g., curl –http1.1), SDK/framework toggles, or reverse-proxy configuration. For latency-sensitive services, evaluate the performance impact before making system-wide registry changes. Ensure any workaround is documented and reversible once an official fix is released.

Organizations encountering ERR_CONNECTION_RESET or ERR_HTTP2_PROTOCOL_ERROR on 127.0.0.1 after deploying KB5066835/KB5065789 should consider a combination of the above mitigations and, where risk permits, rolling back the updates. Document incidents, control patch rollouts through pilot rings, and engage vendor support to minimize downtime and safeguard authentication and compliance workflows while awaiting an official resolution.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.