A locked vault with a keyhole big enough to reach through — but only if someone widened the slot first
CVE-2026-47291 is an integer overflow in the HTTP.sys kernel-mode HTTP driver that ships with every supported version of Windows (10 1607 through 11 26H1, Server 2012 through 2025). During HTTP/1.x-over-TLS header parsing, a 16-bit capacity field in the buffer reference array wraps from 0xFFFB to 0x0000 after roughly 13,107 growth events. The subsequent allocation computes only 40 bytes, but memmove copies ~524 KB of header data into it, producing a massive kernel pool heap buffer overflow. The attacker needs to send approximately 65,536 separate TLS records totaling ~262 KB, which takes about 11 minutes over a sustained connection. Affected services include IIS, WinRM, WCF, SSTP, and any application using the HTTP Server API. The critical gate is the MaxRequestBytes registry value: it must be explicitly raised to at least 262,144 bytes. The Windows default of 16,384 bytes causes HTTP.sys to reject the oversized request before the integer wrap occurs.
Microsoft rates this CRITICAL 9.8 with an unauthenticated remote vector, and the CVSS math is technically accurate — no auth, no interaction, network-reachable, kernel-level impact. However, the vendor score does not account for the non-default MaxRequestBytes precondition. Systems at default configuration are not exploitable. Enterprises that raise MaxRequestBytes tend to do so for large Kerberos token environments (many AD group memberships) — which ironically means the servers most likely to be vulnerable are high-value ones like Exchange, ADFS, and SharePoint. This tension — narrow exploitable population, but high-value targets within it — is why a blanket CRITICAL overstates fleet-wide risk while a MEDIUM would dangerously ignore the servers that matter most.
5 steps from start to impact.
Identify TLS-enabled HTTP.sys listener
HTTP/1.1 response from the kernel stack qualifies. Shodan/Censys dorks for Server: Microsoft-HTTPAPI or IIS banners surface candidates in seconds.- Target exposes an HTTPS port (443, 5986, 8443, etc.) backed by HTTP.sys
- Internal-only WinRM/WCF listeners are not reachable from the internet
- Load balancers or reverse proxies (F5, NGINX, Cloudflare) in front of IIS terminate TLS themselves, preventing the record-level manipulation this exploit requires
Microsoft-HTTPAPI; GreyNoise tags for HTTP.sys probing (none confirmed for this CVE as of Oct 2026)Confirm non-default MaxRequestBytes
400 Bad Request — Header Too Long, the default limit is in place and the target is not exploitable. If the server accepts the oversized request, MaxRequestBytes has been raised and the target moves to the next stage. The w3bd3vil PoC (omair2084/misc on GitHub) implements this as its probe mode.- MaxRequestBytes registry value must be ≥262,144 bytes (default is 16,384)
- The vast majority of Windows installations use the default 16,384-byte limit
- Raising MaxRequestBytes is a deliberate admin action, typically done for large Kerberos token environments — estimated 5–15% of enterprise IIS servers
- WAFs with request-size limits will block the probe
Stream 65,536 TLS records over ~11 minutes
- Stable network path to the target for ~11 minutes
- No connection timeout shorter than 11 minutes on intermediary devices
- Enterprise firewalls and load balancers typically enforce connection idle timeouts (60–300 seconds) that would sever the connection
- IDS/IPS systems (e.g., Check Point CPAI-2026-6526) can detect and block the anomalous TLS record pattern
- The 11-minute dwell time is conspicuous in NetFlow/connection logs
BadRequest / Request_Header_Too_Long)Trigger integer wrap and heap overflow
capacity field overflows from 0xFFFB to 0x0000. The next buffer reference addition triggers a reallocation computing only 40 bytes (0x28 + 0 * 8). The subsequent memmove copies ~524 KB of accumulated header data into this 40-byte buffer, overwriting adjacent kernel pool allocations. This is a deterministic overflow — no ASLR bypass or info leak is needed to cause the crash.- All 65,536 records must arrive intact and be parsed without rejection
- Kernel pool layout must be favorable for code execution rather than just a bugcheck (BSOD)
- HVCI (Hypervisor-protected Code Integrity) on Windows 11/Server 2025 constrains kernel pool exploitation
Achieve kernel-mode code execution
- Favorable kernel pool layout (no HVCI, or HVCI bypass)
- Exploit payload must be tailored to the target OS build and pool allocator version
- HVCI on modern Windows 11 and Server 2025 makes reliable kernel code execution substantially harder
- Pool layout randomization across builds requires per-target tuning
- A failed attempt results in an immediate BSOD, alerting defenders and requiring the 11-minute attack to restart
HKLM\System\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes to 16384 (DWORD) on all Windows servers, or 65534 if larger headers are genuinely required. Restart the HTTP service (net stop http && net start http) or reboot. This completely eliminates the attack vector by causing HTTP.sys to reject requests before the integer overflow can occur. Deploy within 30 days per the noisgate mitigation SLA for HIGH-severity findings. Use Group Policy Preferences or SCCM compliance baselines to enforce fleet-wide.MaxRequestBytes.- Windows Firewall / host-based firewall rules — HTTP.sys listens on ports that must be open for the service to function (80, 443, 5986). Blocking these ports disables the service entirely, which is not a compensating control but a service outage.
- Application-layer request size limits in IIS (maxAllowedContentLength, maxRequestLength) — These control request *body* size, not header size. The overflow is in header parsing, which occurs before these limits are evaluated. They do not help.
- Disabling HTTP/2 or HTTP/3 — The vulnerability is in HTTP/1.x parsing specifically. Disabling newer protocols does not reduce exposure and may actually force more connections through the vulnerable code path.
- Network segmentation alone — While segmentation limits lateral movement *after* compromise, it does not prevent exploitation of internet-facing HTTP.sys services. It is a blast-radius reducer, not a preventive control for this CVE.
The supporting signals.
| In-the-wild status | No confirmed exploitation in the wild. Not listed in CISA KEV. Microsoft rates exploitation more likely. No GreyNoise tags observed as of Oct 2026. |
|---|---|
| Proof-of-concept | Functional PoC available: omair2084/misc/cve_2026_47291_poc.py on GitHub by researcher w3bd3vil (180 lines, Python 3). Supports probe mode (safe recon) and attack mode (triggers kernel pool overflow / BSOD). A second repo ManagerEmpty/CVE-2026-47291-httpsys was listed but returned 404 (likely removed or fake). |
| EPSS | 0.00974 (0.97%) — below the 10th percentile. Some aggregators report higher values (up to 22.8%) depending on model version and date; the user-provided figure is used here. |
| KEV status | Not listed in CISA Known Exploited Vulnerabilities catalog as of 2026-10-03. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 9.8 CRITICAL. Vector implies trivially exploitable from the network. However, the non-default MaxRequestBytes precondition is not captured in the CVSS base score, making the effective attack complexity closer to AC:H in practice. |
| Affected versions | Windows 10 (1607, 1809, 21H2, 22H2), Windows 11 (23H2, 24H2, 25H2, 26H1), Windows Server 2012, 2012 R2, 2016, 2019, 2022, 2025 — all editions prior to the June 2026 cumulative update. |
| Fixed versions | June 2026 Patch Tuesday cumulative updates (KB numbers vary by OS build). Apply via WSUS, SCCM, Windows Update, or Intune. No out-of-band patch was released. |
| Scanning / exposure | Shodan shows ~2.1M internet-facing IIS servers and ~380K Microsoft-HTTPAPI endpoints globally. Unknown fraction have MaxRequestBytes raised. Check Point released IPS signature CPAI-2026-6526. Qualys and Nessus have detection plugins available. |
| Disclosure date | 2026-06-09 (June 2026 Patch Tuesday) |
| Reporting researcher | Credited to Microsoft internal security team (MSRC). No external researcher named. ZDI published detailed analysis on 2026-07-09. w3bd3vil published the PoC independently. |
Sources.
- ZDI Technical Analysis — CVE-2026-47291 HTTP.sys RCE
- CrowdStrike June 2026 Patch Tuesday Analysis
- Microsoft MSRC Advisory — CVE-2026-47291
- w3bd3vil PoC — cve_2026_47291_poc.py (GitHub)
- Check Point IPS Signature CPAI-2026-6526
- IntegSec — CVE-2026-47291 Business Impact and Response
- Microsoft HTTP.sys Registry Settings Documentation
- ProArch — CVE-2026-47291 Vulnerability Explained
Why this verdict
- Non-default configuration gate: The exploit requires
MaxRequestBytesto be raised to ≥262,144 bytes — over 16× the Windows default of 16,384. Systems at default configuration are completely immune. This is a decisive narrowing that CVSS AC:L does not capture. Conservatively, 5–15% of enterprise IIS servers have this value raised (primarily for Kerberos large-token support), reducing the exploitable population by 85–95%. - 11-minute sustained connection requirement: The attack needs ~65,536 TLS records streamed over approximately 11 minutes without interruption. Enterprise load balancers, WAFs, and firewall connection timeouts (commonly 60–300 seconds) will sever most attempts before the overflow triggers. This is meaningful friction absent from the CVSS score.
- Kernel exploitation reliability: Even after triggering the heap overflow, achieving code execution (vs. a BSOD) depends on pool layout. HVCI — enabled by default on Windows 11 and Server 2025 secured-core — further constrains kernel-mode exploitation. A failed attempt causes an immediate, visible crash.
- Role multiplier: HTTP.sys is the kernel HTTP stack for IIS, WinRM, WCF, ADFS, Exchange OWA/ECP, and SharePoint. In the high-value role (internet-facing Exchange, ADFS, SharePoint in large AD environments),
MaxRequestBytesis commonly raised for Kerberos token handling — meaning the servers most likely to be exploitable are also the highest-value targets. Blast radius on a compromised Exchange server is mailbox-scale data exfiltration and potential domain escalation. On ADFS, it is identity-federation-scale compromise. This high-value-role overlap establishes a floor of HIGH despite the narrow exploitable population. - PoC availability: A functional Python PoC with probe and attack modes is public. While not weaponized for reliable RCE, it reliably triggers BSOD, and the overflow primitive is well-understood. Weaponization timeline is weeks, not months.
Why not higher?
CRITICAL would require most deployments to be exploitable at default configuration, which they are not. The MaxRequestBytes precondition is a hard gate — not a soft one that attackers can bypass. The 11-minute connection dwell and the kernel pool reliability challenge further compound against trivial mass exploitation. No in-the-wild exploitation or KEV listing supports keeping the assessment at CRITICAL.
Why not lower?
Dropping to MEDIUM would ignore that the exploitable subset — servers with raised MaxRequestBytes — disproportionately consists of high-value enterprise infrastructure (Exchange, ADFS, SharePoint) in exactly the AD environments with large token sizes. A functional PoC exists, Microsoft rates exploitation as 'more likely,' and successful exploitation yields kernel-level code execution on internet-facing hosts. The deployment-role floor analysis mandates HIGH minimum.
Crowdsourced verification payload.
Run this script on each target Windows host as a local administrator. Invoke with: powershell -ExecutionPolicy Bypass -File Check-CVE202647291.ps1. No network access or external dependencies required. The script checks the OS patch level against the June 2026 fix and inspects the MaxRequestBytes registry value to determine exploitability.
#Requires -RunAsAdministrator
<#
Check-CVE202647291.ps1
Checks whether the current host is vulnerable to CVE-2026-47291
(HTTP.sys integer overflow / heap buffer overflow).
Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
#>
$ErrorActionPreference = 'Stop'
# --- 1. Check OS build against June 2026 cumulative update ---
$os = Get-CimInstance Win32_OperatingSystem
$build = [System.Environment]::OSVersion.Version
# June 2026 patch builds (approximate - adjust per KB):
# Win10 22H2: 19045.5700+ Win11 24H2: 26100.4200+ Server 2022: 20348.3500+
# Server 2025: 26100.4200+ Win11 23H2: 22631.5700+
$patchedBuilds = @{
'19045' = 5700 # Win10 22H2
'19044' = 5700 # Win10 21H2
'22631' = 5700 # Win11 23H2
'26100' = 4200 # Win11 24H2 / Server 2025
'20348' = 3500 # Server 2022
'17763' = 7200 # Win10 1809 / Server 2019
'14393' = 8800 # Win10 1607 / Server 2016
}
$majorBuild = $build.Build.ToString()
$revisionRaw = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name UBR -ErrorAction SilentlyContinue).UBR
if (-not $revisionRaw) { $revisionRaw = $build.Revision }
$patched = $false
if ($patchedBuilds.ContainsKey($majorBuild)) {
if ($revisionRaw -ge $patchedBuilds[$majorBuild]) {
$patched = $true
}
}
# --- 2. Check MaxRequestBytes registry value ---
$regPath = 'HKLM:\System\CurrentControlSet\Services\HTTP\Parameters'
$maxReqBytes = 16384 # default
try {
$regVal = Get-ItemProperty -Path $regPath -Name MaxRequestBytes -ErrorAction SilentlyContinue
if ($regVal) { $maxReqBytes = $regVal.MaxRequestBytes }
} catch { }
$exploitableConfig = ($maxReqBytes -ge 262144)
# --- 3. Check if HTTP.sys driver is loaded ---
$httpSysLoaded = $null -ne (Get-Service -Name 'HTTP' -ErrorAction SilentlyContinue | Where-Object { $_.Status -eq 'Running' })
# --- 4. Report ---
Write-Host "=== CVE-2026-47291 Check ==="
Write-Host "OS: $($os.Caption) (Build $majorBuild.$revisionRaw)"
Write-Host "HTTP.sys running: $httpSysLoaded"
Write-Host "MaxRequestBytes: $maxReqBytes (exploitable threshold: >= 262144)"
Write-Host "Patch applied: $patched"
Write-Host ""
if ($patched) {
Write-Host "PATCHED - June 2026 cumulative update detected." -ForegroundColor Green
exit 0
} elseif (-not $httpSysLoaded) {
Write-Host "UNKNOWN - HTTP.sys service is not running. Host may still be vulnerable if service starts later." -ForegroundColor Yellow
exit 2
} elseif ($exploitableConfig) {
Write-Host "VULNERABLE - Unpatched AND MaxRequestBytes ($maxReqBytes) is at or above exploitable threshold (262144)." -ForegroundColor Red
Write-Host "ACTION: Apply June 2026 patch immediately, or set MaxRequestBytes to 16384 as interim mitigation." -ForegroundColor Red
exit 1
} else {
Write-Host "VULNERABLE (mitigated by default config) - Unpatched but MaxRequestBytes ($maxReqBytes) is below exploitable threshold." -ForegroundColor Yellow
Write-Host "Exploitation is blocked by current MaxRequestBytes value. Apply June 2026 patch to fully remediate." -ForegroundColor Yellow
exit 1
}