The Apache HTTP Server development project released its latest version, 2.4.71, on November 11. The release follows the discovery of a critical vulnerability (CVE-2026-119618) in the HTTP/2 support module “mod_http2” that can lead to remote code execution (RCE), and the project has classified the severity as “critical.” Versions 2.4.55 through 2.4.70 are affected, and affected environments are urged to update to the fixed version.
The root cause is improper synchronization of concurrent processing of shared resources. This can corrupt the heap and allow externally injected code to be executed. An attacker only needs to be able to reach the server without authentication, and a successful exploit could give full control of the server process. In its own assessment, Red Hat gave the vulnerability a CVSS score of 9.8 out of 10 and noted that “reliable exploits have been demonstrated in public research” against servers in default configurations with mod_http2 enabled. However, it did not provide the name or link of the specific research. Security firm Wiz, by contrast, said the same day that no exploitable proof-of-concept exists and that there have been no reports of exploitation in real-world environments, indicating a divergence in assessments. According to Wiz’s analysis, 64% of cloud environments contain resources affected by the vulnerability, and 51% have internet-exposed instances. It noted, however, that these figures do not take into account configurations such as whether HTTP/2 is enabled or disabled.
The scope of impact extends beyond the Apache HTTP Server itself. The standalone module “mod_h2,” published on GitHub, is also affected in versions 2.0.8 through 2.0.42. However, that repository has been read-only since it was archived on June 9, and no fixed version has been published. Servers using the standalone module must also mitigate the risk through the configuration changes described below.
In addition to the critical issue, the release fixes two other bugs. A NULL pointer dereference in mod_md (CVE-2026-106023), which handles automatic certificate acquisition and renewal, crashes a child process while processing an HTTP request; its severity is “important,” and versions 2.4.30 through 2.4.70 are affected. The other is a one-byte buffer overwrite in mod_vhost_alias (CVE-2026-109163), with a severity of “low”; versions 2.4.69 and 2.4.70 are affected.
The three vulnerabilities fixed in 2.4.71 are as follows.
| CVE | Module | Severity | Affected Versions | Summary |
|---|---|---|---|---|
| CVE-2026-119618 | mod_http2 | critical | 2.4.55–2.4.70 | Heap corruption and remote code execution due to a race condition on shared resources |
| CVE-2026-106023 | mod_md | important | 2.4.30–2.4.70 | Child process crash due to NULL pointer dereference |
| CVE-2026-109163 | mod_vhost_alias | low | 2.4.69–2.4.70 | One-byte stack buffer overwrite |
The vulnerability discoverers listed are Anthropic’s “OSS Scanner” (management number ANT-2026-MAPKT6MZ) and two researchers from Google Cloud Vulnerability Research. The reports were filed on October 26 by Anthropic and on November 3 by the Google side; the fix was committed to the source code on November 11, and 2.4.71 was released the same day.
HTTP/2 runs only when enabled via the Protocols directive in the configuration file. HTTP/2 over TLS is specified with “h2,” and HTTP/2 over plain TCP with “h2c,” and this can be configured server-wide or per virtual host. Administrators therefore need to check both the server-wide configuration and the configuration of each virtual host. The Apache HTTP Server security advisory does not offer a workaround, but Wiz advises that, as an interim measure when updating is difficult, administrators remove h2 and h2c from the Protocols directive and leave only “http/1.1.”
Linux distributions are providing fixes through their own custom-built packages, with version numbers that differ from the upstream release. Red Hat had already distributed fixes for Red Hat Enterprise Linux 9 and 10 by the previous day, and it rates the severity as “Important” for its products. This is because its implementation, which assigns a dedicated memory allocator to each HTTP/2 stream, makes attacks more difficult, and RHEL 8 and earlier do not contain the vulnerable code.
| Target | Affected Versions | Fix Status |
|---|---|---|
| Apache HTTP Server (upstream) | 2.4.55–2.4.70 | Fixed in 2.4.71 |
| mod_h2 (standalone) | 2.0.8–2.0.42 | No fixed version (repository archived) |
| Red Hat Enterprise Linux 9/10 | Vendor builds | Fixed packages distributed (severity: Important) |
| Red Hat Enterprise Linux 8 and earlier | Not affected | Do not contain the vulnerable code |
Note: Red Hat’s fixed package for RHEL 9 is provided as “mod_http2-2.0.26-7.el9_9.1.” The status for Debian and Amazon Linux is based on the descriptions in their respective trackers.
In Japan, JVN (Japan Vulnerability Notes), operated by JPCERT/CC and IPA, published “Update for Multiple Vulnerabilities in Apache HTTP Server 2.4” (JVNVU#90805396) dated November 11. It calls for referring to the Apache advisory, and organizations in Japan should check it together with information from each vendor.
This is not the first vulnerability involving HTTP/2. CVE-2026-23918 was identified previously and fixed in 2.4.67, released on May 4. However, the current vulnerability also affects versions from 2.4.67 through 2.4.70. The repeated occurrence of HTTP/2-related flaws is something infrastructure operators cannot afford to overlook.
Apache HTTP Server is one of the most widely used web servers in the world, and its impact ranges from corporate mission-critical systems to individually operated sites. Organizations running affected versions should inventory not only externally exposed services but also internal systems and test environments, and update to 2.4.71 as soon as possible. Until they can update, a realistic approach is to reduce risk through layered defenses such as disabling HTTP/2 and detecting suspicious requests with a WAF (web application firewall). Those who installed the software through package management need to check the application status of the fixed versions published by their respective distributions.
