Vulnerability Analysis

CVE-2026-47291: Windows HTTP.sys Integer Overflow RCE — How to Detect, Fix, and Harden

Executive Summary

CVE-2026-47291 is a critical remote code execution vulnerability in Windows HTTP.sys — the kernel-mode HTTP driver that powers IIS, Windows Remote Management, and any application built on the Windows HTTP Server API. An unauthenticated attacker can send a single crafted HTTP request to trigger an integer overflow, corrupt kernel heap memory, and achieve SYSTEM-level code execution with no user interaction required. Microsoft disclosed the flaw on June 9, 2026 as part of its record-setting Patch Tuesday release and rated exploitation as "More Likely." Organizations with internet-facing Windows servers should treat this as an emergency patching event.

1. What Is This Vulnerability?

The Root Cause: Integer Overflow in a Kernel HTTP Parser

HTTP.sys is a Windows kernel-mode driver (loaded as http.sys) that sits below IIS and every application using the Windows HTTP Server API. It handles raw TCP connections, SSL/TLS offload, request queuing, kernel-mode caching, and URL namespace routing — all before a single line of user-mode application code runs.

CVE-2026-47291 is an integer overflow (CWE-122) in the HTTP request parser inside this kernel-mode driver. When processing HTTP header fields, the parser performs arithmetic on field sizes using a fixed-width integer type. If header content is crafted to push the cumulative size calculation past the integer's maximum value, the counter wraps around to a small number — a classic integer wraparound. The now-undersized value is then used to allocate a kernel heap buffer that is far too small for the data that follows. Subsequent writes overflow that buffer, giving an attacker controlled writes into kernel heap memory.

From there, an attacker can use kernel heap grooming techniques to overwrite adjacent objects — function pointers, security tokens, or kernel structures — to redirect execution. Because HTTP.sys runs in kernel context, successful exploitation yields SYSTEM-level privileges with no boundary above them: complete control of the operating system.

Critical nuance: The integer overflow requires an oversized request to trigger. Systems that enforce the MaxRequestBytes registry value at or below the default (32768 bytes) are not affected by this bug, because the oversized request is rejected before the vulnerable code path is reached. Microsoft's advisory includes a PowerShell script to verify and enforce this setting as an interim mitigation while patches are deployed.

Attack Vector

1. Attacker identifies a Windows host running HTTP.sys (IIS, WinRM, 
   management portal, or any HTTP Server API application)

2. Attacker crafts an HTTP request with header fields sized to trigger 
   the integer wraparound in the kernel parser

3. The integer overflow causes kernel heap memory corruption

4. A follow-up request (or natural heap activity) triggers code execution 
   in kernel context — SYSTEM privileges achieved

5. Attacker has full OS control with no prior credentials required

The attack chain is entirely network-based. No authentication. No user interaction. No pre-existing foothold required.

Real-World Impact

