SURIQ
If an Apache web server between 2.4.55 and 2.4.70 speaks HTTP/2 to the internet, it is running a memory-corruption bug that the Apache Software Foundation rates critical and says can lead to remote code execution (RCE). The fix is Apache HTTP Server 2.4.71, released November 11. The bug is CVE-2026-119618, a race in the HTTP/2 module. The real triage question for most hosting fleets is narrower than the version number: can a client actually reach Apache's own HTTP/2 code?
Which Apache versions are affected by CVE-2026-119618?
Every Apache HTTP Server release from 2.4.55 up to 2.4.70 carries the bug, and 2.4.71 contains the fix. The standalone mod_h2 module that is distributed on GitHub is hit in its 2.0.8 to 2.0.42 releases. Apache publishes no CVSS score, only its own "critical" rating, and lists no official workaround.
The flaw sits in assign_headers() inside mod_http2. According to the CVE record, it is a concurrency bug (CWE-362): two threads touch shared memory without proper locking, so the heap of the serving child process can end up corrupted. Apache's description stops at "can lead to RCE"; it does not say exploitation has been seen.
Two separate teams found it. Apache credits Anthropic's OSS Scanner, which reported it on October 26, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research, who reported it on November 3. The fix landed in the 2.4.x branch and shipped as 2.4.71 on November 11, the same day the CVE went public on the oss-security mailing list.
Exploit status: a crash reproducer, not a confirmed RCE exploit
On November 12, a GitHub account that is not one of the credited finders published a repository named after the CVE. By its own description it holds a lab, a version checker, and a client that drives the race until a child process crashes. We read it as crash-reproduction tooling. It is not a demonstrated code-execution exploit, and we found no report of exploitation in the wild. The CVE is not in CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing.
That gap will not last forever. Two research teams landing on the same bug within eight days tells you it is findable. Public tooling that reliably corrupts the heap is the first step anyone needs toward turning a crash into code execution. Treat the window between "it crashes" and "it runs code" as short.
Who is really exposed: the HTTP/2 path matters more than the version
Only connections that reach Apache's own HTTP/2 code can trigger this bug. That splits a typical hosting estate into three groups:
-
Apache terminates TLS and offers HTTP/2 itself.
mod_http2is loaded andProtocolslistsh2. This is the exposed case, and HTTP/2 is a setting many control-panel Apache builds let you switch on. -
Something else in front speaks HTTP/2. A CDN, Nginx, or a load balancer accepts HTTP/2 from the internet and talks to Apache over HTTP/1.1. The outside world never reaches
mod_http2, though any internal port that still allowsh2c(cleartext HTTP/2) is worth a look. -
The module is not loaded at all. No
mod_http2, no exposure from this CVE.
Do not trust the package version string on its own. Linux distributions routinely backport fixes into an older-looking version number, and some can carry HTTP/2 module code from a newer upstream release than their base version suggests. Check your distribution's security tracker for CVE-2026-119618, not just the output of httpd -v. A box that reports 2.4.62 may be fixed; another may still be exposed.
The same caution applies to control panels that ship their own Apache build. Confirm the panel vendor has published a package that includes the fix before you mark those servers done. For comparison with other web servers in this stack, our earlier breakdown of the Nginx RCE config triage and the LiteSpeed Enterprise root escalation walk through the same "is my config even reachable" question.
How to check a server and spot crashes in the logs
Three quick checks answer whether a given host is exposed, and one log search shows whether something has been poking at it. A heap race in a threaded module tends to show up first as child processes dying with a segmentation fault, which Apache records in its error log.
httpd -v apachectl -M 2>/dev/null | grep -i http2 grep -RniE '^\s*Protocols' /etc/httpd/ /etc/apache2/ 2>/dev/null grep -E 'AH00052: child pid [0-9]+ exit signal (Segmentation fault|Aborted)' /var/log/httpd/error_log /var/log/apache2/error.log
A server that answers yes to the first three (an affected, unpatched build, http2_module loaded, and h2 in Protocols) is in scope. A sudden run of AH00052 child crashes on such a server is not proof of an attack, since other bugs crash children too. It is still the signal worth investigating now, ideally next to the access log lines from the same seconds.
Patch to 2.4.71, or switch off HTTP/2 until you can
Upgrading to 2.4.71, or to a distribution or panel package that carries the fix, then restarting Apache is the fix. If you run the standalone module, the fixed release reported alongside the advisory is mod_h2 2.0.43. After the upgrade, do a full restart rather than a graceful reload and confirm the running build with httpd -v.
Where a patch cannot go out today, the interim step is to stop offering HTTP/2 from Apache: remove h2 and h2c from every Protocols line (vhosts included), or stop loading mod_http2. Clients fall back to HTTP/1.1. You lose some page-load speed and close the only path to this bug. Apache's advisory itself does not list a workaround, so treat this as a stopgap and still patch.
Patching closes the hole, but it does not tell you whether anyone used it first. For servers that sat exposed with HTTP/2 on, pull the error logs from the past few weeks before you rotate them. Look for a cluster of child crashes that did not line up with a deploy or a load spike. A crash pattern with no explanation on an internet-facing box is the thread to pull.