← Back to Feed CACHED · 2026-10-03 01:17:15 · CACHE_KEY CVE-2026-47291
CVE-2026-47291 · CWE-122 · Disclosed 2026-06-09

Windows HTTP.sys Kernel-Mode Integer Overflow Leading to Remote Code Execution

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Kernel RCE via HTTP.sys, but only fires when MaxRequestBytes is raised far above default"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify TLS-enabled HTTP.sys listener

The attacker scans for HTTPS services backed by HTTP.sys — IIS, WinRM (5986), WCF endpoints, or SSTP VPN. Any Windows server answering HTTPS with an HTTP/1.1 response from the kernel stack qualifies. Shodan/Censys dorks for Server: Microsoft-HTTPAPI or IIS banners surface candidates in seconds.
Conditions required:
  • Target exposes an HTTPS port (443, 5986, 8443, etc.) backed by HTTP.sys
Where this breaks in practice:
  • 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
Detection/coverage: Shodan/Censys fingerprint Microsoft-HTTPAPI; GreyNoise tags for HTTP.sys probing (none confirmed for this CVE as of Oct 2026)
STEP 02

Confirm non-default MaxRequestBytes

The attacker sends a probe request with headers just above 16,384 bytes. If HTTP.sys returns 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.
Conditions required:
  • MaxRequestBytes registry value must be ≥262,144 bytes (default is 16,384)
Where this breaks in practice:
  • 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
Detection/coverage: IIS logs will show unusually large header sizes; Qualys/Nessus registry audit checks for MaxRequestBytes deviation from default
STEP 03

Stream 65,536 TLS records over ~11 minutes

The attacker opens a single TLS connection and sends ~65,536 individual TLS records, each containing a small HTTP header line. Each record is independently decrypted by SChannel and delivered to HTTP.sys as a separate buffer reference. This takes approximately 11 minutes at 10ms per record. The sustained connection must not be interrupted by timeouts, keep-alive limits, or network disruptions.
Conditions required:
  • Stable network path to the target for ~11 minutes
  • No connection timeout shorter than 11 minutes on intermediary devices
Where this breaks in practice:
  • 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
Detection/coverage: Check Point IPS signature CPAI-2026-6526; Suricata/Snort rules matching >1,000 HTTP header lines; anomaly detection on TLS record count per connection; Windows HTTP error logs (BadRequest / Request_Header_Too_Long)
STEP 04

Trigger integer wrap and heap overflow

At growth event 13,107, the 16-bit 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.
Conditions required:
  • All 65,536 records must arrive intact and be parsed without rejection
Where this breaks in practice:
  • 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
Detection/coverage: Windows bugcheck (BSOD) with stop code referencing HTTP.sys pool corruption; kernel crash dumps reveal the overflow pattern
STEP 05

Achieve kernel-mode code execution

If pool layout is favorable, the attacker overwrites a kernel object function pointer or pool header to redirect execution. Code runs as SYSTEM in kernel context, giving full control of the host — credential extraction, lateral movement, persistence, or destructive action. On hardened configurations (VBS, HVCI), exploitation complexity rises significantly, and the outcome may be limited to denial of service (BSOD).
Conditions required:
  • Favorable kernel pool layout (no HVCI, or HVCI bypass)
  • Exploit payload must be tailored to the target OS build and pool allocator version
Where this breaks in practice:
  • 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
Detection/coverage: EDR kernel telemetry (e.g., CrowdStrike Falcon, Microsoft Defender for Endpoint kernel tampering alerts); Windows Event Log System crash events; crash dump analysis
03 · Compensating Control

1
HIGH 8.1→IGNORE 0.0
SEVERITY REDUCED
Set MaxRequestBytes to 16384 (default) or at most 65534 — The single most effective mitigation. Set 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.
2
HIGH 8.1→LOW 3.1
SEVERITY REDUCED
Terminate TLS at a reverse proxy or load balancer, not at HTTP.sys — Place NGINX, HAProxy, F5, or Cloudflare in front of IIS to terminate TLS. The exploit requires direct TLS record manipulation against HTTP.sys's SChannel integration — a proxy that re-encapsulates HTTP breaks the record-level control the attacker needs. This also enforces connection timeouts and header count limits. Deploy within 30 days.
3
HIGH 8.1→MEDIUM 6.5
SEVERITY REDUCED
Enable IPS signature for CVE-2026-47291 — Deploy Check Point IPS signature CPAI-2026-6526 or equivalent Snort/Suricata rules that alert on HTTP requests with >1,000 header lines or anomalous TLS record counts. This provides network-level detection and blocking for the 11-minute streaming phase. Deploy within 30 days.
4
HIGH 8.1→MEDIUM 5.5
SEVERITY REDUCED
Enable HVCI and VBS on Windows 11 / Server 2025 — Hypervisor-protected Code Integrity (HVCI) prevents unsigned code execution in the kernel, raising the bar from heap overflow to reliable RCE significantly. This does not prevent the BSOD/DoS outcome but blocks the most dangerous code-execution path. Applicable only to compatible hardware and OS versions. Deploy within 30 days.
5
HIGH 8.1→IGNORE 0.0
SEVERITY REDUCED
Apply June 2026 cumulative update — The definitive fix. Install the June 2026 Patch Tuesday cumulative security update on all affected Windows systems. This patches the integer overflow in HTTP.sys directly. Target deployment within 180 days per the noisgate remediation SLA for HIGH-severity findings, or faster if your environment has raised MaxRequestBytes.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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-conceptFunctional 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).
EPSS0.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 statusNot listed in CISA Known Exploited Vulnerabilities catalog as of 2026-10-03.
CVSS vectorCVSS: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 versionsWindows 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 versionsJune 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 / exposureShodan 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 date2026-06-09 (June 2026 Patch Tuesday)
Reporting researcherCredited to Microsoft internal security team (MSRC). No external researcher named. ZDI published detailed analysis on 2026-07-09. w3bd3vil published the PoC independently.

Sources.

  1. ZDI Technical Analysis — CVE-2026-47291 HTTP.sys RCE
  2. CrowdStrike June 2026 Patch Tuesday Analysis
  3. Microsoft MSRC Advisory — CVE-2026-47291
  4. w3bd3vil PoC — cve_2026_47291_poc.py (GitHub)
  5. Check Point IPS Signature CPAI-2026-6526
  6. IntegSec — CVE-2026-47291 Business Impact and Response
  7. Microsoft HTTP.sys Registry Settings Documentation
  8. ProArch — CVE-2026-47291 Vulnerability Explained
05 · The Call

Final Verdict
↓ DOWNGRADED to HIGH (8.1/10)

Why this verdict

  • Non-default configuration gate: The exploit requires MaxRequestBytes to 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), MaxRequestBytes is 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.

06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#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
}