CVE-2026-119618: pre-auth RCE in Apache mod_http2 fixed in 2.4.71

What happened

A vulnerability tracked as CVE-2026-119618 gives unauthenticated attackers remote code execution against Apache HTTP Server deployments running with HTTP/2 enabled. The flaw is rated CVSS 9.8 and was fixed on 11 November 2026 in Apache HTTP Server 2.4.71. According to a technical write-up published on dev.to, exploitation requires nothing beyond a single crafted HTTP/2 request: no credentials and no interaction from a victim.

How the race condition works

The dev.to analysis lays out the mechanism. mod_http2 is designed so that worker threads never handle the connection's shared memory allocator — each worker is meant to use a private one. A function called assign_headers() breaks that rule for one particular request shape: a body-less request that carries a Content-Type header but no Content-Length, arriving when the request's header table is already full.

In that case the worker thread synthesises a Content-Length: 0 entry and writes it into a stream table shared with the connection thread. That write races against the connection thread on a lock-free free list, and both threads can end up retrieving the same node. The heap corrupts, leaving memory effectively claimed by two threads at once — and the analysis describes that state as the primitive an exploit converts into code execution.

Who is affected

Per the write-up, affected software covers Apache HTTP Server 2.4.55 through 2.4.70 and the standalone mod_h2 module, versions 2.0.8 through 2.0.42. Exposure depends entirely on configuration: only servers with HTTP/2 enabled are vulnerable, meaning the h2 or h2c token present in a Protocols directive. Because that directive can be set server-wide or inside individual virtual hosts, the analysis stresses that both levels need checking — a server can look clean at the global level while a single virtual host keeps it exposed.

How widespread it is

Citing figures from Wiz, the write-up reports that 64% of cloud environments contain resources running a vulnerable version and that 51% have publicly exposed instances. Public exploitation material already exists: a container lab for reproducing the bug, ThreadSanitizer traces demonstrating the race, and a proof of concept built with the standard library are available on GitHub under the CVE identifier. The analysis also compares how Red Hat and upstream rate the issue, deferring the detail to a longer article.

Patching and workarounds

The remedy is an upgrade: Apache HTTP Server 2.4.71, or mod_h2 2.0.43 for the standalone module. The write-up lists the corresponding Red Hat packages as mod_http2-2.0.26-7.el9_9.1 for RHEL 9 and mod_http2-2.0.29-5.el10_3.1 for RHEL 10. Container images built before 11 November bake in the vulnerable module and need a rebuild.

For servers that cannot be patched immediately, the suggested mitigation is to disable HTTP/2 by setting Protocols http/1.1 in every configuration file and every virtual host block. The mitigation is all-or-nothing: a single virtual host left with h2 or h2c enabled keeps the server at risk.

Why it matters

This sits in the highest tier of web-server vulnerabilities: unauthenticated code execution reachable by anyone who can connect to the port, on software that fronts a large share of the internet's sites. Two things sharpen it further. First, HTTP/2 support is commonly enabled wherever TLS is terminated, so the vulnerable configuration is closer to the norm than the exception. Second, the affected window is wide — sixteen 2.4.x releases plus a long run of standalone mod_h2 versions — and Wiz's numbers suggest most cloud estates hold at least one vulnerable resource, half of them internet-facing.

The counterweight is that the fix is a routine version bump and the fallback is a one-line configuration change. The real exposure window is the gap between now and whenever operators apply one of them, which makes patching — and rebuilding any container image older than 11 November — the immediate priority for anyone running HTTP/2 on Apache.