Windows HTTP.sys Header-Count-Triggered Kernel Memory Corruption / BSOD (CVE-2026-49160)
by dhmosfunk · 2026-07-05
- Severity
- High
- CVE
- CVE-2026-49160
- Category
- binary
- Affected product
- Windows HTTP.sys kernel-mode driver (Windows 10 build 26100 confirmed in crash logs)
- Affected versions
- Windows builds using the vulnerable HTTP.sys UlpParseNextRequest/header-array-growth logic (observed: Windows 10 10.0.26100.1)
- Disclosed
- 2026-07-05
- Patch status
- patched
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-07-05 |
| Last Updated | 2026-07 |
| Author / Researcher | dhmosfunk |
| CVE / Advisory | CVE-2026-49160 |
| Category | binary |
| Severity | High |
| CVSS Score | Not specified in source |
| Status | PoC |
| Tags | windows, http.sys, kernel, http2, dos, bsod, memory-corruption, integer-overflow |
| Related | CVE-2026-47291 (related HTTP.sys request-header buffer counter overflow, decompiled code referenced in the same source repo) |
Affected Target
| Field | Value |
|---|---|
| Software / System | Windows HTTP.sys kernel-mode driver (Windows 10 build 26100 confirmed in crash logs) |
| Versions Affected | Windows builds using the vulnerable HTTP.sys UlpParseNextRequest/header-array-growth logic (observed: Windows 10 10.0.26100.1) |
| Language / Platform | Windows kernel-mode network stack (HTTP.sys driver); PoC client written in Python 3 using the h2 library |
| Authentication Required | No |
| Network Access Required | Yes |
Summary
This PoC targets a memory-safety bug in the Windows HTTP.sys kernel driver’s request header parsing path (HTTP!UlpParseNextRequest / HTTP!UlpHandleRequest). The included http2_bomb.py script establishes a TLS/HTTP2 connection to a target IIS/HTTP.sys-backed server and sends a single stream containing a configurable number of extra custom request headers in addition to the four HTTP/2 pseudo-headers. The repository’s decompiled-code excerpt shows that HTTP.sys grows its internal header-pointer array by re-allocating and copying it each time capacity is exceeded, incrementing a 16-bit (unsigned short) size counter by 5 on each growth event. Because that counter is only 16 bits wide, sustained header/request traffic that repeatedly triggers the growth path can wrap the counter, leading to a buffer-size/pointer mismatch and an out-of-bounds write during a later memcpy. The included WinDbg logs (windbg_crash_logs.md) show the resulting kernel bugcheck (PAGE_FAULT_IN_NONPAGED_AREA, code 0x50) with the faulting write occurring in HTTP!memcpy, called from HTTP!UlpParseNextRequest — a full kernel crash (BSOD) triggered remotely and unauthenticated.
Vulnerability Details
Root Cause
Per the decompiled snippet in the repository, HTTP.sys’s header-array growth routine reallocates the header-pointer buffer via ExAllocatePool3/memmove when the current capacity (tracked in a 16-bit field, *(short *)(piVar16 + 400)) is exceeded, incrementing that field by 5 each time. Because the field is an unsigned short, sufficiently repeated growth events cause it to wrap around 16 bits, after which the code’s bounds assumptions about the header-pointer array no longer match its real allocated size — leading to an out-of-bounds write (observed as an invalid write via HTTP!memcpy) and a PAGE_FAULT_IN_NONPAGED_AREA bugcheck.
Attack Vector
- Establish a TLS connection to the target HTTP.sys-backed server and negotiate HTTP/2 (
h2ALPN). - Send one (or repeatedly send) HTTP/2 request stream(s) containing a large number of additional custom request headers beyond the four pseudo-headers.
- Each time the server-side header buffer needs to grow to accommodate the headers, HTTP.sys’s internal 16-bit growth counter increments by 5.
- Sustained/repeated triggering (the repository notes running for roughly 30 minutes so the counter accumulates enough +5 increments) eventually wraps the 16-bit counter.
- The next header-buffer access uses a buffer whose real size no longer matches the wrapped counter’s expectations, causing an out-of-bounds write inside
HTTP!memcpyduringUlpParseNextRequest, crashing the kernel with bugcheck0x50.
Impact
Remote, unauthenticated denial of service: any Windows host serving HTTP(S) via HTTP.sys (IIS and any other HTTP.sys-based service) can be crashed (BSOD) by a remote attacker with only network reachability to the HTTPS listener, requiring a reboot to recover.
Environment / Lab Setup
Target: Windows 10 (build 26100 in the documented crash) with HTTP.sys-backed HTTPS listener (e.g. IIS), attached to a kernel debugger (WinDbg/KD) for crash analysis
Attacker: Python 3 with the `h2` library, network/TLS access to the target's HTTPS port
Proof of Concept
PoC Script
See
http2_bomb.pyandwindbg_crash_logs.mdin this folder.
| |
The script connects to the target host, negotiates HTTP/2 over TLS, and sends a single GET request stream with the four required pseudo-headers plus --headers additional x-fooooooo-NNNN custom headers, then prints the response/stream-termination events. To reproduce the kernel crash documented in windbg_crash_logs.md, the request needs to be sent repeatedly (or with a large header count) against a debugger-attached target so the internal 16-bit header-buffer growth counter accumulates enough increments to wrap and corrupt kernel memory, ultimately bugchecking with PAGE_FAULT_IN_NONPAGED_AREA (0x50) in HTTP!memcpy / HTTP!UlpParseNextRequest.
Detection & Indicators of Compromise
Windows bugcheck 0x50 (PAGE_FAULT_IN_NONPAGED_AREA) with faulting module HTTP.sys, symbol HTTP!memcpy, call stack containing HTTP!UlpParseNextRequest / HTTP!UlpHandleRequest / HTTP!UlpThreadPoolWorker
Sustained inbound HTTP/2 (or HTTP/1.1) connections carrying an unusually large number of custom request headers per stream/request to the same host over an extended period
Signs of compromise:
- Unexpected server reboots / BSODs on Windows hosts running IIS or other HTTP.sys-based services
- Crash dumps identifying
HTTP.sysas the faulting driver with bucket IDAV_VRF_HTTP!memcpy - Network logs showing repeated requests with abnormally high header counts per connection/stream from a single source
Remediation
| Action | Detail |
|---|---|
| Primary fix | Apply the Microsoft security update addressing CVE-2026-49160 for HTTP.sys once available/installed; monitor Microsoft’s advisory for the patched build |
| Interim mitigation | Limit maximum request header count/size at a front-end reverse proxy or load balancer before traffic reaches HTTP.sys; monitor for and rate-limit connections sending abnormal numbers of headers; restrict direct internet exposure of HTTP.sys-backed services where feasible |
References
Notes
Mirrored from https://github.com/dhmosfunk/CVE-2026-49160-HTTP.sys on 2026-07-05. Demonstration videos referenced in the upstream repository’s Releases page were not mirrored (external/large media, not required to reproduce the PoC).
| |