CVE-2026-119618: The Critical Apache HTTP/2 RCE in mod_http2, Fixed in 2.4.71

Nov 12, 2026

CVE-2026-119618 is a critical, unauthenticated remote code execution flaw in Apache HTTP Server's mod_http2, affecting httpd 2.4.55 through 2.4.70 and fixed in 2.4.71. Who is actually affected, the root cause, the exposure numbers, and what to patch — with the version facts other write-ups got wrong.

On 11 November 2026 the Apache HTTP Server project released httpd 2.4.71 and disclosed three flaws fixed in it. The headline one is CVE-2026-119618, a thread-safety bug in mod_http2 that a remote, unauthenticated attacker can turn into heap corruption, and from there into remote code execution. Apache rates it critical; Red Hat scores it CVSS 9.8. It affects Apache HTTP Server 2.4.55 through 2.4.70, and only when the server is serving HTTP/2.

There are already good explainers on this one — Wiz published the exposure numbers everyone is quoting. This post is the version we wanted for ourselves: the facts checked against the primary sources, the root cause from the published diff, and the two version claims that other write-ups got wrong. We added the CVE to our public Threat Watch feed on the day it dropped, and this is the long form of that record.

Everything below was verified on 12 November 2026 against the primary sources: the Apache advisory, the fix commit, the Red Hat CVE page, the Debian tracker, and the public reproduction lab.

CVE-2026-119618 in one table

Two more flaws ship their fix in the same 2.4.71 release, and they are worth a line because they load by default on many builds:

• CVE-2026-106023 (important): a NULL pointer dereference in mod_md crashes the child process. Affects 2.4.30 – 2.4.70.
• CVE-2026-109163 (low): a one-byte stack overwrite in mod_vhost_alias, affecting 2.4.69 and 2.4.70 — a follow-up to CVE-2026-63292.

The whole bug is one write to the wrong table

mod_http2 runs each HTTP/2 stream on a worker thread with its own private memory pool, so a worker never touches the connection thread's allocator. The connection's allocator is lock-free: it was created without a mutex, so there is nothing to serialise two threads reaching into it. The private-pool design is what keeps that safe.

assign_headers() breaks the rule for one request shape. When a request has no body, carries a Content-Type, and has no Content-Length, the function synthesises a Content-Length: 0 header. In 2.4.55 through 2.4.70 it writes that header into req->headers, the stream's shared table, instead of r->headers_in, the request-private clone the worker owns.

That write is where the threads collide. If the stream's header table is already full, the write allocates a new 8 KB node from the connection's lock-free allocator — at the same moment the connection thread is allocating from or freeing to the same free list. Two threads pop the same node, it ends up owned twice, and the child process heap is corrupted.

The fix changes the write target and nothing else:

-                apr_table_setn(req->headers, "Content-Length", "0");
+                apr_table_setn(r->headers_in, "Content-Length", "0");

r->headers_in lives in the worker's own request pool, so the synthesised header never crosses a thread boundary. That one line is the entire 2.4.71 fix for CVE-2026-119618.

The public reproduction lab that appeared on 12 November drives exactly this trigger in a container, shows the corruption on 2.4.70 under AddressSanitizer and ThreadSanitizer, and shows 2.4.71 clean under the same traffic. It demonstrates the crash and the race, not a weaponised code-execution exploit. Red Hat's write-up goes further and states that "public research has demonstrated a reliable exploit against a default-configured server"; the only public code we could find proves memory corruption, so treat the step from corruption to code execution as credible but not something you can download today.

Is your server actually affected?

The version range is necessary, not sufficient. CVE-2026-119618 is only reachable when the server negotiates HTTP/2, and plenty of Apache installs never do. Check three things, in order:

# 1. Is the HTTP/2 module even loaded?
apachectl -M | grep http2
 
# 2. Is HTTP/2 actually turned on anywhere in the config?
#    (check inside every VirtualHost, not just the global scope)
grep -rniE 'Protocols.*h2c?' /etc/apache2 /etc/httpd
 
# 3. Does an internet-facing host negotiate it on the wire?
curl -sI --http2 https://your-host/ | head -1   # "HTTP/2 200" = h2 negotiated

If mod_http2 is not loaded, or no Protocols line names h2/h2c, the server serves HTTP/1.1 and this bug has no path to it. That is the real exposure question, and it is the one a plain "2.4.70 is affected" scanner result does not answer.

The exposure numbers, and two facts to ignore

Wiz scanned cloud estates and reported that 64% of cloud environments have at least one resource running an affected Apache version, and 51% have one exposed to the internet. Those figures are version-based — they count the 2.4.55–2.4.70 range, not whether HTTP/2 is turned on — so read them as the outer bound of the blast radius. They are still a fair argument for patching quickly: a critical, unauthenticated RCE in the most widely deployed web server is the kind of thing that gets a working exploit written against it, and the trigger is already public.

Two version claims are circulating that are wrong, and acting on either wastes time:

• There is no fixed standalone mod_h2 release. Some write-ups (and the reproduction lab's own README) list "mod_h2 2.0.43" as the fix, and Wiz's table lists "2.0.24". The icing/mod_h2 repository was archived in June 2026 with v2.0.42 as its final tag, and 2.0.24 sits inside the affected range. If you build mod_h2 from source, there is no newer module to move to — the fix lives in httpd 2.4.71's bundled mod_http2.
• "Disable mod_http2" is not the only lever. You do not need to unload the module; removing h2 and h2c from your Protocols directives and reloading is enough to close the path, and it is the workaround the lab author verified.

Distro status: don't assume your package manager has it yet

The fix landed upstream on 11 November. Downstream packages lag, so confirm the build you are about to deploy actually carries it.

The Red Hat nuance is useful even if you do not run RHEL: an allocator-per-stream build is materially harder to exploit than the shared-allocator default, which is why the same bug is critical upstream and "important" on RHEL 9/10.

What to do

• Patch to httpd 2.4.71. It fixes CVE-2026-119618 along with the mod_md and mod_vhost_alias flaws. Before you trust a distro package, confirm it is 2.4.71-based — on 12 November, Debian stable was not.
• If you cannot patch now and do not need HTTP/2, remove h2 and h2c from every Protocols directive, including the ones inside VirtualHost blocks, and reload. Servers left on the http/1.1 default are not affected.
• Find your HTTP/2-enabled, internet-facing hosts first with the three checks above, and patch those before anything behind authentication or a WAF.
• Standalone mod_h2 users: move to 2.4.71's bundled module. There is no standalone fix release.
• Watch for a CVE score and distro errata. NVD had no score at the time of writing; Red Hat's 9.8 is the number to plan around.

We track vulnerabilities like this one on Helix Threat Watch, a public feed with the preconditions stated plainly, so "affected" never oversells what it means for your estate. The CVE-2026-119618 record carries the sources, the timeline, and the remediation steps above.

Helix Cyber runs agent-driven penetration tests that reason about which of your hosts actually negotiate HTTP/2, instead of flagging a version string and calling it a finding. Every candidate finding is reproduced by a second agent before it reaches a report, and retests after a patch like 2.4.71 are a click rather than a new engagement.