Facts checked Nov 12, 2026
Apache's critical mod_http2 flaw, fixed November 11, reaches only httpd servers that actually speak HTTP/2, so US companies should find those hosts, patch internet-facing ones first, and know what switching HTTP/2 off breaks.
The Apache HTTP Server project rates CVE-2026-119618 critical and says a flaw in assign_headers() "can lead to RCE" in versions 2.4.55 through 2.4.70, fixed in 2.4.71 (released November 11). Apache's advisory calls it heap corruption; Red Hat says a worker thread writes into memory owned by the connection thread through a shared, lock-free allocator. Apache gives no CVSS score; Red Hat rates it 9.8, and Red Hat and Wiz describe it as exploitable without authentication. Anthropic's OSS Scanner reported it on October 26 and Google Cloud Vulnerability Research on November 3. The standalone mod_h2 module, versions 2.0.8 through 2.0.42, is also affected; its repository was archived on June 9, 2026 and has no fixed release, so those users must move to the module bundled with httpd 2.4.71. The release also fixes two lower-severity bugs, in mod_md and mod_vhost_alias.
Which servers are actually exposed?
Version alone overstates exposure. Red Hat says servers serving only HTTP/1.1 are not affected, and upstream's default is HTTP/1.1 only. Wiz says 64% of cloud environments have vulnerable resources and 51% have publicly exposed instances, but notes that this "does not take configuration into account", so the figures do not show whether HTTP/2 is on.
Run three questions on every host. Is the version 2.4.55 through 2.4.70? Is mod_http2 loaded? Does any Protocols line list h2 or h2c, server-wide or in a virtual host? A vhost line replaces the server-wide one, per Apache's docs. Debian's packaged http2.conf (master, trixie and bookworm-security packaging branches) sets Protocols h2 h2c http/1.1, so on Debian enabling the module turns both on, and Debian-derived builds likely do the same; read that file on your hosts. Check container base images and bundled copies too; Red Hat lists JBoss Core Services as affected with no fix.
In our view, a server behind a load balancer that terminates HTTP/2 is out of reach only if h2c is off on the origin or the proxy does not forward upgrades, because h2c can start from an HTTP/1.1 connection.
Is a fixed package out for your platform?
As of the morning of November 12, RHEL 9 and 10 are fixed (Red Hat rates them Important, not Critical, citing a per-stream allocator). Debian 13 is fixed (DSA-6620-1); Debian 12 was still listed as vulnerable and Amazon Linux as pending a fix. On Ubuntu and any other distribution, check the vendor's tracker for your release before you rely on a package.
What to do now
- Platform team, today: inventory hosts with the three questions; rank internet-facing first.
- Platform team, today, where no fixed package exists: set
Protocols http/1.1(Wiz's workaround) server-wide and in every vhost that has its own line, or remove h2 and h2c there. Clients fall back to HTTP/1.1, which Apache's docs say is always available; we expect gRPC, and h2c between a proxy and its origin, to fail. Revert after patching. - Platform team, within days: upgrade to 2.4.71 or your distro's fixed package, then re-run the check.
- SOC, this week: we would treat unexplained httpd child crashes or segfaults on h2-enabled hosts as worth a look, since heap bugs often surface as crashes first. Also watch for a CISA KEV listing or a public exploit.
What is not known yet
Red Hat said "public research has demonstrated a reliable exploit" against a default-configured server with mod_http2 enabled, naming no research. Wiz said that, as of its November 11 post, "no exploit is available" and there are no reports of exploitation in the wild. In our view, Red Hat's statement means the window could close fast, so do not wait for a KEV listing to patch exposed hosts.
