The Layer Nobody Thinks About
When organizations evaluate web server security, they think about the application framework (ASP.NET, Spring, Django), the web server software (IIS, Apache, Nginx), and the operating system (Windows Server, Linux). They rarely think about HTTP.sys — the kernel-mode HTTP driver that sits beneath IIS and processes every HTTP request before it reaches the application layer. HTTP.sys is invisible. It has no configuration UI. Most administrators don't know it exists. And on June 9, 2026, it received a CVSS 9.8 vulnerability that enables unauthenticated remote code execution with kernel privileges.
CVE-2026-47291 is an integer overflow in HTTP.sys's request-parsing logic. When the driver processes an HTTP request, it performs 16-bit integer arithmetic on the total request size. A request whose header block reaches or exceeds 65,535 bytes triggers an integer overflow — the computed allocation size wraps around to a small value, resulting in a heap buffer significantly smaller than the data written into it. The overflow enables arbitrary code execution in kernel memory. Not user-space. Kernel-space. The attacker gains the highest privilege level the operating system offers.
What HTTP.sys Underlies
HTTP.sys is not optional on Windows Server. It is the kernel-mode HTTP listener that underlies: IIS (Internet Information Services) — the default Windows web server; WCF (Windows Communication Foundation) — enterprise service communication; WinRM (Windows Remote Management) — the protocol that powers PowerShell remoting; ASP.NET and ASP.NET Core on IIS — every .NET web application hosted on Windows; and any Windows service that registers an HTTP listener. If your organization runs any web service on Windows Server, HTTP.sys is processing requests. The vulnerability is not in the application. It is not in the web server. It is in the kernel driver beneath both.
The Mitigation Nuance
Microsoft's advisory includes a critical detail: systems using the default MaxRequestBytes registry value are not affected. The integer overflow only triggers when MaxRequestBytes has been explicitly increased above 65,535. This means the vulnerability primarily affects servers where administrators changed the default configuration to accept larger requests — a common modification for applications that handle large file uploads, complex SOAP payloads, or extended header chains.
This creates a paradox of visibility. The servers most likely to be vulnerable are the ones running the most complex, enterprise-critical applications — the ones where administrators needed larger request sizes because the applications demanded it. The default-configuration hobby server is safe. The custom-configured enterprise server running a decade-old WCF service is the target.
The Framework Lens
HTTP.sys vulnerabilities are invisible to application-layer security scanning. A web application firewall (WAF) inspects HTTP requests after they reach the application layer — but CVE-2026-47291 triggers in the kernel driver before the request reaches the WAF. Static analysis of the application code will not find it. Dynamic application security testing (DAST) will not find it. Only network-level or host-level security tools that inspect raw HTTP traffic before it reaches the HTTP.sys driver can detect exploitation attempts.
This is why the framework choice matters at a level deeper than most security conversations reach. Frameworks running on Linux (Django, FastAPI, Rails, Express, Laravel) do not use HTTP.sys. They are structurally immune to this class of vulnerability — not because they are more secure, but because they run on an operating system that processes HTTP requests in user-space, not kernel-space. The architectural decision to deploy on Linux vs. Windows is, in this case, the security decision.
