Critical mod_http2 race condition exposes Apache HTTP Server to unauthenticated RCE

What happened

Wiz has published details of a critical vulnerability in Apache HTTP Server's HTTP/2 module, tracked as CVE-2026-119618. According to the advisory, the bug is a concurrency flaw that a remote attacker can abuse without any credentials to corrupt server memory and achieve arbitrary code execution. Wiz credits the discovery to two independent finders: Anthropic and Google Cloud's vulnerability research team. As of publication, the company states that no exploit has been made public and there are no known cases of the flaw being exploited in the wild.

How the flaw works

The problem lies in mod_http2, specifically in a function called assign_headers() that handles shared resources across concurrently executing threads. Because access to those shared resources is not properly synchronized, an attacker can trigger a race condition that corrupts the heap. That memory corruption can then be leveraged to run arbitrary commands as the web server user. Critically, the attack requires no authentication — only the ability to reach a server that has HTTP/2 handling enabled.

Affected versions

Two code paths are affected. For Apache HTTP Server itself, versions 2.4.55 through 2.4.70 are vulnerable, and the fix ships in 2.4.71. For teams running the standalone mod_h2 module from GitHub, the advisory is internally inconsistent: its version table lists 2.0.8 through 2.0.42 as affected and 2.0.24 and newer as patched, while its remediation text instructs users to upgrade beyond 2.0.42. The two figures conflict, so standalone-module users should treat anything at or below 2.0.42 as vulnerable unless the project's own release notes state otherwise.

Exposure in cloud environments

Wiz Research examined its customer data and reports that 64% of the cloud environments it looked at contain resources vulnerable to this CVE, while 51% have affected instances that are publicly exposed. The company caveats that these figures do not account for configuration. In cloud settings, Wiz warns that a compromised Apache instance hosting containerized or virtualized workloads can become a foothold for lateral movement, giving attackers a path toward neighboring microservices and cloud metadata endpoints.

What administrators should do

The primary fix is an upgrade: move Apache HTTP Server installations to 2.4.71 or later, which resolves the race condition in assign_headers(). Organizations running standalone mod_h2 builds should likewise move to a patched module release. Where immediate patching is not possible — for instance when change windows or legacy dependencies block a server upgrade — Wiz recommends disabling HTTP/2 as a temporary measure. In practice this means editing the configuration file, typically httpd.conf, so that the enabled protocol list contains only HTTP/1.1 and no longer references h2 or h2c. Dropping HTTP/2 support closes the attack vector until a proper patch can be deployed.

Why it matters

Unauthenticated remote code execution in a mainstream web server is about as serious as vulnerabilities get: anyone who can reach the server over the network can potentially take it over without a valid account. Apache HTTP Server remains one of the most widely deployed servers on the internet, and HTTP/2 is commonly enabled for performance, so the pool of reachable targets is large. In cloud and containerized deployments the blast radius extends beyond a single host, since a hijacked web server process can be used to probe adjacent services and metadata endpoints that often hold credentials. There is no evidence of active exploitation yet, but public disclosure tends to shorten that window considerably. Administrators who cannot patch today should at minimum disable HTTP/2 and schedule the move to 2.4.71 as soon as possible.