Apache HTTP Server 2.4.71 Fixes Critical mod_http2 RCE

Apache has patched a critical remote code execution flaw in mod_http2, the module that handles HTTP/2 traffic for Apache HTTP Server. The bug is tracked as CVE-2026-119618 and affects versions 2.4.55 through 2.4.70. The fix landed on November 11 in version 2.4.71, SecurityWeek reports.

What to do: upgrade to 2.4.71, or to your distribution’s patched package. If you cannot update yet, removing h2 and h2c from the Protocols directive and leaving http/1.1 takes the vulnerable code out of play, per Wiz’s advice as relayed by The Hacker News. Check the server-wide setting and every virtual host, because the directive can be set per host.

What is affected

The flaw is a race condition, where multiple threads access a shared resource improperly and can corrupt server memory. Red Hat says an unauthenticated remote attacker could run arbitrary commands and take control of the server process. Only servers with HTTP/2 enabled are exposed; servers that speak only HTTP/1.1 are not.

Standalone builds of the module, published as mod_h2, are affected from 2.0.8 through 2.0.42, according to The Hacker News. That project’s repository has been archived and read-only since June 9, and no fixed release has been published, so the Protocols change is the practical option there.

2.4.71 also fixes CVE-2026-106023, an important-rated issue that can crash server processes, and CVE-2026-109163, a low-severity stack buffer overflow.

Distribution status

Vendors ship their own package versions, so check your platform rather than comparing against 2.4.71. As of The Hacker News’s reporting on November 12:

• Red Hat Enterprise Linux 9 and 10 have fixes, and Red Hat rates the flaw Important there rather than Critical, because its mod_http2 packages give each HTTP/2 stream its own memory allocator, which makes an attack much harder. RHEL 8 and earlier do not contain the vulnerable code.
• Debian unstable has a fix. Debian bookworm, trixie and forky were listed as vulnerable with no fix yet.
• Amazon Linux fixes were pending, and Ubuntu had no tracker page for the flaw at the time.
• Red Hat JBoss Core Services and Red Hat Hardened Images were listed as affected with no fix.

Exploitation status

The picture is mixed, and worth stating carefully. Red Hat’s assessment says public research has demonstrated a reliable exploit against a default configuration with mod_http2 enabled, but it does not name or link that research. Wiz said on November 11 that no exploit was available and that it had seen no exploitation in the wild. A public proof of concept on GitHub reportedly reproduces memory corruption and process crashes but does not demonstrate code execution.

Wiz also reported that 64% of cloud environments in its data contained affected Apache versions and 51% had publicly exposed instances. Those figures do not account for configuration, so they overstate the number of exploitable servers.

Disclosure

Apache credited Anthropic’s OSS Scanner with reporting the flaw on October 26. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research independently reported it on November 3. Defiant has noted that WordPress updates cannot fix the issue, since it sits in the web server underneath.

Analysis: two independent finders inside nine days, one of them an automated scanner, suggests this class of bug in long-lived C modules is getting cheaper to find. That favors defenders only if patch pipelines move as fast as discovery does, and the distribution table above, with several major platforms still unfixed, is a reminder that they often do not.

For earlier Apache coverage, see Apache Answer, Apache Roller and Apache Syncope.