CVE-2026-47291: Remote Code Execution in Windows HTTP.sys Kernel Driver

The Windows kernel-mode HTTP driver, HTTP.sys, handles HTTP request parsing and execution directly in kernel space to maximize network performance and minimize user-to-kernel mode context switching. This driver exposes a critical attack surface as it is exposed to untrusted network traffic on systems running Internet Information Services (IIS), WinRM, Web Services for Management, or other applications using the HTTP Server API. The vulnerability classified as CVE-2026-47291 represents an integer overflow condition that leads to a heap-based buffer overflow in the non-paged kernel pool during the processing of HTTP request headers.\n\nThis vulnerability is reachable remotely by an unauthenticated attacker who sends a sequence of malformed HTTP request headers. Because the processing occurs within the kernel context, successful exploitation allows execution of arbitrary code with SYSTEM-level privileges. Conversely, failed exploitation attempts or payloads designed specifically for disruption lead to immediate system crashes via bug checks, manifesting as a Blue Screen of Death (BSOD). This makes the vulnerability highly dangerous for both confidentiality and system availability.\n\nThe vulnerability resides in the dynamic array resizing routines where the driver tracks incoming HTTP headers. As the driver processes headers, it dynamically reallocates space to house header pointers. Due to a failure to validate upper bounds on capacity variables, the driver is susceptible to a wrap-around vulnerability. Security researchers have confirmed that both HTTP/1.1 and HTTP/2.0 connections are viable vectors for this exploit, provided the headers are structured to force continuous memory reallocation.

The primary root cause of this vulnerability is an integer overflow (CWE-190) in the tracking of internal state variables within HTTP.sys. The driver utilizes a structure to manage incoming HTTP request context, denoted in decompiled code as piVar16. Inside this context, two unsigned 16-bit integers (ushort) are maintained: one at offset 0x642 representing the current count of parsed headers, and another at offset 400 representing the total capacity of the allocated pointer array. Because these variables are 16-bit unsigned integers, their maximum representation value is 65535.\n\nWhen a new HTTP header is parsed, the driver compares the count at 0x642 against the maximum capacity at 400. If the count is equal to or greater than the capacity, the driver enters a reallocation branch to expand the buffer. In this branch, HTTP.sys calculates the size of the new kernel pool allocation using the formula (capacity * 8) + 0x28 bytes. The driver then attempts to update the capacity variable by executing capacity = capacity + 5.\n\nThe flaw manifests when the capacity variable reaches the value of 65531. Upon the subsequent execution of the reallocation block, the driver computes 65531 + 5. Due to the limitations of 16-bit integer representation, this addition results in a mathematical wraparound to 0. Consequently, during the next reallocation cycle, the capacity variable is treated as 0. When the driver computes the allocation size (0 * 8) + 40 bytes, it requests a heap chunk of only 40 bytes from the kernel pool via ExAllocatePool3.\n\nThe final step of the vulnerability involves a subsequent memory copy operation (memmove) designed to migrate the existing pointers to the new buffer. The driver calculates the transfer size based on the current parsed header count, which is 65532. The copy operation attempts to move 65532 * 8 bytes, which equals 524256 bytes, into the newly allocated 40-byte buffer. This leads to a heap-based buffer overflow (CWE-122) in the kernel address space, corrupting adjacent heap chunks and leading to control-flow hijack or system crash.

