The Apache Software Foundation released Apache HTTP Server 2.4.71 on 11th November, 2026 to fix CVE-2026-119618, a critical race condition in mod_http2. The flaw can let an unauthenticated attacker run code on an affected server with HTTP/2 switched on.
Key Facts
- Apache HTTP Server 2.4.55 through 2.4.70 is affected, along with standalone mod_h2 builds 2.0.8 through 2.0.42.
- Anthropic’s OSS Scanner reported the flaw first, and two Google Cloud researchers found the same bug eight days later.
- Red Hat says only servers with HTTP/2 enabled are exposed, so HTTP/1.1-only setups aren’t vulnerable to this bug.
- Version 2.4.71 also fixes a mod_md crash rated important and a low-severity stack overflow in mod_vhost_alias.
Concurrent HTTP/2 requests corrupt the heap
Apache’s security advisory traces the bug to assign_headers() in mod_http2, the module that handles HTTP/2 traffic. When requests arrive concurrently, one thread can modify memory that belongs to another, and the heap gets corrupted.
Red Hat scores it 9.8 out of 10. An attacker who can reach the server needs no credentials to run arbitrary commands and take control of the httpd process, the company said. It added that “servers configured to serve only HTTP/1.1 are not vulnerable.“
Anthropic’s scanner filed its report on 26th October, 2026, logged as ANT-2026-MAPKT6MZ. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research followed independently. Anthropic opened OSS Scanner earlier in October as a free, opt-in service that runs its Claude models, Mythos among them, against open-source code.
Two separate teams landing on one race condition within about a week suggests the bug wasn’t especially hidden. That’s the uncomfortable part for anyone still running 2.4.70.
We’re aware of CVE-2026-119618, a race condition in Apache mod_http2 that can lead to heap corruption and potentially RCE. We’re actively investigating. It appears to be configuration-specific, with only hosts with h2 enabled in Protocols being exposed. Patch now or drop h2 until you can.
— watchTowr (@watchtowrcyber) November 11, 2026
Red Hat and Wiz disagree on exploit status
Red Hat says public research has shown a reliable exploit against a default-configured server with mod_http2 enabled. It doesn’t name or link that research, though. Wiz said the same day that no exploit was available and nobody had reported exploitation in the wild. A proof of concept on GitHub reproduces memory corruption and Apache process crashes, but it doesn’t demonstrate code execution.
Exposure looks wide on paper. Wiz found affected Apache versions in 64% of the cloud environments in its data, and publicly exposed instances in 51%. The company cautioned that those figures ignore configuration, so they count servers that may never have enabled HTTP/2.
Patch history adds a trap. An earlier HTTP/2 flaw, CVE-2026-23918, was fixed in 2.4.67. Admins who patched for that one and stopped anywhere up to 2.4.70 are still exposed. It’s one more entry in our KEV Tracker.
Distro packages trail the upstream fix
Red Hat shipped fixes for RHEL 9 and 10, where it rates the flaw Important rather than Critical. Its mod_http2 packages give each HTTP/2 stream a separate memory allocator, which makes an attack much harder. RHEL 8 and earlier don’t contain the vulnerable code.
Debian has fixed unstable (sid) with apache2 2.4.71-1, while bookworm, trixie and forky remain vulnerable. Amazon Linux lists the fix as pending, and according to The Hacker News, Ubuntu’s CVE tracker had no page for the flaw.
Standalone mod_h2 users have no fixed release to install. The project’s GitHub release list ends at 2.0.42, the last affected version, and the repository has been read-only since it was archived in June.
What’s Next?
Admins on major Linux distributions should install 2.4.71 or their vendor’s patched package as it ships. WordPress security updates won’t help here, Defiant warned, because the bug sits in the underlying web server.
Wiz advises servers that can’t update yet to drop h2 and h2c from the Protocols directive and keep Protocols http/1.1. That helps reduce risk only if it covers the server-wide setting and every virtual host. Apache’s advisory offers no workaround of its own.
