Apache HTTP Server has a critical flaw in its HTTP/2 implementation that can allow a remote attacker to execute code on a vulnerable server. The Apache project released version 2.4.71 on 11 November 2026 to address CVE-2026-119618. Debian, Ubuntu and Red Hat followed with security information on 12 November.
For web hosting operators, the immediate question is not merely whether Apache is installed. It is whether an affected HTTP/2 implementation can process requests from an untrusted client. That requires looking at the web server, its active protocols and the infrastructure in front of it.
The flaw is especially relevant to shared hosting, where a single Apache installation may serve many websites. Its position in HTTP request handling means that application-level authentication is not a substitute for addressing the vulnerable web server.
What CVE-2026-119618 affects
The Apache security advisory identifies a concurrency defect in the mod_http2 module's header handling function, assign_headers. Insufficient synchronization between execution paths can result in heap corruption. Apache classifies the issue as critical because remote code execution is a possible consequence.
The upstream affected range is Apache HTTP Server 2.4.55 through 2.4.70, inclusive. The separately distributed mod_h2 releases from 2.0.8 through 2.0.42 are also affected. Apache 2.4.71 contains the fix. Linux distributions may use different package versions or backport module changes, so the upstream range is not a universal test of package safety.
Red Hat's security bulletin RHSB-2026-017 explains that an unauthenticated attacker able to send HTTP/2 requests to an affected system can trigger the flaw. Servers offering only HTTP/1.1 are outside this vulnerability's protocol exposure.
That does not make HTTP/1.1 a security solution in general. Nor does it establish that other Apache vulnerabilities are absent. It defines the boundary for this CVE.
Why a web protocol bug can become code execution
HTTP/2 allows multiple streams to share a connection. A server needs to manage protocol state, request headers and work performed concurrently. Apache's mod_http2 documentation describes how the module adds HTTP/2 support and uses workers to process requests.
The vulnerable function is part of that implementation. Improper synchronization can leave one execution path manipulating memory while another is operating on related state. If memory is corrupted, a process may crash. Under exploitable conditions, memory corruption can also be used to redirect execution.
The advisory identifies a code execution risk, not a guarantee that every malicious request succeeds. Exploitability depends on the affected implementation and runtime circumstances.
If exploitation succeeds, the initial consequences are governed by the privileges of the affected server process. A compromised worker could have access to files, credentials or application resources available to that process. It does not automatically follow that the attacker obtains root privileges, access to every tenant or control of the physical host. Hosting isolation and process permissions determine much of the potential blast radius.
Does Cloudflare or another reverse proxy remove the risk?
A reverse proxy introduces a second protocol connection. A browser may negotiate HTTP/2 with a CDN, while the CDN connects to the origin using HTTP/1.1. The browser-facing connection alone does not prove that Apache's HTTP/2 module is processing requests.
Consider two designs. In the first, a CDN terminates HTTP/2 and forwards HTTP/1.1 requests to an origin that cannot be reached directly by internet clients. In the second, the origin accepts HTTP/2 itself, either from the proxy or through a separate public listener. The relevant exposure is different even if both websites advertise HTTP/2 support to browsers.
Every route to the origin matters, including secondary hostnames, management endpoints and direct access to the origin address. HTTP/2 may also be enabled without TLS through h2c, as the Apache documentation explains. HTTPS is not a prerequisite for every HTTP/2 connection.
A CDN can reduce exposure in some configurations. It should not be treated as evidence that a vulnerable origin has been patched. Likewise, generic web application firewall rules do not establish that a thread-safety defect in the server's protocol implementation has been eliminated.
The version number on a Linux server can be misleading
Enterprise and long-term-support distributions frequently apply security fixes to maintained package branches without adopting the newest upstream release wholesale.
Debian's DSA-6620-1 advisory, published on 12 November, identifies 2.4.71-1~deb13u1 as the fixed package for Debian 13 (trixie). Its update addresses three vulnerabilities.
Ubuntu's USN-9090-1 notice specifies several releases affected by CVE-2026-119618, including Ubuntu 20.04 LTS, 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10. The Ubuntu CVE record additionally notes that newer HTTP/2 module versions had been backported to stable releases. An inventory looking only at the original upstream Apache version may consequently produce false negatives.
Red Hat reports that fixes are available for most affected products, with other fixes being expedited. Its bulletin is the appropriate reference for product-specific status rather than an assumption that all RHEL installations receive the same package.
A container image or appliance creates another layer of version ownership. Updating a host operating system does not replace an Apache binary bundled inside a container. The fixed package must actually reach the deployed service.
Two independent discoveries, one vulnerable implementation
Apache credits Anthropic's OSS Scanner with reporting the flaw on 26 October. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research independently reported it on 3 November. The project records the fix and 2.4.71 release on 11 November.
The separate reports establish that two research efforts found the same defect. They do not establish that attackers exploited it in production, or that one discovery proves a general vulnerability-detection rate for AI tools.
An internet-facing HTTP/2 service with an affected implementation deserves prompt attention. Once an appropriate update is deployed, the remaining questions are whether all instances are actually running the fixed code and whether any earlier compromise needs investigation. A corrected package protects future request handling; it cannot undo actions that occurred before the update.