On 9 June 2026, Microsoft released patches for CVE-2026-47291 as part of a record-breaking Patch Tuesday that addressed more than 200 vulnerabilities in a single release. CVE-2026-47291 is a remote code execution vulnerability in HTTP.sys, the Windows kernel-mode driver that handles all HTTP and HTTPS traffic for Windows servers. The vulnerability carries a CVSS score of 9.8 and is exploitable by an unauthenticated attacker who sends a single crafted network packet to any Windows system listening on HTTP or HTTPS. A successful exploit yields SYSTEM-level privileges, the highest available on a Windows system, with no authentication, no user interaction, and no privilege boundary above the attacker. Zero Day Initiative and Microsoft both assessed exploitation as "more likely," a designation that indicates technical analysis suggests exploitation is achievable and probable in the near term.
HTTP.sys is a kernel-mode device driver that has been included in Windows since Windows Server 2003. It implements the HTTP protocol at the kernel level, which provides significant performance advantages for web server workloads because HTTP traffic can be processed without context switches between kernel mode and user mode for common operations. Internet Information Services, the built-in Windows web server, routes all its HTTP and HTTPS traffic through HTTP.sys. Many third-party Windows applications that expose HTTP endpoints also use HTTP.sys, either directly or through the Windows HTTP Server API.
The kernel-mode position of HTTP.sys has two important consequences for CVE-2026-47291. The first is scope: HTTP.sys handles traffic for every application on the system that uses the Windows HTTP stack, meaning that a vulnerability in HTTP.sys is not limited to a specific web application or service but affects the entire system. The second consequence is impact: code that executes within HTTP.sys runs at kernel privilege level, which is above all user-mode privilege boundaries including SYSTEM. A kernel-mode exploit does not need to perform privilege escalation after initial code execution because it is already at the highest privilege level on the system from the moment the exploit triggers.
CVE-2026-47291 combines two weakness types: CWE-190, an integer overflow, and CWE-122, a heap-based buffer overflow. The combination is a classic exploitation pattern where an integer overflow in a calculation that determines the size of a memory allocation causes the allocation to be smaller than the data that will subsequently be written into it. When the code then writes data into the undersized allocation, the write extends beyond the allocated buffer into adjacent heap memory.
In a kernel-mode component like HTTP.sys, heap memory is shared across all kernel operations on the system. Overwriting heap memory adjacent to an undersized HTTP.sys allocation can corrupt kernel data structures, overwrite function pointers, or manipulate kernel objects in ways that redirect execution to attacker-controlled code. The specific HTTP request processing path where the overflow occurs relates to how HTTP.sys handles certain request parameters, though Microsoft has not published the precise technical details to avoid providing an exploitation guide. The remediation, discussed later, involves a registry value that limits the maximum size of HTTP requests, which provides context for the general nature of the vulnerable parsing path.
Many high-severity vulnerabilities require the attacker to satisfy at least one precondition beyond network access: an existing user account, a user who clicks a link, a specific application running in a particular configuration. CVE-2026-47291 requires none of these. Any Windows system that accepts inbound HTTP or HTTPS connections is a valid target. The attacker sends one crafted packet. No authentication handshake precedes the vulnerability trigger. No user on the target system needs to do anything.
This combination has specific implications for organisations that use HTTP.sys-based services in publicly accessible configurations. A Windows web server, a Windows machine running the WinRM remote management service, an application that uses the HttpListener class, or any other service that binds to an HTTP or HTTPS port via the Windows HTTP Server API is a viable exploitation target. The attack requires only that the crafted packet reach the HTTP.sys listener, which means that firewall rules that permit inbound HTTP or HTTPS traffic for legitimate purposes also permit the exploit packet through. The attack surface for CVE-2026-47291 is every HTTP and HTTPS listener on every Windows system in the environment.
The consequence of successful exploitation is code execution at SYSTEM privilege level in kernel mode. SYSTEM is the highest privilege account on a Windows system in user mode, with unrestricted access to all resources. Kernel mode is a step above SYSTEM, operating with no privilege boundary enforced by the Windows security model above it. An attacker who achieves kernel code execution through CVE-2026-47291 can read and write any memory location in the system, install kernel-mode rootkits that survive reboots and evade user-mode security tools, disable security software including endpoint detection and response agents, create new administrative accounts, modify Windows Defender and firewall policies, and exfiltrate any data on the system or accessible to it through network connections.
The absence of any privilege escalation step after initial exploitation is what makes kernel-mode exploits particularly valuable to threat actors. A common pattern in Windows exploitation chains involves chaining a remote code execution vulnerability that provides user-mode execution with a separate local privilege escalation vulnerability that elevates from a limited user context to SYSTEM. CVE-2026-47291 collapses this two-step chain into a single step: one packet, SYSTEM. This makes the vulnerability exceptionally useful as a first stage in a ransomware deployment, a lateral movement operation, or a persistent access campaign.
Microsoft's advisory confirms that CVE-2026-47291 affects every currently supported version of Windows client and server operating systems, from Windows 10 version 1607 through Windows 11 version 26H1, and from Windows Server 2012 through Windows Server 2025. This breadth is a function of HTTP.sys being a fundamental component of the Windows platform that has been present and largely unchanged across multiple major Windows versions. A vulnerability in shared infrastructure code of this kind does not confine itself to a single product generation.
For organisations that have not fully migrated to current Windows versions, the scope of CVE-2026-47291 means that end-of-mainstream-support versions including Windows Server 2012 and 2012 R2 are also affected. Microsoft typically does not provide patches for out-of-support systems as part of Patch Tuesday releases. Organisations running Windows Server 2012 or 2012 R2 without Extended Security Updates should investigate their options, which include Extended Security Update subscriptions that remain available through Azure or through volume licensing agreements for certain versions. Running an unpatched HTTP.sys component on an internet-accessible server in the current threat environment is an unacceptable risk posture, regardless of the support status of the underlying operating system.
Microsoft uses the designation "exploitation more likely" on its Exploitability Index for vulnerabilities where its security researchers assess that consistent, repeatable exploitation is technically achievable and that a threat actor with moderate skill could develop a working exploit. This designation does not mean exploitation has been confirmed in the wild at the time of the Patch Tuesday release, but it does mean that Microsoft expects working exploits to appear in the near term. For network-accessible kernel vulnerabilities with CVSS 9.8 scores, the window between patch release and first observed exploitation is often measured in days to weeks rather than months.
The "exploitation more likely" assessment should be treated as a signal to prioritise patching above other lower-severity items in the same Patch Tuesday release. For CVE-2026-47291 specifically, the combination of kernel-mode impact, no authentication, and broad version scope places it in the highest tier of urgency even within a record-breaking 200-plus CVE release cycle. Security teams that triage Patch Tuesday items by CVSS score and exploitability assessment will find CVE-2026-47291 at the top of both lists. Tracking threat intelligence on when active exploitation begins is essential to inform the actual urgency of the remediation timeline.
The June 2026 Patch Tuesday release addressed more than 200 vulnerabilities, including six zero-days and 32 vulnerabilities rated Critical, making it the largest single Patch Tuesday release in Microsoft's recorded history. CVE-2026-47291 is one of several critical RCE vulnerabilities in the June release, alongside CVE-2026-45657, a CVSS 9.8 use-after-free flaw in the Windows Kernel, and CVE-2026-42904, affecting TCP/IP stack processing.
The record volume of June's release creates a practical prioritisation challenge for security teams that must evaluate, test, and deploy patches across large Windows environments. When a Patch Tuesday release includes dozens of critical vulnerabilities, teams that work through them sequentially may take weeks to reach lower-priority items, during which time vulnerabilities like CVE-2026-47291 remain unpatched on production systems. Organisations with mature vulnerability management programmes should have prioritisation frameworks that automatically elevate network-accessible kernel RCEs with no authentication requirement to emergency patch status, separating them from the queue of standard Patch Tuesday items that are processed on a monthly maintenance schedule.
Microsoft's advisory notes that systems using the default MaxRequestBytes registry value of 16,384 bytes (16 KB) are not exposed to CVE-2026-47291. The vulnerability is triggered only when this value has been set higher than its default. As a pre-patch mitigation, Microsoft recommends that administrators verify the MaxRequestBytes registry value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters is set to no higher than 65,534 bytes to avoid exposure.
This mitigation detail is important for organisations that cannot patch immediately, but it requires careful validation. Many web server configurations and custom applications set MaxRequestBytes to higher values to accommodate large request payloads, file uploads, or complex API calls. Lowering this value to 65,534 bytes or the 16,384-byte default may break application functionality that depends on large HTTP request processing. Before applying the registry-based mitigation, administrators should verify the current value of MaxRequestBytes across their Windows server fleet and assess whether lowering it would affect production workloads. Where the current value is already at the default or below the mitigation threshold, no immediate registry change is required, but the June 9 patch should still be applied to address the underlying flaw.
The primary action is to apply Microsoft's June 9, 2026 patches for CVE-2026-47291 across all Windows systems in the environment, prioritising internet-accessible systems and internal systems running HTTP or HTTPS listeners on network segments accessible from the internet or from untrusted network zones. Systems that are fully isolated from any network access are not exposed to this vulnerability, but any system with a network listener of any kind should be treated as in-scope for the patch.
Before the patch can be deployed, verify the MaxRequestBytes registry value across your Windows server fleet. If it is at the default 16,384 bytes or has not been modified, the existing configuration is not exposed to this specific exploitation path. If it has been set above 65,534 bytes, lowering it below 65,534 is a pre-patch mitigation that reduces but does not eliminate risk, and the patch should be applied as quickly as possible regardless. After patching, monitoring indicators of compromise in HTTP.sys event logs and Windows security event logs for anomalous kernel-mode activity is the detection complement to the remediation action.
Yes. HTTP.sys handles both HTTP and HTTPS traffic on Windows, and CVE-2026-47291 affects the processing path that applies to both protocols. Running only HTTPS does not remove the vulnerable code path from the attack surface. The patching recommendation applies equally to systems that only expose HTTPS endpoints.
Yes. Microsoft's advisory lists all supported Windows client versions, including Windows 10 from version 1607 and Windows 11, as affected. However, the practical risk is lower for client systems because they typically do not run HTTP server software or expose HTTP listeners accessible from external networks. If a Windows 10 or Windows 11 system is running software that binds to an HTTP port, such as a development web server, a local API endpoint, or Windows Remote Management, the system is exposed to this vulnerability through those listeners.
No. The registry-based mitigation reduces exposure for systems where MaxRequestBytes has been set above the vulnerable threshold, but it is not a complete remediation. The underlying integer overflow flaw in HTTP.sys remains present on unpatched systems. The patch from Microsoft's June 9 Patch Tuesday release fixes the root cause. The registry mitigation should be used only as a temporary measure while the patch is being tested and deployed, not as a long-term substitute for applying the security update.
Both vulnerabilities carry CVSS 9.8 scores and both affect the Windows Kernel in the broad sense. CVE-2026-45657 is a use-after-free flaw in the Windows Kernel component itself, while CVE-2026-47291 is in HTTP.sys, the kernel-mode HTTP driver. The attack prerequisite differs: CVE-2026-45657 requires a local user or a lower-privilege process to have already reached the system, whereas CVE-2026-47291 is remotely exploitable with no prior access. For systems with internet-accessible HTTP listeners, CVE-2026-47291 represents a higher immediate risk because it does not require any prior foothold on the target.
Applications that use HTTP.sys include Internet Information Services (IIS), Windows Remote Management (WinRM), the .NET HttpListener class, the WCF HTTP transport, and many third-party Windows applications that use the Windows HTTP Server API. Any application that binds to an HTTP or HTTPS port on Windows via these mechanisms routes its traffic through HTTP.sys and is therefore exposed to CVE-2026-47291 through that binding. Applications that implement their own TCP-level HTTP processing without using the Windows HTTP Server API are not affected.
As of the June 9 Patch Tuesday release date, Microsoft had not confirmed active in-the-wild exploitation of CVE-2026-47291 but assessed it as "exploitation more likely." The window between patch release and first observed exploitation for vulnerabilities of this severity has shortened considerably over the past two years. Security teams should not use the absence of confirmed exploitation at patch release as a basis for deprioritising this vulnerability: patching should proceed on an emergency timeline regardless of whether exploitation has been publicly confirmed.
WSL instances run a separate Linux kernel and do not use HTTP.sys, so they are not directly affected by CVE-2026-47291. However, the Windows host on which WSL runs does use HTTP.sys, and if that host exposes HTTP or HTTPS listeners via the Windows HTTP stack, those listeners are exposed. Windows containers that use HTTP.sys through the host's kernel share the vulnerability with the host. The patch should be applied to the Windows host, which covers both the host's own HTTP listeners and any Windows containers that share the host kernel.
Not every Windows system faces the same level of risk from CVE-2026-47291. The attack requires an attacker to send a crafted packet to an HTTP or HTTPS listener on the target system. Systems that are entirely isolated from any network connectivity, or that have no active HTTP or HTTPS listeners, are not exposed. The immediate risk is concentrated in systems that are directly reachable from the internet with active HTTP or HTTPS listeners, such as public-facing web servers running IIS, Windows servers exposed to the internet for WinRM remote management, and applications that use the HttpListener class or the Windows HTTP Server API on internet-accessible systems.
Windows servers that are behind a web application firewall or a reverse proxy may have some protection if the WAF or proxy inspects HTTP requests before they reach HTTP.sys, depending on how the architecture is configured. However, organisations should not rely on WAF protection as a substitute for patching: WAF rules are typically written to filter known attack patterns, and a zero-day exploit may use request structures that do not match existing WAF rules. The MaxRequestBytes mitigation is more reliable than WAF filtering as a compensating control, but it also requires validation that changing this value does not break production application functionality. The priority order should be: verify the current MaxRequestBytes value, apply the patch, review the patched systems for signs of prior exploit activity. The indicators of compromise for a kernel-mode exploit may be subtle but are worth investigating on any internet-facing Windows server in the vulnerability window.
Incidents like this one rarely announce themselves through official channels first. Indicators of active exploitation, compromised infrastructure, and stolen credentials circulate in closed forums and private channels well before any public advisory reaches your security team. By the time a vulnerability makes it into a published report, organisations without early visibility are already operating behind the curve.
Defendis gives your security team that early visibility. We monitor the dark web, underground forums, and threat actor channels so your team receives relevant intelligence before it becomes breaking news, with context about emerging threats matched against your organisation's exposure, without requiring your analysts to spend time in places they should not have to go.
