CVE-2026-49787

What it actually does

CVE-2026-49787 is a network-reachable denial-of-service vulnerability in Windows HTTP.sys caused by allocation of resources without adequate limits or throttling. HTTP.sys is the kernel-mode HTTP stack used by IIS and other Windows services that expose HTTP/HTTPS endpoints. An unauthenticated remote attacker can send crafted or excessive HTTP traffic that forces the system to consume constrained resources, potentially causing HTTP service degradation, request queue exhaustion, application pool failures, or host-level availability impact. The impact is availability only; the provided CVSS vector indicates no confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make web applications, APIs, management endpoints, or Windows services that rely on HTTP.sys unavailable to users and dependent systems. For internet-facing IIS servers, reverse proxies, API gateways, or Windows management services, this can result in outages, failed transactions, missed SLAs, and operational disruption. The vulnerability affects many supported Windows client and server releases, including Windows Server 2016 through 2025 and Windows 10/11 versions, so exposure may be broad wherever Windows hosts accept HTTP/HTTPS traffic. Although it is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, the attack is unauthenticated, network-accessible, and low-complexity, so exposed systems should still be prioritized for patching and compensating controls.

How an attack unfolds

An attacker first identifies a Windows host exposing an HTTP.sys-backed listener, commonly IIS over ports 80 or 443, WinRM over 5985 or 5986, or another application using the Windows HTTP Server API. The attacker then sends crafted or high-volume HTTP requests designed to trigger unbounded or insufficiently throttled resource allocation in HTTP.sys. Because no authentication or user interaction is required, the attacker can perform the attack remotely against reachable services. As resources are consumed, legitimate requests may queue, time out, or fail; IIS application pools and dependent services may become unstable; and the host may show elevated memory, CPU, handle, or request queue usage. Exploitation ends when the target becomes unable to reliably process HTTP traffic or requires service restart, traffic filtering, or reboot to recover.

How to fix it

Apply the relevant Microsoft security update for all affected Windows versions: Windows 10 1607, 1809, 21H2, 22H2; Windows 11 24H2, 25H2, 26H1; Windows Server 2016, 2019, 2022, and 2025. No fixed version numbers were provided in the input, so use the Microsoft Security Update Guide, Windows Update, WSUS, Microsoft Configuration Manager, or equivalent patch management tooling to deploy the July 2026 or later cumulative update that remediates this vulnerability. Where immediate patching is not possible, reduce exposure by blocking unnecessary inbound HTTP.sys-backed services, restricting WinRM to trusted management networks, placing public web services behind load balancers or DDoS protections, enforcing request rate limits and connection limits at perimeter controls, and monitoring/restarting affected services during attempted exploitation. Avoid relying on application-layer authentication as a mitigation because exploitation is unauthenticated and occurs before any meaningful authorization control can protect the service.

How to confirm the fix worked

Confirm that each affected Windows host has installed the Microsoft cumulative security update that includes the fix for this vulnerability. Validate patch status through centralized update inventory, Windows Update history, WSUS/Configuration Manager compliance reports, or PowerShell queries such as Get-HotFix and OS build verification against Microsoft’s published fixed build list. Confirm exposure by enumerating listening HTTP.sys-backed services using commands such as netsh http show servicestate, netsh http show urlacl, netstat, Get-NetTCPConnection, IIS configuration, and WinRM listener configuration. After patching, verify that HTTP/HTTPS services still function normally and that no unnecessary listeners remain reachable from untrusted networks. For high-risk exposed servers, run controlled load and negative testing only in authorized test environments to confirm that request throttling and availability controls behave as expected.

Typical attack path

1. Scan for Windows-hosted HTTP/HTTPS services or management endpoints exposed to the network.
2. Confirm that the target appears to use HTTP.sys-backed services such as IIS, WinRM, or Windows HTTP API applications.
3. Send crafted or excessive unauthenticated HTTP requests to the exposed listener.
4. Force HTTP.sys or dependent services to allocate resources without sufficient throttling.
5. Cause request queue exhaustion, service instability, timeouts, or outage for legitimate users.
6. Optionally repeat the traffic pattern to keep the service unavailable after recovery actions.

How to detect it

To determine whether exploitation has already occurred, review telemetry from Windows hosts that expose HTTP.sys-backed services and from upstream network controls. Primary log sources include IIS access logs, HTTPERR logs, Windows System and Application event logs, IIS/WAS events, Windows Defender or EDR telemetry, firewall logs, load balancer logs, WAF logs, NetFlow, and DDoS provider alerts. Look for abrupt spikes in inbound HTTP requests, unusually high connection counts from one or many sources, repeated request timeouts, HTTP 503 responses, request queue failures, application pool recycling, HTTP service instability, memory or handle exhaustion, and service restarts coinciding with traffic bursts. Pay special attention to exposed ports 80, 443, 5985, and 5986. Because this is a denial-of-service condition rather than code execution, durable host artifacts may be limited; absence of malware or persistence does not rule out exploitation. Correlate service degradation timestamps with external traffic sources, HTTPERR entries, IIS 503 responses, WAS/W3SVC events, and perimeter rate-limit or blocked-connection events.

• C:\Windows\System32\LogFiles\HTTPERR\httperr*.log
• C:\inetpub\logs\LogFiles\W3SVC*\*.log
• Connection_Dropped
• Connection_Abandoned_By_ReqQueue
• QueueFull
• Timer_ConnectionIdle
• Timer_MinBytesPerSecond
• 503
• Service Unavailable
• WAS
• W3SVC
• HTTP Service
• A process serving application pool
• application pool
• stopped
• recycled
• netsh http show servicestate
• netsh http show urlacl
• TCP/80
• TCP/443
• TCP/5985
• TCP/5986

What your security team should do

• Prioritize patching internet-facing Windows servers, IIS hosts, API endpoints, reverse proxies, and systems exposing WinRM or other HTTP.sys-backed services.
• Use Microsoft’s official security update channels to identify and deploy the fixed cumulative update for each affected Windows release.
• Inventory all HTTP.sys listeners with netsh http show servicestate and netsh http show urlacl, then remove or restrict any unnecessary listener.
• Restrict ports 80, 443, 5985, and 5986 to only required sources; keep management endpoints off the public internet.
• Add or tune upstream rate limiting, connection limiting, request timeout, and DDoS mitigation controls for exposed Windows HTTP services.
• Monitor IIS, HTTPERR, System, and Application logs for request floods, queue exhaustion, service crashes, and repeated HTTP service recovery events.
• Create incident response playbooks for rapid containment, including blocking source networks, enabling emergency rate limits, recycling affected services, and failing over traffic if needed.
• Although current EPSS and known-exploitation signals are low, treat the issue as operationally important because exploitation is unauthenticated and can cause outages without compromising credentials.