Short answer: CVE-2026-119618 is a race condition in Apache HTTP Server's mod_http2 module that can lead to remote code execution. It affects Apache HTTP Server 2.4.55 through 2.4.70, and separately the standalone mod_h2 project on GitHub, versions 2.0.8 through 2.0.42. The fix shipped in Apache HTTP Server 2.4.71 on 11 November 2026. No authentication is required, but only servers that actually load mod_http2 and speak HTTP/2 through Apache itself are exposed. Checking your version number is not enough: you need to know whether the module is loaded at all.
What Is CVE-2026-119618?
NVD describes it plainly: a Concurrent Execution using Shared Resource with Improper Synchronization vulnerability, CWE-362, in Apache HTTP Server's mod_http2, specifically inside the assign_headers() function, that can lead to remote code execution. In plain terms, this is a race condition. Two execution paths touch the same shared data structure without the locking they need, and under the right timing, that mismatch corrupts memory. Memory corruption bugs in a long-running server process are exactly the kind of thing that escalates from a crash to arbitrary code execution once someone works out a reliable trigger.
mod_http2 is the module that gives Apache native HTTP/2 support. It parses incoming HTTP/2 frames, including headers, across multiple concurrent streams on the same connection, which is precisely the kind of concurrent, shared-state processing where synchronization bugs like this one live.
Who Found It, and When
The vulnerability was identified by Anthropic's open source vulnerability scanner, which reported it to the Apache Software Foundation's security team on 26 October 2026. Independently, Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported the same class of issue on 3 November 2026. Apache shipped the fix in HTTP Server 2.4.71 on 11 November 2026, and NVD published the CVE record the following day, 11 November 2026 at 15:17 UTC.
Two independent research teams landing on the same bug in the same module within about a week of each other is worth noting on its own: it suggests mod_http2's header-assignment path was ripe for discovery by anyone doing serious fuzzing or static analysis of HTTP/2 implementations, not a one-off finding.
Is There a CVSS Score?
This is where a lot of the coverage around this CVE gets it wrong, so it is worth being precise. Red Hat has rated this vulnerability 9.8, which is the score circulating in most summaries you will see. NVD, as of this writing, has not assigned its own CVSS vector to CVE-2026-119618; the metrics field in the NVD record is empty. These are two different organizations, and they do not always agree, or move at the same speed. If a source tells you "NVD scored this 9.8," that source is wrong today. Red Hat's 9.8 is a reasonable estimate given that this is an unauthenticated, network-exploitable memory corruption bug, but it has not been independently confirmed by NVD's own scoring at the time of publication.
Is This Being Exploited Right Now?
No public exploit code exists, and no in-the-wild exploitation has been documented. Wiz, which tracks this class of vulnerability closely, states explicitly that there is no evidence of active exploitation at this time. That said, public research has already demonstrated a reliable trigger against Apache's default mod_http2 configuration, meaning the hard part, proving the bug is exploitable rather than just theoretically unsafe, has already been done publicly. The gap between "a research team can trigger this reliably" and "someone automates it into a worm" is usually measured in days, not months, once a write-up with enough detail circulates. Patch on the assumption that the gap is closing, not on the assumption that it has not opened yet.
Which Versions Are Affected
- Apache HTTP Server 2.4.55 through 2.4.70, when mod_http2 is compiled in and loaded. Apache HTTP Server 2.4.71 is the fixed release.
- Standalone mod_h2, version 2.0.8 through 2.0.42, the independent GitHub project by the same original author that some distributions and custom builds use instead of, or alongside research into, the bundled Apache module. There is no published fixed version for standalone mod_h2 at the time of writing.
Both are affected because they share lineage in the header-handling code path. If you built Apache yourself with a vendored or separately tracked mod_h2, do not assume that upgrading apache2 or httpd from your distribution's package manager alone covers you; check which header-processing code your build actually links against.
How Do I Check in One Command?
The version number alone is the wrong test. A server running Apache 2.4.69, inside the affected range by the numbers, is not exposed if mod_http2 was never compiled in or never loaded. Conversely, a server that silently vendors an old mod_h2 build might be exposed in ways a package manager will not surface. The question that actually matters is whether the module is present and loaded, and the fastest way to answer it is to look for the shared object file itself.
If Apache is installed under /opt/panelica, the module lives at:
ls /opt/panelica/services/apache/modules/mod_http2.so"No such file or directory" means that installation does not carry the module, so this CVE cannot reach it regardless of the Apache version string. For a standard distribution install, the equivalent check is:
# Debian/Ubuntu
dpkg -l | grep libapache2-mod-http2 ; ls /usr/lib/apache2/modules/mod_http2.so
# RHEL/AlmaLinux/Rocky
httpd -M 2>/dev/null | grep http2 ; ls /usr/lib64/httpd/modules/mod_http2.soIf either command finds the file, or if httpd -M lists http2_module as loaded, that server needs the Apache 2.4.71 upgrade. If neither finds anything, the module simply is not there to exploit.
Does This Affect Panelica?
No. We checked this directly on 12 November 2026, and the reasoning is worth walking through because it illustrates exactly why version-number matching is the wrong way to triage this CVE.
Panelica's Apache package is version 2.4.69, which sits squarely inside the range NVD lists as affected. On a version-number-only reading, this installation would get flagged by any scanner that just diffs release numbers. It is not, in fact, exposed, for a specific and checkable reason: mod_http2 is not part of the build at all.
httpd -lon our Apache binary lists exactly three compiled-in modules:core.c,mod_so.c, andhttp_core.c. HTTP/2 support is not statically linked into the binary.- Our Apache package ships 95 loadable modules as
.sofiles.mod_http2.sois not one of them, and there is no copy of it anywhere under our Apache installation; the only references to "http2" that exist are a header file and the stock manual pages that ship with the Apache source tree, neither of which is executable code. - Our Apache build recipe does not pass
--enable-http2at configure time, and does not referencenghttp2anywhere. Apache cannot build mod_http2 without linking against libnghttp2, so the absence of that dependency at build time is not an accident, it is structural.
There is a second layer worth being honest about, because overstating protection is as misleading as understating a risk. Panelica terminates HTTP/2 at nginx, not at Apache. Our nginx build is compiled with --with-http_v2_module, and every customer virtual host enables HTTP/2 at that layer. Requests then reach Apache over plain HTTP/1.1 on the loopback interface, on an internal port that is never exposed to the internet. HTTP/2 exists in our stack; it just is not Apache's implementation of it.
That distinction matters for what this protects against and what it does not. Not shipping mod_http2 protects against bugs that live specifically in Apache's own HTTP/2 implementation, including this one. It does not make a server immune to HTTP/2 as a protocol: issues at the protocol level, like the 2023 Rapid Reset attack, are a property of any HTTP/2 server, including nginx, and have to be mitigated wherever HTTP/2 is actually terminated. The accurate statement is that bugs in Apache's HTTP/2 implementation cannot reach a Panelica server, because that implementation is not present. It is not that HTTP/2 attacks in general cannot reach it.
A Pattern Worth Noticing
This is not mod_http2's first serious finding. HTTP/2 Rapid Reset, CVE-2023-44487, was exploited in the wild against HTTP/2 servers broadly in October 2023. The HTTP/2 CONTINUATION flood, CVE-2024-27316, followed in April 2024. A double-free in mod_http2 itself was fixed in Apache 2.4.67. CVE-2026-119618 is the latest entry in a module that keeps producing concurrency and memory-safety issues, which tracks with what it is: a C module parsing attacker-controlled, multiplexed binary frames across concurrent streams, which is a genuinely hard problem to get right in a memory-unsafe language.
Terminating HTTP/2 at a dedicated edge layer, whether that is nginx, a CDN, or a reverse proxy, and speaking HTTP/1.1 to the application server behind it is a common pattern for exactly this reason. It is not a universal defense against every class of bug, as the Rapid Reset example shows, but it does mean that application-server-specific implementation bugs in a protocol that complex stay contained to whichever component actually parses the protocol on the wire.
What to Do Right Now
- Run the one-line check above on every Apache server you operate before doing anything else. Do not trust a version number alone.
- If mod_http2.so is present and loaded, upgrade to Apache HTTP Server 2.4.71 as the priority. Treat it as urgent given the public research into reliable triggers, even without a confirmed in-the-wild exploit yet.
- If you maintain a custom build against the standalone mod_h2 project, track that repository directly; there is no fixed release to point to yet, and a package manager upgrade of Apache itself will not cover a separately vendored mod_h2.
- If the module is simply not present, this CVE does not apply to that server, regardless of the Apache version installed.
Frequently Asked Questions
What is CVE-2026-119618?
A race condition, CWE-362, in the assign_headers() function of Apache HTTP Server's mod_http2 module, which can lead to memory corruption and remote code execution. It affects Apache HTTP Server 2.4.55 through 2.4.70, and separately the standalone mod_h2 project, versions 2.0.8 through 2.0.42.
Which Apache versions are affected?
Apache HTTP Server 2.4.55 through 2.4.70, when mod_http2 is compiled in and loaded. The fix is in Apache HTTP Server 2.4.71, released 11 November 2026. The vulnerability only applies to installations that actually load the mod_http2 module.
How do I check if mod_http2 is loaded on my server?
Look for the module file directly rather than relying on the version number: on Panelica, ls /opt/panelica/services/apache/modules/mod_http2.so; on a standard Debian or Ubuntu install, check for the libapache2-mod-http2 package and the file at /usr/lib/apache2/modules/mod_http2.so; on RHEL-family systems, run httpd -M | grep http2. If the module is absent or not listed as loaded, that server is not exposed to this CVE.
What is the actual CVSS score for CVE-2026-119618?
Red Hat has assigned a score of 9.8. NVD has not yet published its own CVSS vector for this CVE as of this writing. Treat the 9.8 figure as a vendor assessment, not an NVD-confirmed score, until NVD updates the record.
Is CVE-2026-119618 being actively exploited?
No public exploit code or confirmed in-the-wild exploitation has been reported as of publication. Public research has, however, demonstrated a reliable way to trigger the underlying race condition against Apache's default HTTP/2 configuration, which is typically the step that precedes weaponized exploitation.
Does this affect Panelica?
No. Panelica's Apache package is version 2.4.69, inside the numerically affected range, but it does not ship, compile, or load mod_http2 at all: Apache's own module list shows no HTTP/2 support compiled in, the module file is absent from the package, and the build recipe never links against the nghttp2 library HTTP/2 support would require. HTTP/2 in our stack is handled entirely by nginx, which sits in front of Apache and speaks HTTP/1.1 to it internally. This protects against bugs specific to Apache's own HTTP/2 implementation; it does not make the stack immune to HTTP/2 protocol-level issues in general, which would need to be addressed at whichever layer terminates HTTP/2, in our case nginx.