Apache HTTP Server 2.4.71 patches critical remote code execution in mod_http2

October 26, 2026. Anthropic reports a critical flaw to the Apache project. November 3, 2026. Google Cloud Vulnerability Research reports the same flaw, independently. November 11, 2026. Apache publishes HTTP Server 2.4.71, fixing three flaws including an unauthenticated remote code execution. Why it matters: mod_http2 is loaded by default on most servers that speak HTTP/2, and the flaw needs nothing more than a request a remote client can reach.

The flaw: a thread race in assign_headers()

The vulnerability is tracked as CVE-2026-119618, rated critical by Apache’s security team. Its NVD label is precise: a concurrent execution using shared resource with improper synchronization — in plain terms a race condition — in the assign_headers() function of mod_http2. The result is heap corruption that can be steered into remote code execution.

The mechanism lives in how mod_http2 assembles an HTTP/2 request’s headers before handing the request to the server core. assign_headers() touches a structure shared between threads without synchronizing access correctly. Two concurrent requests, or a carefully ordered sequence of frames, can make that structure’s state diverge: the server writes into a memory region it believes valid, and an attacker who controls the frame flow can turn that write into code execution.

The reach is wide because the vector is mundane. There is no authentication precondition, no exotic optional module, no non-standard configuration: the only requirement is that HTTP/2 be enabled — and it is enabled by default whenever mod_http2 is loaded. Affected versions run from 2.4.55 through 2.4.70 for the server, and from 2.0.8 through 2.0.42 for mod_h2, the GitHub repository that carries the module standalone.

A reassuring note for those who have moved their front-end to HTTP/3: that protocol is not affected. It relies on a separate module, mod_http3, and a separate software stack. The flaw lives in the code that speaks HTTP/2 — which is the overwhelming majority of current deployments, HTTP/3 remaining a minority at the edge. The right question to triage your fleet is therefore not “am I up to date?” but “which protocol does my front-end actually serve?”.

Two teams, one discovery

What makes this batch notable is not only its severity but who found it. Two independent parties are credited as finders in the official announcement:

• Anthropic, through its OSS Scanner, under the internal reference ANT-2026-MAPKT6MZ — reported on October 26, 2026;
• Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research — reported on November 3, 2026.

In other words, an automated open-source code scanner run by an AI lab and a human vulnerability research team arrived, eight days apart, at the same thread race in assign_headers(). It is a concrete signal of what automated code analysis — the kind Anthropic runs across open-source repositories — is starting to produce on targets as central as the most deployed web server in the world.

The coordination was clean. The fix, commit 824beab in the 2.4.x branch, shipped on November 11, 2026, the same day 2.4.71 was published. No real-world exploitation is documented at the time of the announcement, but the gap between report and fix — roughly three weeks for the first report — is the standard window for a flaw of this depth in a project of this size.

Two more flaws in the same release

2.4.71 does not carry a single fix. The batch holds three, in descending severity, and the other two are worth knowing because they hit very common modules.

CVE-2026-106023 — important. A null pointer dereference in mod_md, the module that handles ACME domain validation (the Let’s Encrypt flow). A crafted request can crash the child process — a denial of service that is genuinely annoying on a server renewing its certificates. Versions 2.4.30 through 2.4.70 are affected.

CVE-2026-109163 — low. A one-byte stack buffer overwrite in mod_vhost_alias, completing an earlier fix (CVE-2026-63292, already covered in our analysis of Apache 2.4.69). Only 2.4.69 and 2.4.70 are affected. The severity is low, but it is a reminder that “one byte” fixes tend to leave variants behind.

Who is exposed: the real surface of mod_http2

The operational question is not “am I on Apache?” but “is HTTP/2 enabled here?”. The answer is almost always yes. Since 2.4.17, mod_http2 ships with the server, and distributions enable it by default — Debian, Ubuntu, RHEL and their derivatives — because HTTP/2 measurably improves page latency. Red Hat, which ships the server in RHEL, published its own advisory and reiterates that only servers loading mod_http2 are affected.

There is also a category that gets forgotten too often: reverse proxies and home-grown load balancers that expose Apache in front, and shared hosting providers serving thousands of sites behind a single binary. On those machines, one vulnerable instance is a door into everything behind it.

For defenders, the uncomfortable part is the long tail. Apache ships inside enterprise distributions with multi-year support windows, so a large share of the installed base runs 2.4.x releases that are years old — squarely inside the 2.4.55–2.4.70 range. An upstream patch does not reach those boxes until the vendor backports it, which is exactly why the disable-HTTP/2 workaround matters as much as the upgrade itself.

Check and fix in a few minutes

The check takes two commands. The first prints the binary version, the second tells you whether mod_http2 is loaded.

httpd -v
apachectl -M | grep -i http2

If the version predates 2.4.71 and http2_module appears, you are exposed. The real fix is upgrading to 2.4.71 — through your distribution’s package manager, or by recompiling if you maintain mod_h2 from its GitHub repository, where the patched releases are those before 2.0.8 and after 2.0.42.

At fleet scale the enumeration is just as simple: cross your version inventory — CMDB, infrastructure scanner — against the vulnerable range 2.4.55–2.4.70, and alert on any server that matches. A useful habit for teams running dozens of front-ends is to inspect the Server header each exposed node returns, which often leaks the exact binary version.

For those who cannot patch immediately, the workaround is clean: disable HTTP/2. On Debian or Ubuntu, a2dismod http2 followed by systemctl reload apache2 is enough. Elsewhere, comment out the LoadModule http2_module directive and reload. The cost is performance — connections fall back to HTTP/1.1 — but that is a price far below a remote code execution.

Verdict

If you serve HTTP/2 from an Apache older than 2.4.71 — front-end, reverse proxy, or shared hosting — upgrade to 2.4.71 before your next maintenance window, or disable mod_http2 within the hour if the upgrade is blocked. CVE-2026-119618 is an unauthenticated remote code execution on the world’s most deployed web server, and the absence of public exploitation observed so far changes nothing: the patching window is open, so take it. If HTTP/2 is disabled in your fleet — a deliberate HTTP/1.1-only posture — the risk drops to the other two flaws in the batch, neither of which is remotely exploitable without specific conditions: still schedule the update on your normal cadence.

References

• Apache — HTTP Server 2.4.71 security announcements (accessed November 12, 2026)
• oss-security — “CVE-2026-119618: Apache HTTP Server: mod_http2: heap corruption and RCE in assign_headers” (Eric Covener, November 11, 2026)
• NVD — CVE-2026-119618 (published November 11, 2026)
• ETTAYEB — our analysis of Apache 2.4.69 and its twenty fixes