Reviewing the decompiled source code reveals the precise logic flow of the buffer allocation check and the subsequent overflow. The following code snippet demonstrates the vulnerability:\n\nc\nif (*(ushort *)((longlong)piVar16 + 0x642) < *(ushort *)(piVar16 + 400)) {\n // Normal path: insertion of pointer\n} else {\n // Reallocation path\n _Dst = (void *)ExAllocatePool3(0x42, (ulonglong)*(ushort *)(piVar16 + 400) * 8 + 0x28, 0x52526c55, &UxLowPriorityPool);\n if (_Dst != (void *)0x0) {\n // memmove relies on the counter count * 8\n memmove(_Dst, *(void **)(piVar16 + 0x192), (ulonglong)*(ushort *)((longlong)piVar16 + 0x642) << 3);\n // Vulnerable increment of capacity\n *(short *)(piVar16 + 400) = (short)piVar16[400] + 5;\n *(void **)(piVar16 + 0x192) = _Dst;\n }\n}\n\n\nIn the patched version, the driver implements validation prior to the capacity update and expands the tracking fields to 32-bit integers to prevent the wraparound. The patch changes the structure layout to use uint32_t for tracking capacity and enforces strict bounds-checking:\n\nc\nuint32_t current_capacity = *(uint32_t *)(piVar16 + 400);\nif (current_capacity >= 0xFFFF) {\n // Enforce boundary check to prevent overflow\n UlBugCheckEx(STATUS_INTEGER_OVERFLOW, ...);\n return STATUS_INTEGER_OVERFLOW;\n}\nuint32_t new_capacity = current_capacity + 5;\n*(uint32_t *)(piVar16 + 400) = new_capacity;\n\n\nmermaid\ngraph LR\n A["Parse Header"] --> B{"Count >= Capacity?"}\n B -- "No" --> C["Store Pointer in Array"]\n B -- "Yes" --> D["ExAllocatePool3(Size)"]\n D --> E["memmove(New, Old, Count * 8)"]\n E --> F["Capacity = Capacity + 5"]\n F --> G{"Overflow?"}\n G -- "Yes (capacity wrapping to 0)" --> H["Next Allocation size = 40 bytes"]\n G -- "No" --> A\n H --> I["memmove writes 524KB into 40B"]\n I --> J["Kernel Panic / RCE"]\n

Exploitation of CVE-2026-47291 requires the attacker to send a large volume of HTTP headers in a single request. However, normal HTTP servers buffer request headers in TCP stream packets, which might process headers in batches. To reliably trigger the individual buffer reallocations, the attacker must bypass network buffering by disabling Nagle's algorithm (TCP_NODELAY) on the sending socket. This forces the server's TCP stack to process each packet individually, prompting HTTP.sys to perform incremental reallocations.\n\nThe attacker establishes a standard TCP connection (and TLS handshake if HTTPS is used) and begins transmitting the HTTP request. By sending over 65535 custom headers (e.g., X-Pad-1: value1, X-Pad-2: value2), the attacker sequentially increases the driver's internal header counter. Each byte is streamed separately, which forces the driver's parser to continually invoke the reallocation block and eventually trigger the integer wraparound.\n\nOnce the wraparound occurs, the next parsed header triggers the allocation of a 40-byte buffer. The memmove operation then executes, copying the existing 524,256 bytes of header pointer data into the 40-byte heap allocation. By carefully structuring the layout of the kernel pool memory prior to this overflow, an attacker can overwrite critical kernel pointers or page table entries to redirect execution flow to shellcode. If the memory layout is not carefully prepared, the overflow corrupts the heap metadata, immediately causing a bug check crash.

The impact of CVE-2026-47291 is classified as Critical, with a CVSS base score of 9.8. Because the vulnerability resides in HTTP.sys, which runs in kernel mode (Ring 0), exploitation allows the attacker to execute code with the highest privileges available on the Windows operating system. Successful exploitation circumvents all user-mode security controls, virtual secure mode, and sandboxes, granting full system compromise.\n\nFailed exploit attempts pose a severe threat to operational continuity. Because the heap-based buffer overflow corrupts kernel pool memory, any mismatch or invalid pointer dereference will trigger a kernel bug check (BSOD). This allows remote, unauthenticated attackers to easily execute Denial of Service (DoS) attacks against exposed enterprise infrastructure, web servers, and administrative endpoints like WinRM.\n\nThreat intelligence indicates that this vulnerability is highly attractive to malicious actors. Public proof-of-concept scripts have been released on platforms like GitHub, such as https://github.com/dhmosfunk/CVE-2026-49160-CVE-2026-47291-HTTP.sys and https://github.com/ManagerEmpty/CVE-2026-47291-httpsys. Additionally, weaponized commercial exploits have been observed on decentralized markets like SatoshiDisk, raising the likelihood of active exploitation in enterprise networks.

The primary remediation strategy for CVE-2026-47291 is the application of the Microsoft June 2026 cumulative security updates. These updates patch the HTTP.sys kernel driver, resolving the integer overflow by migrating the tracking variables to 32-bit types and adding strict boundary checks prior to memory allocation. Organizations should prioritize updating all Windows Server and client machines, particularly those hosting public-facing web applications or utilizing WinRM services.\n\nIf immediate patching is not feasible, several defensive workarounds can reduce the attack surface. Organizations should deploy Web Application Firewalls (WAF) or reverse proxies in front of vulnerable IIS servers. These middleboxes should be configured to strictly enforce maximum limits on the total number of headers (e.g., maximum of 100) and the maximum request header size (e.g., limit to 8 Kilobytes), dropping any non-compliant requests before they reach the Windows HTTP stack.\n\nAdditionally, administrators can configure local registry keys to restrict header processing limits on the target IIS servers. For instance, modifying the MaxFieldLength and MaxRequestBytes registry values under the registry path HKLM\System\CurrentControlSet\Services\HTTP\Parameters enforces maximum size limits on headers in the driver itself. While this does not prevent the underlying bug, it limits the size of payloads that can be successfully parsed, disrupting the ability to send the required 65,535 headers to trigger the overflow.