Apache HTTP Server 2.4.71 fixes a critical vulnerability in its HTTP/2 module that can lead to remote code execution, according to Apache’s vulnerability advisory. The November 11 release addresses CVE-2026-119618 in mod_http2, affecting upstream Apache HTTP Server versions 2.4.55 through 2.4.70.
The patch matters because Apache remains a common internet-facing web server, but the practical exposure is narrower than the upstream version range alone suggests. Red Hat’s CVE assessment says a server must have HTTP/2 enabled through Apache’s Protocols directive, with h2 or h2c configured. Systems serving HTTP/1.1 only are not affected under that assessment.
Concurrency flaw sits in HTTP/2 request handling
Apache describes the issue as a synchronization problem involving concurrent execution and shared resources in mod_http2. Under the right conditions, that defect can corrupt heap memory and lead to remote code execution. Red Hat characterizes it as a thread-safety flaw in the handling of concurrent HTTP/2 requests.
HTTP/2 changes how browsers and servers exchange web resources. Rather than opening separate connections for many requests, the protocol can multiplex numerous streams through one connection. That improves efficiency, but it also makes correct coordination of stream state, memory and concurrent work essential. A synchronization failure in this layer is particularly serious because an attacker need only reach the public web service, not first obtain a valid account.
Red Hat gives its general assessment a CVSS v3 score of 9.8 out of 10, with a vector indicating network reachability, low attack complexity, no privileges and no user interaction. Its advisory says the flaw could allow a remote, unauthenticated attacker to execute arbitrary commands on affected servers, potentially taking control of the host.
Version, configuration and vendor packaging alter the risk
For administrators running Apache’s upstream builds, the immediate task is to identify installations in the affected 2.4.55-to-2.4.70 range, determine whether HTTP/2 is enabled, and move to 2.4.71. Apache also lists separately released mod_h2 versions 2.0.8 through 2.0.42 as affected. The distinction is useful because some deployments use distribution-maintained packages rather than a stock upstream installation, and package behavior can differ from the headline Apache version.
Red Hat’s product analysis illustrates why a single severity label cannot simply be pasted onto every deployment. While the company rates the general CVE assessment Critical, it rates its Red Hat Enterprise Linux 9 and 10 mod_http2 packages Important. Red Hat says those packages use a separate allocator for each HTTP/2 stream, which raises exploitation complexity compared with the general case. RHEL 8 and earlier, Red Hat says, do not contain the affected code.
That is not a dismissal of the underlying flaw. It is a product-specific mitigation detail. Organizations using RHEL should consult their applicable Red Hat advisory and package updates rather than assume either that the upstream 9.8 score precisely describes their systems or that they are insulated by the lower product rating. The same principle applies to other operating-system distributions and managed hosting stacks: the relevant question is the vendor’s current package status and the actual HTTP/2 configuration.
Teams that cannot patch immediately may consider temporarily restricting affected servers to HTTP/1.1 by removing h2 and h2c from the Protocols directive. That mitigation was attributed to Wiz in follow-up reports by The Hacker News and BastionZero, rather than presented as an Apache workaround in Apache’s own advisory. Disabling HTTP/2 can affect application performance and compatibility, so it is a temporary operational choice, not a substitute for installing the corrected software.
Exploit status remains unclear in public accounts
The available reporting contains an important unresolved difference over exploit status. Red Hat says public research has demonstrated a reliable exploit against a default-configured server with mod_http2 enabled. Its advisory does not identify or link that research.
By contrast, BastionZero and The Hacker News reported that Wiz said no exploit was available and that exploitation in the wild had not been reported. Those reports do not explain whether “no exploit” meant no publicly released exploit code, no independently usable proof of concept, or something else. They also do not contradict Red Hat’s specific claim that research demonstrated reliability under a default configuration, but they leave the public availability of exploit material unsettled.
There is no basis in these accounts to say the vulnerability is being exploited in the wild. Nor should the absence of a confirmed active campaign be treated as a reason to defer patching: the affected component is ordinarily exposed to untrusted network traffic, and the configuration condition is straightforward to check.
A short disclosure-to-patch timeline
Apache’s advisory records reports to its security team from Anthropic on October 26 and from Google on November 3. It lists the correction in the 2.4.x branch and the 2.4.71 release on November 11. Security-news coverage followed the next day, focusing on the potential for unauthenticated execution and the configuration requirement.
For operations teams, the most useful inventory is not merely every server labelled Apache. It is the subset running the vulnerable mod_http2 code, exposing HTTP/2, and awaiting the vendor’s corrected package or an upgrade to 2.4.71. Red Hat’s architecture-specific rating is a reminder that exploitability is shaped by the software actually deployed, not only by the CVE headline.