CVE-2026-119618: Critical Apache mod_http2 Flaw Allows Unauthenticated Remote Code Execution

A critical flaw in Apache HTTP Server's HTTP/2 module, mod_http2, lets an unauthenticated remote attacker run code on the server. Tracked as CVE-2026-119618 and rated 9.8 out of 10 on the CVSS scale by Red Hat, it affects Apache HTTP Server 2.4.55 through 2.4.70. The Apache HTTP Server project fixed it in version 2.4.71, released November 11. Only servers with HTTP/2 enabled are exposed.

The upstream patch is out, but many downstream packages are not. As of November 12, the stable Debian releases, every tracked Amazon Linux version and two Red Hat products had no fixed package, and Ubuntu had not published a status page for the CVE. The standalone mod_h2 module has no fix, and its archived project may never release one.

What the flaw does

Red Hat ships Apache HTTP Server as part of Red Hat Enterprise Linux. It says an attacker who can reach the server needs no authentication and could take full control of the server process. The attack runs over HTTP/2, so any listener that offers HTTP/2 is part of the attack surface.

The affected code covers Apache HTTP Server 2.4.55 through 2.4.70. Standalone builds of the module, released on GitHub as mod_h2, are affected from 2.0.8 through 2.0.42. Because the affected range is so wide, many servers that are otherwise kept up to date are still vulnerable.

Conflicting signals on exploitability

Red Hat's assessment, published November 11, says "public research has demonstrated a reliable exploit" against a server in its default configuration with mod_http2 enabled. Red Hat does not name or link that research. Later the same day, Wiz said no exploit was available and no exploitation in the wild had been reported.

Taken together, there is no confirmed public exploit and no confirmed attack, but one vendor says reliable exploitation is possible. The fixed 2.4.71 source is public, so attackers can compare it with 2.4.70 to find the bug. Plan for an exploit appearing within days, not weeks.

Where exposure comes from

According to the module documentation, HTTP/2 runs only where the Protocols directive enables it. The directive uses h2 for HTTP/2 over TLS and h2c for HTTP/2 over plain TCP. It can be set for the whole server or for a single virtual host, so a server whose global setting allows only HTTP/1.1 can still offer HTTP/2 on one virtual host.

• h2 on a TLS listener: the most common deployment, often enabled by default templates and hardening guides that recommend HTTP/2 for performance.
• h2c on a plain TCP listener: less common, but it exposes the same module without TLS in front of it.
• Virtual host overrides: a single site configured for HTTP/2 exposes the whole server process, not just that site.

Distribution patch status

Distributions ship their own builds with their own package version numbers, so the upstream version string alone does not show whether a server is fixed. Status as of November 12:

• Apache HTTP Server project releases: fixed in 2.4.71.
• Red Hat Enterprise Linux 9: fixed in mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981).
• Red Hat Enterprise Linux 10: fixed in mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978).
• RHEL 9.4 Update Services for SAP Solutions, and 9.6, 9.8, 10.0 and 10.2 Extended Update Support: fixed under RHSA-2026:98968, 98954, 98982, 98953 and 98979.
• Red Hat Enterprise Linux 6, 7 and 8: not affected, because they do not contain the vulnerable code.
• Red Hat JBoss Core Services and Red Hat Hardened Images: affected, no fix listed.
• Debian unstable (sid): fixed in apache2 2.4.71-1. Debian bookworm, trixie and forky: vulnerable, no fix listed.
• Amazon Linux 2 (Core), Amazon Linux 2023 and Amazon Linux 2027 Preview: fix pending.
• Ubuntu: no CVE status page published.

Red Hat rates the flaw Important on RHEL 9 and 10 rather than Critical. Its mod_http2 packages give each HTTP/2 stream its own memory allocator, which the vendor says makes an attack much harder. That rating applies to Red Hat's own builds only. Upstream builds, builds compiled from source and other distributions' packages should be treated as Critical.

Mitigation where no fix exists

The Apache HTTP Server advisory offers no workaround. In its vulnerability analysis, Wiz advises admins who cannot update yet to remove h2 and h2c from the Protocols directive and leave Protocols http/1.1. This closes the attack path because clients fall back to HTTP/1.1. The vulnerable code is still installed, and the change has to cover the server-wide setting and every virtual host.

Also fixed in 2.4.71

The release also fixes a crash in mod_md, which Apache rates important, and a one-byte overwrite of stack memory in mod_vhost_alias, which Apache rates low. Servers that use mod_md for automatic ACME certificate management benefit from the update even if HTTP/2 is disabled.

How it was found

Anthropic's OSS Scanner, a free service that uses the company's AI models to scan open-source projects, reported the flaw on October 26. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it independently last week. Two separate teams, one using AI-driven scanning, found the same bug in a core web server module within about two weeks. This suggests the bug was not hard to find for anyone looking, including attackers.

RedEye assessment

The highest risk sits with internet-facing Apache servers that offer HTTP/2 on Debian bookworm, trixie or forky, on any Amazon Linux release, on JBoss Core Services or Red Hat Hardened Images, and on any upstream or container build from 2.4.55 through 2.4.70. These servers have no vendor package to install today. Disabling HTTP/2 is the only published protection until one ships. Red Hat says a reliable exploit exists and the fixed source is public, so we expect exploitation attempts to begin soon. The patch gap on Debian and Amazon Linux leaves defenders less time than the 2.4.71 release date suggests.