Security & privacy

Critical Apache HTTP/2 flaw allows remote code execution in versions 2.4.55 to 2.4.70

A critical vulnerability in Apache's mod_http2 module enables unauthenticated remote code execution. Patches are available for version 2.4.71 and specific Linux distributions.

Server rack with red warning light and binary code
Illustration created for this article

A severe security vulnerability has been identified in the Apache HTTP Server, specifically within its HTTP/2 module, mod_http2. Tracked as CVE-2026-119618, this flaw allows unauthenticated attackers to execute arbitrary code on affected servers. The issue impacts versions 2.4.55 through 2.4.70 and was addressed in the release of version 2.4.71 yesterday.

What happened

The vulnerability resides in the mod_http2 module, which handles HTTP/2 traffic for the Apache web server. According to Red Hat, an attacker who can reach the server does not need authentication to exploit this flaw. Successful exploitation could grant the attacker full control over the server process. Red Hat rates the severity at 9.8 out of 10 on the CVSS scale, indicating a critical threat level. The vendor’s assessment notes that public research has demonstrated a reliable exploit against servers running with default configurations where mod_http2 is enabled, though no specific research paper was linked.

Conflicting reports exist regarding active exploitation. While Red Hat highlighted the existence of a reliable exploit method, security firm Wiz stated later that day that no public exploit code was available and no wild exploitation had been observed. This discrepancy suggests that while the theoretical risk is extreme and proof-of-concept methods exist, widespread automated attacks may not yet be underway. Administrators should treat the threat as imminent given the high severity score and the ease of access required for exploitation.

The fix is contained in Apache HTTP Server version 2.4.71, released yesterday. This update also resolves a crash in the mod_md module, rated as important, and a low-severity one-byte stack memory overwrite in mod_vhost_alias. For those using standalone builds of the module from GitHub under the name mod_h2, versions 2.0.8 through 2.0.42 are affected. No fixed release has been published for these standalone builds, and the repository has been read-only since June 9.

Key details

  • CVE Identifier: CVE-2026-119618 affects Apache HTTP Server versions 2.4.55 through 2.4.70.
  • Fixed Version: Apache HTTP Server 2.4.71 resolves the issue; standalone mod_h2 remains unfixed.
  • Attack Vector: Remote, unauthenticated attackers can execute code if HTTP/2 is enabled via h2 or h2c protocols.
  • Red Hat Status: Fixes shipped for RHEL 9 and 10; RHEL 8 and earlier are not affected due to different module architecture.
  • Debian Status: Debian unstable (sid) is fixed; Debian bookworm, trixie, and forky remain vulnerable with no listed fix.
  • Workaround: If patching is not immediately possible, remove h2 and h2c from the Protocols directive to disable HTTP/2.

Background

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It introduces improvements such as multiplexing, header compression, and server push to enhance performance. In Apache, this functionality is provided by the mod_http2 module. Administrators enable it using the Protocols directive in their configuration files, specifying h2 for HTTP/2 over TLS or h2c for clear-text HTTP/2. Because this module processes complex binary frames from client requests, any memory management error within it can lead to severe vulnerabilities like buffer overflows or use-after-free errors, which attackers can leverage to run malicious code.

Linux distributions often package Apache differently than the upstream project. For instance, Red Hat Enterprise Linux (RHEL) modifies the mod_http2 module to give each HTTP/2 stream its own memory allocator. This architectural change makes exploiting memory corruption flaws significantly harder, which is why Red Hat rates the issue as Important rather than Critical for RHEL 9 and 10. Other distributions like Debian and Ubuntu may ship closer to the upstream code, leaving them more exposed to the raw severity of the flaw.

Why it matters

For teams managing self-hosted infrastructure, this vulnerability represents a direct threat to server integrity. Since the attack requires no authentication, any publicly accessible Apache server with HTTP/2 enabled is a potential target. Compromise could lead to data theft, service disruption, or the server being used as a pivot point for further network attacks. The high CVSS score reflects the ease of exploitation and the total impact on confidentiality, integrity, and availability.

The situation is complicated by the varying status of fixes across different operating systems. While upstream Apache users can simply upgrade to 2.4.71, users of Debian stable branches or Amazon Linux may find themselves waiting for vendor-specific patches. Additionally, those using the archived standalone mod_h2 library have no official patch path, forcing them to rely on configuration workarounds that disable HTTP/2 entirely, potentially impacting performance for modern clients.

What you can do

  • Check your version: Identify if your Apache server runs between versions 2.4.55 and 2.4.70, or if you use mod_h2 2.0.8–2.0.42.
  • Verify HTTP/2 status: Review your configuration for the Protocols directive. If h2 or h2c is present, HTTP/2 is active.
  • Apply patches: Upgrade to Apache 2.4.71 immediately if you use upstream releases. For RHEL users, apply the specific mod_http2 packages listed in recent advisories.
  • Implement workaround: If you cannot patch immediately, edit your Apache config to remove h2 and h2c from the Protocols directive, effectively disabling HTTP/2 until a fix is applied.
  • Monitor vendor trackers: Keep an eye on Debian, Ubuntu, and Amazon Linux security trackers for upcoming patches, as some currently list no fix.
  • Review standalone modules: If you use the archived mod_h2 from GitHub, plan to migrate to the main Apache package or maintain a strict disablement of HTTP/2.

More news

All news