Apache HTTP Server CVE-2026-119618: Critical mod_http2 RCE

The Apache HTTP Server — the single most widely deployed web server software on the internet — has a critical, unauthenticated remote code execution flaw in its HTTP/2 engine. CVE-2026-119618 is a race condition in mod_http2's assign_headers() function that an attacker can drive into heap corruption and, from there, code execution with the privileges of the web server process. Red Hat scored it CVSS 9.8. It affects Apache HTTP Server 2.4.55 through 2.4.70 and is fixed in 2.4.71, released November 11. There is no confirmed exploitation in the wild yet — but the way this one was found is the story: Apache credited Anthropic's OSS Scanner with reporting it on October 26, and Google Cloud's Vulnerability Research team independently found the same bug a week later.

Developing story — first published 16:48 CET (15:48 UTC), November 12, 2026. Updated as the vendors and CISA publish more.

At a glance

CVE	CVE-2026-119618
Product / affected versions	Apache HTTP Server 2.4.55 through 2.4.70 (only with HTTP/2 enabled); standalone mod_h2 GitHub module 2.0.8 through 2.0.42
Fixed in	Apache HTTP Server 2.4.71 (released 2026-11-11); mod_h2 module per the GitHub advisory; or your distribution's backported httpd package
CVSS	9.8 Critical · CVSS 3.1 · scored by Red Hat · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · NVD record still "Received", not yet scored
Exploited in the wild	No reports as of 2026-11-12 (Wiz); Red Hat notes public research has demonstrated a reliable exploit against a default-configured server with mod_http2 enabled
CISA KEV	Not listed (catalog version 2026.11.10)
Public PoC	A crash-only PoC is public (reproduces memory corruption and Apache process crashes, not full RCE, per SecurityWeek)
Official advisory	Apache httpd security advisory (vulnerabilities_24)

What CVE-2026-119618 actually is

The defect is a concurrent-execution race condition (CWE-362) in mod_http2, the module that implements HTTP/2 for Apache. Inside assign_headers(), a shared resource is accessed by concurrent threads without the synchronization needed to keep that access safe. HTTP/2 multiplexes many streams over one connection, and an attacker who controls the timing and shape of those streams can win the race, corrupt the heap, and — the hard part, which the vendor says has been demonstrated — steer that corruption into executing attacker-supplied code. No credentials, no user interaction, nothing but reachability of an HTTP/2 endpoint.

The scope condition is the one piece of good news, and it is decisive:

"Only servers that have HTTP/2 enabled are affected; servers configured to serve only HTTP/1.1 are not vulnerable." — Red Hat's advisory.

HTTP/2 is enabled when mod_http2 is loaded and h2 (over TLS) or h2c (cleartext) appears in your Protocols directive. That is an extremely common configuration — most TLS-terminating Apache front ends turned HTTP/2 on years ago for the performance — but a server locked to HTTP/1.1 is out of scope entirely. That fact is also your fastest compensating control, which is why it leads the remediation below.

A nuance worth knowing if you run Red Hat: on RHEL 9 and RHEL 10, mod_http2 allocates each stream from a separate allocator, which Red Hat says makes exploitation substantially harder and is why it rates those two Important rather than Critical. RHEL 8 and earlier are not affected. That does not change the instruction — patch — but it tells you where on the priority list a given host sits.

Found by an AI scanner, then by a human team

For once the discovery credit is the headline, not a footnote. Apache's advisory lists two independent finders of the same race condition: Anthropic's OSS Scanner — an automated system that audits open-source code — filed it as vulnerability ANT-2026-MAPKT6MZ and reported it on 2026-10-26; Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it independently on 2026-11-03. A machine found a memory-safety bug in one of the most-reviewed C codebases in existence, in code paths that have been in production since 2.4.55, and a top-tier human research team arrived at the same bug a week later.

That convergence is the part defenders should internalize. The economics of finding bugs like this one are changing: automated code analysis now surfaces real, critical, pre-disclosure vulnerabilities in software everyone runs, and it does so at a cadence and scale no manual review matches. The defensive mirror image is uncomfortable — the same class of tooling that found CVE-2026-119618 responsibly is available to people who will not file an advisory. "Reviewed for decades" is no longer a reason to assume a codebase is clean.

Are my servers affected?

Two checks decide it. First, the version:

# Red Hat / RPM family
httpd -v
# Debian / Ubuntu family
apache2 -v

If it reports Apache/2.4.55 through 2.4.70, the build is in range. Then confirm HTTP/2 is actually on — a 2.4.70 server with HTTP/2 disabled is not vulnerable:

# Is mod_http2 loaded?
httpd -M 2>/dev/null | grep -i http2     # or: apache2ctl -M | grep -i http2
# Is h2/h2c in the Protocols directive?
grep -rniE '^[[:space:]]*Protocols' /etc/httpd /etc/apache2 2>/dev/null

If mod_http2 is loaded and Protocols lists h2 or h2c, you are exposed and should treat an internet-facing instance as the first thing to fix tonight.

Remediation

