Apache HTTP Server: Critical HTTP/2 Flaw Can Let Attackers Run Code Remotely

Is your Apache server responding over HTTP/2? A critical flaw in the mod_http2 module could allow an unauthenticated attacker to execute remote code. Version 2.4.71 fixes the issue, but who can really benefit from it? Here's what you need to know.

On November 11, 2026, the Apache Foundation released a new version of its web server: Apache HTTP Server 2.4.71. This release fixes three security flaws, including CVE-2026-119618, a critical vulnerability. According to the security advisory, the flaw is located in the assign_headers() function of the mod_http2 module. It is associated with a race condition: multiple parallel operations modify the same memory region without coordinating. Depending on the order in which they run, that memory can be corrupted. In its report, Wiz notes that a remote, unauthenticated attacker can corrupt memory to execute code with the privileges of the web server process.

Apache HTTP Server versions 2.4.55 (released in January 2023) through 2.4.70 are affected, as well as mod_h2 versions 2.0.8 through 2.0.42, the standalone variant of the module distributed on GitHub. For a server to be vulnerable, the mod_http2 module must be loaded and HTTP/2 enabled via the Protocols directive, with either h2 (HTTP/2 over TLS) or h2c (cleartext HTTP/2).

It is worth noting that this vulnerability was reported on October 26, 2026 by Anthropic's OSS Scanner, a free AI-based open-source project scanning service. Anthony Weems and Simon Scannell from the Google Cloud Vulnerability Research team independently reported it on November 3. It was clearly meant to be found!

Public exploit or not? Red Hat and Wiz disagree

“Public research has demonstrated a reliable exploit”, Red Hat says on its dedicated vulnerability page, referring to a server using the default configuration with mod_http2 enabled. However, Red Hat, which assigns this flaw a CVSS score of 9.8 out of 10, does not specify which research it is referring to. Wiz, for its part, said on November 11 that no exploit was available and that no active exploitation had been reported.

Since then, a proof of concept (PoC) has been published on GitHub. It demonstrates memory corruption on version 2.4.70, and its absence on 2.4.71, but not code execution. On GitHub, the repository is particularly well documented, with technical details and information for reproducing the test environment. More to come.

How do you protect against CVE-2026-119618?

You need to upgrade to Apache HTTP Server 2.4.71, or to a package that includes the fix: Apache's advisory provides no workaround. In practice, you mainly depend on your distribution and on when that package becomes available:

• Red Hat Enterprise Linux 9 and 10: according to Red Hat, the fixes are delivered in packages mod_http2-2.0.26-7.el9_9.1 and mod_http2-2.0.29-5.el10_3.1. It is this package, separate from httpd, that you need to update before restarting httpd (check with rpm -q mod_http2, because httpd -v will not change version).
• Debian: according to the Debian security tracker, bookworm, trixie, and forky are vulnerable. The fix is available in the Trixie Security repository.
• Amazon Linux: patch pending for Amazon Linux 2, 2023, and 2027 Preview, according to Amazon Linux.
• Ubuntu: Canonical had not published any tracking page for this CVE.

I can confirm that the patch is available on Debian 13.

sudo apt list --upgradable
apache2-bin/stable-security 2.4.71-1~deb13u1 amd64 [upgradable from: 2.4.69-1~deb13u1]
apache2-data/stable-security 2.4.71-1~deb13u1 all [upgradable from: 2.4.69-1~deb13u1]
apache2-utils/stable-security 2.4.71-1~deb13u1 amd64 [upgradable from: 2.4.69-1~deb13u1]
apache2/stable-security 2.4.71-1~deb13u1 amd64 [upgradable from: 2.4.69-1~deb13u1]

In the meantime, Wiz recommends disabling HTTP/2. Check whether the module is loaded, then locate every occurrence of the Protocols directive (global and per VirtualHost):

sudo apachectl -M | grep -w http2_module
grep -Rni "Protocols" /etc/apache2/ /etc/httpd/ 2>/dev/null

Then remove h2 and h2c from each occurrence so that only this remains:

Protocols http/1.1

You can also disable the module directly so it is no longer loaded, using a2dismod http2 on Debian and Ubuntu. Clients will fall back to HTTP/1.1, which is an acceptable trade-off while you patch, even though there is currently no indication that this flaw is being exploited.

This article is also an opportunity to revisit previous and recent vulnerabilities patched in Apache2:

• May 2026 : the CVE-2026-23918 flaw, which allowed a denial of service with just two simple frames. Also, if you installed version 2.4.67 at the time, you were not in the clear: versions 2.4.67 through 2.4.70 are vulnerable to this new flaw.
• June 2026 : the HTTP/2 Bomb attack, capable of exhausting the RAM of an NGINX, Apache, or IIS server in under a minute.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio