Apache patches critical mod_http2 race condition allowing unauthenticated RCE

Apache released HTTP Server 2.4.71 on November 11, patching a race condition in mod_http2 that Red Hat says an unauthenticated attacker could use to run commands on the server. SecurityWeek reported the fix on November 12.

The flaw is tracked as CVE-2026-119618 and affects versions 2.4.55 through 2.4.70. It sits in mod_http2, the module that handles HTTP/2 traffic, and the Apache description points at assign_headers(). The same description lists affected releases of mod_h2 from GitHub as 2.0.8 through 2.0.42, which matters if you build the module separately from the server package.

What happened

Two sets of researchers found it independently. Apache credited Anthropic's OSS Scanner with reporting the bug on October 26. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported the same issue on November 3.

Red Hat assigned a CVSS score of 9.8 and stated that only servers with HTTP/2 enabled are affected, while servers configured to serve only HTTP/1.1 are not vulnerable. That configuration detail does more work than the score. A 9.8 on a box that never negotiated HTTP/2 is a number without a matching exposure.

The same 2.4.71 release also fixes two other issues: CVE-2026-106023, described as important and able to crash server processes, and CVE-2026-109163, a low-severity stack buffer overflow in mod_vhost_alias.

Technical mechanism and impact

A race condition means several threads reach the same shared state without proper synchronisation. In mod_http2's header assignment path, that can corrupt server memory. Corrupted memory in a process that handles untrusted requests is the usual road to code execution, and Red Hat's advisory says an attacker could exploit it remotely without authentication to execute arbitrary commands and take control of the server process.

How reliable that is in practice is a separate question from whether it's possible. Red Hat says public research has demonstrated a reliable exploit against a server with mod_http2 enabled, but its advisory doesn't name the research. Wiz, writing when its blog went up on November 11, said no exploit was available and there were no reports of exploitation in the wild. A public proof of concept on GitHub reportedly reproduces memory corruption and Apache process crashes but doesn't demonstrate remote code execution. Those two statements aren't in conflict: a crash PoC and a working RCE chain are different artifacts, and the gap between them is where most of the work lives.

Wiz also put out exposure figures: 64% of cloud environments in its data contained resources running affected Apache versions, and 51% had publicly exposed instances. Wiz itself cautioned that the numbers don't account for server configuration, so they don't represent exploitable installations. Treat them as a measure of how common the software is, not how many boxes are open to this bug.

One point worth repeating because it gets missed: Defiant warned that WordPress security updates can't fix this, since the flaw is in the web server underneath.

HackZoneLabs assessment

In our view the patch is the easy call and the inventory is the hard one. The affected range is wide, the module ships with the server in most distributions, and the fix landed in a point release that many teams apply on a slow cycle. We'd want to know which of our hosts actually negotiate HTTP/2 before deciding how urgent this is, because that single setting separates a 9.8 from a non-issue. The absence of in-the-wild exploitation as of November 11 is a reason to move deliberately, not a reason to wait: the bug is public, the PoC is public, and the researchers who found it described it as reliably exploitable.

What remains unknown

Nobody has published a write-up of the exploit chain that we can point to, and Red Hat's advisory doesn't identify the research it cites. The source gives no timeline for when a public RCE exploit might appear, and no indication that anyone has tried this against real servers. Whether your distribution has shipped 2.4.71 in its own packages isn't stated either; check your vendor rather than assuming.

Defensive priorities

Install Apache HTTP Server 2.4.71 or the vendor-supplied package. If you can't patch immediately, disabling HTTP/2 temporarily prevents exploitation, per the source. Then confirm the change took: a config that still advertises h2 on a listener you thought you'd closed is the kind of thing that survives a change freeze. If you build mod_h2 from GitHub separately, check that version too.

CVE references

CVE-2026-119618

CVE-2026-106023

CVE-2026-109163