CVE-2026-47291 | HTTP protocol | RCE
| Vulnerability | CVE-2026-47291 |
|---|---|
| Type | Unauthenticated Remote Code Execution (Kernel-level) / Integer Overflow → Heap Buffer Overflow (CWE-190 / CWE-122) |
| Description | A vulnerability in the Windows kernel-mode HTTP protocol stack (http.sys) may allow an unauthenticated, remote attacker to execute arbitrary code with kernel-level privileges on an affected system by sending a specially crafted HTTP request that is larger than 65,535 bytes. The flaw is due to a 16-bit integer overflow in the HTTP request parsing logic. When the total request header size becomes near or over the maximum value that can be stored in 16 bits (65,535 bytes), the parser uses wraparound arithmetic to calculate an allocation size that is much smaller than the data written, by several orders of magnitude. This results in a heap buffer overflow in the kernel memory . An attacker can manipulate neighboring heap structures and execute arbitrary code in kernel mode . The http.sys component is used by IIS, Windows Communication Foundation (WCF), Windows Remote Management (WinRM), and other Windows HTTP-backed services; however, only systems where the MaxRequestBytes registry value has been explicitly raised above 65,535 are exploitable. Systems using the Windows default value (16,384 bytes) are not affected. |
| Affected Systems | - Windows 10 (all supported versions, including build 1809 and later) - Windows 11 (all supported versions) - Windows Server 2012 R2, 2016, 2019, 2022, 2025 (all supported versions) - Vulnerable configuration: Any system where HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes has been set to a value greater than 65,535 bytes.- Default configuration (NOT vulnerable): Systems using the Windows default MaxRequestBytes value of 16,384 bytes are not exploitable. Verify your registry setting before panicking.- Affected services/applications: IIS, WCF, WinRM, ASP.NET applications, custom Windows HTTP Server API-based applications. - Red Hat, CentOS, other non-Windows OS: Not affected. |
| Attack Vector | - Protocol: HTTP/HTTPS over TCP (any port where HTTP.sys is listening; commonly 80, 443, or custom admin ports) - Authentication: None required (pre-authentication) - User Interaction: None required - Attack Complexity: Low (attacker must craft and send a single malformed HTTP request) - Privileges Gained: Kernel-level (NT AUTHORITY\SYSTEM) — equivalent to root/administrator with unrestricted kernel access - Target: Any internet- or network-reachable HTTP listener backed by http.sys (IIS sites, WinRM endpoints, WCF services, ASP.NET Core on Windows, custom HTTP Server API applications)- Payload Delivery: A specially crafted HTTP request (GET, POST, or other method) with header(s) and/or body payload engineered such that the total request size exceeds 65,535 bytes, triggering the integer overflow |
| Exploit Mechanism | The attack leverages an integer overflow in the http.sys request size check logic:1. Received Request: An HTTP request is received by an http.sys listener, either on a port exposed to the network or an internal port.2. Size calculation: http.sys uses 16-bit unsigned integer arithmetic to calculate the total size of the request. As the request grows, this counter gets closer to 0xFFFF (65535 bytes).3. Integer overflow: If the total request data size exceeds 0xFFFF, the 16-bit counter, it rolls over to a small value (e.g. if a request is 65,551 bytes, it will be counted as 0x0010 = 16 bytes).4. Mismatch of memory allocation: The wrapped value is used to allocate a heap buffer, e.g. 16 bytes. Meanwhile, the parser has consumed 65551 bytes (or more) of data. 5. Heap buffer overflow: The parser writes all 65,551+ bytes into the 16-byte buffer, overwriting adjacent heap metadata, other objects, and potentially kernel function pointers. 6. Heap corruption: An attacker constructs the request payload so that it overwrites a function pointer or heap structure used by the kernel’s heap manager or http.sys.7. Code execution: Attacker-supplied code (embedded within the oversized request) executes with kernel privileges when the compromised heap structure is processed or the compromised function pointer is dereferenced. 8. Privilege and Impact: It runs in kernel context and has full access to all system memory, device drivers, and kernel APIs. This implies full system compromise, persistence, and lateral movement to any process or resource. |
| The Impact of the Bug | Successful exploitation results in immediate remote code execution at the kernel level on the victim Windows system. The attacker has complete and unrestricted access with kernel mode capability level equivalent to SYSTEM privilege and can:- Use kernel-mode rootkits or persistence mechanisms that persist across reboots and avoid user-mode detection. - Dump credentials and encryption keys from memory (e.g., DPAPI secrets, Kerberos tickets, and Bitlocker recovery keys). - Disabling/bypassing of Windows Defender, Windows Firewall and other security tools in kernel mode. - Access to cloud metadata services (AWS IMDSv2, Azure Instance Metadata Service, GCP Metadata Server) if the system is deployed in a cloud environment, potentially leading to compromise of cloud credentials and IAM tokens. - Reads all storage directly and can exfiltrate sensitive data: databases, config files, intellectual property. - Lateral movement into the larger network using compromised credentials or as a pivot point for worm-like malware. - Disrupt availability - deploy ransomware, disable critical applications, or deploy cryptocurrency miners that use the full kernel context. - Impersonate any user, service account or domain account and use those privileges to perform attacks. Critical note: http.sys is kernel mode code, and any exploit running in that context will bypass most endpoint detection and response (EDR) tools, which typically operate at user mode. CVSS Severity: Critical (10) EPSS likelihood is currently low (0.2%), meaning no known public PoC or active wild exploitation at disclosure, but this should not delay patching—the vulnerability is confirmed, the component is widely deployed, and exploit development is likely underway. |
| How to detect if you have a vulnerable application to this attack vector? | - Step 1. Check your MaxRequestBytes registry value. Run a Command Prompt or PowerShell as Administrator and run:reg query HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters /v MaxRequestBytes- If this value is not listed or returns (value not set), you are using the default (16,384 bytes) and are NOT vulnerable.- If the value is 65,535 or less, you are NOT vulnerable. If the value is greater than 65,535, you ARE exploitable. - Step 2: Identify affected services. List all http.sys backed services on your machine:- IIS (check all websites and app pools) - WinRM (check winrm enumerate winrm/config/listener)- WCF services (check Windows Event Logs and Service Control Manager) - Custom HTTP Server API applications (review running processes and network listeners) - Step 3: Network visibility. Identify all external-facing and internal HTTP(S) services using vulnerability scanners, Shodan/Censys, or internal port scans: - Port 80 (HTTP) - Port 443 (HTTPS) - Custom ports (admin interfaces, development servers, isolated management LANs) - Step 4: Host-based detection. Monitor IIS and HTTP.sys logs for abnormally large HTTP requests or protocol violations: - IIS log field cs-bytes (request size) or sc-bytes (response size) showing values > 65,535- HTTP.sys event logs (Windows Event Viewer > Applications and Services Logs > Microsoft-Windows-HttpEvent) for truncation or protocol errors on large requests - Network IDS/IPS alerts for HTTP requests with Content-Length or Transfer-Encoding fields indicating payloads > 65,535 bytes - Step 5: Windows Update status. Check Windows Update history for the June 2026 security patch (KB number to be determined by Microsoft): Get-HotFix -Module KB (Windows 10/11/Server 2019+)Or review Settings > Update & Security > Update History. |
| Mitigation Steps | Immediate Patching (Priority 1): - Apply the June 2026 Microsoft Security Update for Windows (Patch Tuesday release) containing the fix for CVE-2026-47291. - Follow the Microsoft Security Response Center (MSRC) guidance at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47291 for your specific Windows version. - Ensure all cumulative rollups and security updates are installed; do not skip intermediate patches. Interim Mitigation (if immediate patching is not possible): - For systems with elevated MaxRequestBytes: If your registry value is > 65,535, immediately lower it to a value below 65,535 (e.g., 65,536 or 65,535 itself does NOT help; use 32,768 or less). Execute the following in PowerShell as Administrator: powershell<br> reg add "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v MaxRequestBytes /t REG_DWORD /d 32768 /f<br> net stop HTTP<br> net start HTTP<br> # Or reboot if services do not restart cleanly<br>Note: Verify that your applications (IIS, WCF, WinRM) continue to function with the reduced limit. Most applications use far less than 65 KB per request, but custom applications or file-upload scenarios may be affected. - For systems with default MaxRequestBytes (16,384): No configuration change is required; you are not exploitable. Do not raise this value unnecessarily. Network Controls / WAF-IDS: - At the network perimeter, identify and block or rate-limit inbound HTTP(S) requests with abnormally large headers or bodies (> 65,535 bytes or even a lower threshold like 32 KB if your workload allows). - Use Web Application Firewalls (WAF) to reject requests with excessively large Content-Length, Transfer-Encoding, or custom headers.- Restrict HTTP.sys-backed services (especially WinRM, IIS admin interfaces) to trusted source IPs; deny public internet access if not required. - Review reverse proxy configurations (if any exist in front of IIS) to ensure malformed requests are not blindly forwarded; consider adding request-size validation at the proxy layer. If Patching and Mitigation Are Not Possible: - Disable unnecessary HTTP.sys services. If WinRM, IIS, or WCF are not required, disable them entirely: <br> # Disable IIS<br> iisreset /stop<br> # Disable WinRM<br> Stop-Service WinRM; Set-Service WinRM -StartupType Disabled<br> # Disable HTTP.sys listener for custom apps (context-dependent)<br>- Isolate affected systems to internal-only networks; do not expose them to the internet or untrusted segments. - Plan an emergency patching window for the affected systems; treat this as a high-priority security incident until patched. Post-Remediation: - Review logs for exploitation attempts: examine IIS logs and HTTP.sys event logs for requests with anomalous sizes or protocol violations dating back weeks (in case of pre-patch reconnaissance or exploitation). - If compromise is suspected: Assume kernel-level rootkit installation. Conduct a full forensic analysis, check for persistence mechanisms (kernel drivers, scheduled tasks, WMI event subscriptions), rotate all credentials, and validate system integrity using offline boot tools or bare-metal recovery imaging. - Monitor for lateral movement: Attackers who compromise a system via this vulnerability have kernel-level access and can forge Kerberos tickets, impersonate accounts, or pivot laterally. Review domain logs and inter-system communication for anomalies. |
| References | - https://nvd.nist.gov/vuln/detail/CVE-2026-47291 - https://www.cve.org/CVERecord?id=CVE-2026-47291 - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47291 - https://www.ionix.io/threat-center/cve-2026-47291/ - https://windowsforum.com/threads/cve-2026-47291-confirmed-windows-http-sys-rce-patch-tuesday-priority-guide.424352/ - https://www.zerodayinitiative.com/blog/2026/6/9/the-june-2026-security-update-review - https://thehackernews.com/2026/06/microsoft-patches-record-206-flaws.html - https://advisories.checkpoint.com/defense/advisories/public/2026/cpai-2026-6526.html - https://cybersixt.com/cve/CVE-2026-47291 |