Apache patches critical mod_http2 RCE (CVE-2026-119618)

Apache released HTTP Server 2.4.71 on 11 November 2026 to fix CVE-2026-119618, a memory-corruption bug in the mod_http2 module that the project rates critical and Red Hat scores 9.8. The Apache advisory describes it as a "Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers()" that "can lead to RCE" — a thread races another thread's memory, corrupting the heap, and an unauthenticated remote attacker who can reach an HTTP/2-enabled server could potentially execute code. Only servers that enable HTTP/2 via the Protocols directive are affected. The upstream advisory is on the Apache security page; the fix is commit 824beab9.

Affected versions

• Apache HTTP Server: 2.4.55 through 2.4.70. Fixed in 2.4.71.
• Standalone mod_h2 (the GitHub module releases): 2.0.8 through 2.0.42. No tagged fixed release at time of writing — rebuild from the fixed commit or move to the httpd package.
• Not affected: mod_http2 before 2.0.8 (the vulnerable code isn't present), and any server running HTTP/1.1 only.

Distribution fixes are already shipping: RHEL 9 mod_http2-2.0.26-7.el9_9.1, RHEL 10 mod_http2-2.0.29-5.el10_3.1, and Debian unstable apache2 2.4.71-1. Red Hat rates RHEL 9 and 10 Important rather than Critical because each HTTP/2 stream gets its own memory allocator there, which makes exploitation materially harder; RHEL 8 and earlier are not affected. Debian bookworm, trixie, and forky are listed as vulnerable with no fix published yet.

Exploitation status

No confirmed exploitation in the wild. The two readings diverge on how close it is: Red Hat's advisory states that "public research has demonstrated a reliable exploit" against default configurations with mod_http2 enabled, while Wiz says no public exploit was available and no in-the-wild activity had been reported. Treat it as pre-exploitation on a 9.8 default-config RCE — the window is short.

The flaw was reported on 26 October 2026 by Anthropic's OSS Scanner, and separately by Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research.

Action checklist

1. Inventory HTTP/2. Grep your configs for Protocols lines containing h2 or h2c. HTTP/1.1-only servers are out of scope — don't burn a maintenance window on them.
2. Patch to 2.4.71 (or your distro's fixed mod_http2 build above) on every HTTP/2-enabled front end and reverse proxy.
3. Can't patch today? Disable HTTP/2. Wiz's interim mitigation is to drop h2 and h2c from the Protocols directive, leaving Protocols http/1.1, and reload. That removes the attack surface at a performance cost.
4. Don't forget embedded Apache. Appliances, load balancers and vendor products that bundle httpd with HTTP/2 on are the ones that will still be vulnerable in six months.
5. If you run standalone mod_h2, rebuild from commit 824beab9 — there is no tagged release to pull.

Context

This is the second RCE-capable mod_http2 flaw this cycle: the earlier CVE-2026-23918 double-free was fixed in 2.4.67, so servers sitting on 2.4.67 through 2.4.70 patched one HTTP/2 bug only to remain exposed to this one. HTTP/2's per-connection state machine keeps producing memory-safety bugs under concurrency — we covered the HTTP/2 Bomb DoS class in June and a use-after-free in curl's HTTP/2 stack before that. The recurring lesson for operators is the same: HTTP/2 is a distinct, higher-risk code path, and "patch the web server" has to mean the HTTP/2 module specifically.

Worth noting who found it. The initial report came from an automated scanner (Anthropic's OSS Scanner) alongside human researchers at Google — the same pattern as the Codex-assisted HTTP/2 Bomb discovery earlier this year. Machine-assisted bug-finding is now a standing part of the disclosure pipeline for this protocol, and the patch cadence is tightening to match.