As of the publication of this post, no confirmed mass-exploitation events have been publicly linked to CVE-2026-47291. However:

  • Microsoft explicitly rated this flaw "Exploitation More Likely" — their strongest pre-exploit confidence rating.
  • June 2026 Patch Tuesday shipped the largest cumulative Windows patch release in recorded history (208 CVEs by ZDI's count). Security researchers across the industry noted that binary diffing of the patched vs. unpatched http.sys driver would immediately narrow the search space for exploit developers.
  • HTTP.sys has a historical precedent: MS15-034 (CVE-2015-1635), another HTTP.sys RCE disclosed in 2015, was widely weaponized within 24 hours of disclosure and could be triggered with a single HTTP range header.
  • The 2026 release lands during an elevated threat landscape described by industry analysts as the "Mythos disclosure window" — a period of unusually high AI-assisted vulnerability research activity. The assumption that exploit code is actively being developed is well-founded.

2. Who Is Affected?

Affected Operating Systems (all builds prior to June 2026 Patch Tuesday):

Platform Affected Versions
Windows 10 1607 through 22H2
Windows 11 22H2, 23H2, 24H2, 26H1
Windows Server 2012 R2, 2016, 2019, 2022, 2025

Affected Services and Applications — any that bind to HTTP.sys:

  • IIS (Internet Information Services) — most obvious, but not the only exposure
  • Windows Remote Management (WinRM) — ports 5985 and 5986; present on most servers
  • Certificate Enrollment Web Service / CA Web Enrollment — ADCS over HTTP
  • ASP.NET Core hosted with the HTTP.sys server (as opposed to Kestrel)
  • Custom applications using the Windows HTTP Server API (httpapi.dll/http.sys)
  • Management portals, backup consoles, print servers, monitoring agents — any Windows-native daemon that calls HttpCreateRequestQueue or registers a URL prefix with HttpAddUrl
  • Third-party Windows appliances (security cameras, industrial controllers, embedded management interfaces) shipping Windows with HTTP-based dashboards

Not affected:

  • Hosts where MaxRequestBytes is at or below the default value of 32,768 bytes and the restriction is actually being enforced — verify with the PowerShell command in Section 4.
  • Applications using Kestrel behind a reverse proxy that terminates and normalizes HTTP before forwarding to the Windows host (the proxy must fully re-parse and re-serialize — pass-through proxies do not reduce risk).
  • Linux, macOS, and non-Windows systems (HTTP.sys is Windows-only).

3. How to Detect It (Testing)

Manual Testing Steps

Step 1: Identify all Windows hosts running HTTP.sys-backed services

On each Windows host, run from an elevated PowerShell prompt:

# List all registered HTTP.sys URL reservations
netsh http show urlacl

# List all active HTTP.sys listeners
netsh http show servicestate

Any URL reservation or active listener indicates HTTP.sys is in use on that host.

Step 2: Check the MaxRequestBytes registry value

Microsoft's mitigation hinges on this setting. Check it on every Windows host:

# Check current MaxRequestBytes setting
$key = "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters"
$val = Get-ItemProperty -Path $key -Name "MaxRequestBytes" -ErrorAction SilentlyContinue

if ($null -eq $val) {
    Write-Host "MaxRequestBytes: NOT SET (using default 32768 — SAFE for CVE-2026-47291)"
} elseif ($val.MaxRequestBytes -le 32768) {
    Write-Host "MaxRequestBytes: $($val.MaxRequestBytes) — SAFE"
} else {
    Write-Host "MaxRequestBytes: $($val.MaxRequestBytes) — POTENTIALLY VULNERABLE (exceeds safe threshold)"
}

If MaxRequestBytes is absent (default) or set to ≤ 32768, the specific integer overflow trigger is mitigated — though patching is still required. Values above 32768 are the at-risk configuration.

Step 3: Determine network reachability

From an external vantage point (or a separate internal network zone), verify which hosts have HTTP/HTTPS ports reachable:

# Quick port scan for common HTTP.sys ports
nmap -p 80,443,5985,5986,8080,8443 <target_range> --open -oG httpsys_exposed.txt

Hosts appearing in this output with unpatched Windows builds are your immediate priority.

Step 4: Verify patch status

# Check installed hotfixes — look for KB associated with June 2026 Patch Tuesday
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-06-09"} | Select-Object HotFixID, InstalledOn

# Or check Windows build version
[System.Environment]::OSVersion.Version

Cross-reference the build number against Microsoft's Security Update Guide for CVE-2026-47291 to confirm the patch is installed.

Automated Scanning

Tenable / Nessus:

  • Plugin family: Windows
  • Search for CVE-2026-47291 in the plugin library; scan all Windows servers and workstations
  • Ensure the authenticated scan policy is used — unauthenticated scans may not detect the registry configuration

Qualys:

  • QID lookup: search "CVE-2026-47291" in the Qualys KnowledgeBase
  • Run an authenticated Windows scan against all in-scope hosts
  • Filter results by QID and prioritize hosts with external network exposure

Rapid7 InsightVM / Nexpose:

  • CVE-2026-47291 should appear in the vulnerability library post-June 9
  • Run a credentialed scan; filter by CVE ID; correlate with your asset risk tags for external exposure

PowerShell-based bulk assessment (internal use):

# Bulk check across domain-joined machines via Invoke-Command
$computers = Get-ADComputer -Filter {OperatingSystem -like "*Windows*"} | Select-Object -ExpandProperty Name

$results = Invoke-Command -ComputerName $computers -ScriptBlock {
    $key = "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters"
    $val = Get-ItemProperty -Path $key -Name "MaxRequestBytes" -ErrorAction SilentlyContinue
    $maxBytes = if ($null -eq $val) { "Default (32768)" } else { $val.MaxRequestBytes }
    
    $hotfix = Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-06-09"} | Select-Object -First 1
    
    [PSCustomObject]@{
        Hostname = $env:COMPUTERNAME
        MaxRequestBytes = $maxBytes
        JunePatched = ($null -ne $hotfix)
        PatchKB = $hotfix.HotFixID
    }
} -ErrorAction SilentlyContinue

$results | Export-Csv -Path ".\CVE-2026-47291-Assessment.csv" -NoTypeInformation

Code Review Checklist

For developers building applications on the Windows HTTP Server API:

  • Verify your application does not explicitly set MaxRequestBytes above 32,768 in any configuration or installer script
  • Confirm your app does not call HttpSetRequestQueueProperty or modify HTTP.sys parameters in a way that increases request buffer limits
  • If your app uses a bundled WinRM or management interface, verify it is patched independently of the application itself
  • Check third-party library dependencies for any that register HTTP.sys URL prefixes

4. How to Fix It (Mitigation)

Step-by-Step Remediation

Step 1: Apply the immediate registry mitigation (if patching is delayed)

Run the following PowerShell on each at-risk host:

# Set MaxRequestBytes to safe value (16384 is conservative; 32768 is Microsoft's safe threshold)
$key = "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters"

if (-not (Test-Path $key)) {
    New-Item -Path $key -Force | Out-Null
}

Set-ItemProperty -Path $key -Name "MaxRequestBytes" -Value 16384 -Type DWord
Write-Host "MaxRequestBytes set to 16384. Restarting HTTP service..."

# Restart the HTTP service to apply the change
net stop http /y
net start w3svc  # Start IIS if applicable; adjust for your services

⚠️ Important: Lowering MaxRequestBytes affects all HTTP.sys-backed services on the host. Very large POST bodies or header-heavy requests may be rejected. Test in a non-production environment first and verify application behavior.

Step 2: Deploy the June 2026 Patch Tuesday cumulative update

This is the definitive fix. Deploy via your standard patch management pipeline:

  • Windows Update / Microsoft Update: Automatic for consumer devices; verify Business/Enterprise policies are not blocking
  • WSUS: Approve the June 2026 cumulative update for all Windows OS versions in scope; verify synchronization has completed
  • Microsoft Endpoint Configuration Manager (MECM/SCCM): Deploy the update package; prioritize internet-facing server collections
  • Microsoft Update Catalog: Manual download at https://www.catalog.update.microsoft.com — search "CVE-2026-47291"
  • Intune/MDM: Create a policy to enforce June 2026 Quality Update and target all enrolled Windows devices

Step 3: Prioritize by exposure

  1. Internet-facing Windows servers (IIS, WinRM, RD Gateway, ADCS) — patch immediately
  2. Hosts with MaxRequestBytes above 32,768 — apply registry fix today, patch ASAP
  3. Internally reachable management servers — patch within 24–48 hours
  4. Workstations and devices not running HTTP services — standard critical patch cycle

Step 4: Reboot to confirm patch activation

HTTP.sys is a kernel driver loaded at boot. The cumulative update replaces the http.sys binary, but the old version remains in memory until the system reboots. A pending reboot leaves the host vulnerable.

# Check if a reboot is pending
$pendingReboot = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Write-Host "Reboot pending: $pendingReboot"

Code Fix Example

If your application explicitly sets or elevates MaxRequestBytes, remove or reduce that configuration. Example in a C++ application using the HTTP Server API:

// VULNERABLE: Inflating MaxRequestBytes far above default
HTTP_PROPERTY_FLAGS flags;
flags.Present = 1;
ULONG maxBytes = 1048576;  // 1MB — puts host in vulnerable range

HttpSetRequestQueueProperty(
    hReqQueue,
    HttpServerMaxBandwidthProperty, // ← NOT this; but analogously:
    // Do NOT set MaxRequestBytes above 32768 via any registry or API call
    &maxBytes,
    sizeof(maxBytes),
    0,
    NULL
);

// FIXED: Remove the custom MaxRequestBytes setting entirely,
// OR enforce a safe value at or below 32768 (the OS default)

For IIS-based deployments, check applicationHost.config and web.config for maxRequestEntityAllowed and maxAllowedContentLength — these operate at the IIS layer above HTTP.sys, but confirm no installer has modified HTTP.sys registry parameters directly.

Configuration Hardening

Reverse proxy normalization (interim, not a substitute for patching):

If IIS or another HTTP.sys service is behind NGINX, HAProxy, or a WAF, configure the proxy to:

  • Cap client_max_body_size (NGINX) or request.maxsize (HAProxy) to a sane limit
  • Reject requests with malformed or conflicting Transfer-Encoding / Content-Length headers
  • Normalize all headers before forwarding — prevent raw malformed requests from reaching the Windows backend

Example NGINX configuration:

# In the upstream block serving the Windows IIS backend
proxy_pass http://windows_backend;
proxy_set_header Host $host;

# Normalize and limit request size
client_max_body_size 16m;
client_body_buffer_size 16k;

# Reject suspicious header combinations
proxy_hide_header Transfer-Encoding;

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Verify the June 2026 cumulative update is installed and the system has been rebooted; confirm http.sys file version is ≥ the patched version from MSRC advisory
  • Scenario B: Confirm normal HTTP/HTTPS traffic continues to work correctly after patching (IIS, WinRM, application-specific endpoints)
  • Scenario C: Verify MaxRequestBytes is at a safe value after patching, or that it has been removed (reverted to default)

Security Test Cases

Test Case 1: Verify patch is applied and active

  • Precondition: Apply June 2026 cumulative update and reboot
  • Steps: Check Get-HotFix output; verify http.sys file version matches patched binary
  • Expected Result: Build number reflects post-June-9-2026 cumulative update; no reboot pending

Test Case 2: Confirm MaxRequestBytes mitigation is in effect

  • Precondition: Registry mitigation applied (or patched)
  • Steps: Run the MaxRequestBytes PowerShell check from Section 3
  • Expected Result: Value is absent (default 32768) or explicitly ≤ 32768

Test Case 3: Verify oversized requests are rejected at the network edge

  • Precondition: Reverse proxy or WAF in place with header size limits
  • Steps: Send a test HTTP request with very large (>32KB) combined header size using curl:
# Generate a request with a large custom header to test server-side rejection
python3 -c "
import socket
host = 'target-server'
port = 80
# Build a request with a very large header value
large_header = 'X-Test: ' + 'A' * 40000
req = f'GET / HTTP/1.1\r\nHost: {host}\r\n{large_header}\r\n\r\n'
s = socket.socket()
s.connect((host, port))
s.send(req.encode())
resp = s.recv(4096)
print(resp.decode(errors='replace')[:500])
s.close()
"
  • Expected Result: Server returns HTTP 400 (Bad Request) or connection is reset; no crash; no HTTPERR log entries indicating a kernel fault

Automated Tests

Integrate this PowerShell check into your post-patch validation pipeline:

function Test-CVE202647291Remediation {
    param([string[]]$Computers = @($env:COMPUTERNAME))
    
    $results = foreach ($computer in $Computers) {
        $result = Invoke-Command -ComputerName $computer -ScriptBlock {
            # Check 1: Is the patch installed?
            $patch = Get-HotFix | Where-Object { $_.InstalledOn -ge "2026-06-09" }
            
            # Check 2: Is MaxRequestBytes safe?
            $key = "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters"
            $regVal = Get-ItemProperty -Path $key -Name "MaxRequestBytes" -ErrorAction SilentlyContinue
            $maxBytes = if ($null -eq $regVal) { 32768 } else { $regVal.MaxRequestBytes }
            
            # Check 3: Is a reboot pending?
            $rebootPending = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
            
            [PSCustomObject]@{
                Host            = $env:COMPUTERNAME
                PatchInstalled  = ($null -ne $patch)
                MaxRequestBytes = $maxBytes
                SafeConfig      = ($maxBytes -le 32768)
                RebootPending   = $rebootPending
                Remediated      = ($null -ne $patch) -and ($maxBytes -le 32768) -and (-not $rebootPending)
            }
        } -ErrorAction SilentlyContinue
        $result
    }
    
    $results | Format-Table -AutoSize
    $vulnerable = $results | Where-Object { -not $_.Remediated }
    if ($vulnerable) {
        Write-Warning "$($vulnerable.Count) host(s) are NOT fully remediated:"
        $vulnerable | Select-Object Host, PatchInstalled, MaxRequestBytes, RebootPending
    } else {
        Write-Host "All checked hosts are remediated." -ForegroundColor Green
    }
}

# Usage:
Test-CVE202647291Remediation -Computers @("webserver01","iishost02","winrm-mgmt01")

6. Prevention & Hardening

Best Practices

  • Maintain MaxRequestBytes at or below the default (32,768 bytes) across all Windows servers as a permanent policy baseline. Audit for any application installer or Group Policy Object that raises this value.

  • Enforce Patch Tuesday compliance with SLA enforcement by exposure tier. Internet-facing Windows HTTP servers should be patched within 24–48 hours of a Critical "Exploitation More Likely" advisory. Internal servers should follow within 72 hours. This flaw is a textbook case for why generic 30-day patch windows are incompatible with modern threat timing.

  • Inventory all HTTP.sys listeners as part of your attack surface management program. The riskiest servers are often not the ones in your IIS console — they are forgotten management portals, backup agents, monitoring services, and vendor appliances. Run netsh http show urlacl across your fleet quarterly and reconcile against your asset inventory.

  • Place all non-public HTTP.sys services behind network access controls. WinRM (5985/5986), management dashboards, and internal APIs should never be reachable from the internet or from untrusted network segments without VPN or conditional access.

  • Regularly review third-party Windows appliances for HTTP.sys dependency. Vendors rarely call out their use of Windows HTTP Server API, but embedded Windows appliances can expose HTTP.sys through their management interface without it being obvious from the product name.

Monitoring & Detection

The challenge with HTTP.sys vulnerabilities is that exploitation may occur before IIS application logs are populated — the kernel driver processes requests before user-mode code runs. Use a layered detection approach:

Windows Event Logs to monitor:

# Monitor for HTTP.sys-related errors in the System log
Get-WinEvent -LogName System -FilterHashtable @{
    ProviderName = "HTTP"
    Level = 1,2  # Critical and Error
} | Select-Object TimeCreated, Id, Message | Format-List

HTTPERR logs (typically at C:\Windows\System32\LogFiles\HTTPERR\):

# Parse HTTPERR logs for unusual status codes or error types
Get-Content "C:\Windows\System32\LogFiles\HTTPERR\*.log" | 
    Where-Object { $_ -match "Timer_MinBytesPerSecond|Connection_Abandoned_By_ReqQueue|Bad_Request" } |
    Select-Object -Last 100

Telemetry indicators of post-exploitation:

  • Unexpected child processes spawned by w3wp.exe, svchost.exe (HTTP service), or other HTTP-bound processes
  • New scheduled tasks, service installations, or registry run-key modifications following inbound HTTP activity
  • LSASS access attempts (Sysmon Event ID 10) from web server process identities
  • WMI or PowerShell activity from HTTP service accounts
  • Network connections to unusual destinations originating from svchost.exe hosting the HTTP service

Detection rule (Sigma-style, for SIEM ingestion):

title: Suspicious Child Process from HTTP.sys Service
status: experimental
description: Detects potential post-exploitation of HTTP.sys — unexpected process creation from HTTP service workers
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\svchost.exe'
    ParentCommandLine|contains:
      - 'HTTPService'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\certutil.exe'
  condition: selection
falsepositives:
  - Legitimate server management scripts triggered via HTTP APIs
level: high
tags:
  - attack.execution
  - cve.2026.47291

References

Latest from the blog

See all →