1. Am I affected?

Run the two checks above on every Apache instance — the real running build after the last maintenance window, not the one you think you deployed. Inventory internet-facing instances first (anything answering on 443/80 at the edge, reverse proxies, load-balancer back ends, appliance web consoles that embed httpd), then internal ones. Any 2.4.55–2.4.70 build with mod_http2 loaded and h2/h2c enabled is in scope.

2. Patch — the exact fixed version

Upgrade to Apache HTTP Server 2.4.71 (released 2026-11-11), or install your distribution's backported httpd/apache2 package carrying the fix — Red Hat, AlmaLinux, Gentoo, Microsoft Azure Linux and others shipped tracked updates. If you build the standalone mod_h2 module from GitHub, move off the 2.0.8–2.0.42 range per the module's advisory. Restart the service after upgrading and confirm the running version; a package that is installed but not reloaded is still serving the vulnerable code.

3. Can't patch now? Compensating controls

• Turn HTTP/2 off. This is the single highest-value stopgap and it removes the vulnerable code path entirely. Set Protocols http/1.1 in your server/vhost configuration, remove any h2 and h2c tokens, and reload. Clients fall back to HTTP/1.1 transparently; you lose some performance, not availability.
• Or unload the module. Where HTTP/2 isn't needed, disable mod_http2 outright (a2dismod http2 on Debian/Ubuntu, or comment the LoadModule http2_module line on RPM systems) and reload.
• Restrict exposure. For an instance that must keep HTTP/2, limit who can reach it (allowlist, VPN, WAF in front) while you schedule the patch. This narrows the attacker population; it is not a substitute for the fix.

4. Hunt for compromise

No vendor or researcher IOCs have been published, so hunt on behavior, not indicators — and do not invent IOCs. Generalizable signals for a memory-corruption RCE in a web server (mapped to MITRE ATT&CK):

• Repeated worker crashes / segfaults attributed to mod_http2 in your error log or kernel dmesg. The public PoC is crash-only, so a burst of HTTP/2 worker segfaults can mark probing or an attempt in progress, even before any code runs (T1190 Exploit Public-Facing Application).
• Child processes spawned by the Apache service account (apache, www-data, httpd) — shells, interpreters, or network tools launched by the web server have no business existing (T1059 Command and Scripting Interpreter).
• New or modified files under the document root or cgi directories — a web shell dropped for persistence (T1505.003 Web Shell).
• Anomalous outbound connections from the web host to never-seen destinations — a tool pull, a beacon, or data staging and egress (T1041 Exfiltration Over C2 Channel).

5. Eradicate and verify

If you find an implant, removing the file is not enough: rebuild from a known-good image where feasible, and rotate every secret the web host could read — the server's TLS private keys first, then any application database credentials, API tokens or service-account keys present on that host. Invalidate active sessions. Then confirm the fix after patching: re-test that the HTTP/2 endpoint no longer crashes or corrupts under the condition that demonstrated the issue, rather than trusting the version string alone.

What is not known yet

• NVD scoring. The NVD record is still in "Received" status with no CVSS assigned; the 9.8 above is Red Hat's score. A full NVD analysis and any CISA SSVC decision will follow.
• Weaponized RCE. Red Hat states public research has demonstrated a reliable exploit against a default-configured server, but the only public PoC so far produces crashes, not confirmed code execution. The gap between "reliable crash" and "reliable RCE" on this bug is not yet public — and that gap tends to close within days of a patch, via diffing.
• In-the-wild activity. No exploitation has been reported as of this writing, and the CVE is not in CISA KEV. The exposed population is large enough that this can change quickly.

Patch, or turn HTTP/2 off — and don't guess which hosts are actually reachable

The decision an operator faces tonight is concrete: patch to 2.4.71 across the fleet, or disable HTTP/2 as a holding action on the ones you can't touch yet — and in what order. That ordering question is where most teams either freeze the whole estate at once or quietly defer, and both are guesses. Zero Hunt's AI Remediation Advisor ranks the fix by real exploitability — CISA KEV status first (not listed, here), then what was proven reachable in your own environment, then CVSS and EPSS — and hands you the exact action per host: upgrade to 2.4.71 with rollback notes where that's clean, or the precise Protocols http/1.1 holding change where a maintenance window is days out, then re-verifies that the HTTP/2 path is no longer corruptible.

And because this bug was found by a machine reading source, the honest answer to "is my 2.4.70 front end actually driveable to code execution, or will it only crash?" isn't a version lookup — it is the question Zero Hunt's autonomous AI red team was built to answer. Running on an on-premise appliance on its own private models with a human in the loop, its 10-agent swarm identifies the exact Apache build and HTTP/2 configuration on your perimeter and, in an ephemeral hardened container that never touches the host, works a proof-of-concept until it demonstrably reaches code execution or demonstrably cannot — so you patch the genuinely-exposed hosts first instead of treating a crash-only probe and a working RCE as the same emergency. It is the difference between automated, continuous penetration testing that keeps pace with disclosures like this one and the annual report that names the bug a year late.