CVE-2026-119618: Apache 2.4.71 fixes unauthenticated HTTP/2 RCE

The Apache HTTP Server project released 2.4.71 on November 11, 2026, fixing CVE-2026-119618, a heap corruption bug in mod_http2 that Apache rates critical and says can lead to remote code execution. Red Hat scores it 9.8 under CVSS 3.1 with no authentication or user interaction required. Every Apache release from 2.4.55 through 2.4.70 is affected when HTTP/2 is turned on, which covers every upstream release since January 2023.

How the mod_http2 bug works

HTTP/2 lets a browser send many requests at once over a single connection. Apache's mod_http2 hands those streams to worker threads. According to Red Hat's analysis, a worker thread processing a stream can write into memory owned by the connection thread through a shared, lock-free allocator, inside the assign_headers() function. Two threads touching the same memory without a lock corrupts the heap, and a crafted sequence of requests can turn that corruption into code running as the Apache user.

Only servers that negotiate HTTP/2 are exposed. That means h2 (HTTP/2 over TLS) or h2c (cleartext HTTP/2) listed in the Protocols directive. A server that speaks only HTTP/1.1 is not vulnerable, even with the module loaded.

The bug was reported to Apache on October 26 by Anthropic's OSS Scanner, an AI-driven code auditing tool, and again on November 3 by Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research. The fix landed the same day as the release.

Affected versions and exploit status

• Apache HTTP Server 2.4.55 through 2.4.70.
• Standalone mod_h2 builds from GitHub, versions 2.0.8 through 2.0.42. That repository was archived in June and has no fixed release.
• Servers that upgraded to 2.4.67 in May for CVE-2026-23918, or to 2.4.69 in October for CVE-2026-57941, are still affected. Those were separate mod_http2 bugs.

Sources disagree on how close attackers are. Red Hat's statement says "public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled." Wiz's vulnerability entry lists no public proof-of-concept, no confirmed exploitation in the wild, and no CISA KEV listing as of disclosure. NVD had received the record on November 11 but had not scored it yet. We are treating it as exploitable.

The same release fixes CVE-2026-106023, a NULL pointer dereference in mod_md that crashes child processes (2.4.30 through 2.4.70, rated important), and CVE-2026-109163, a one-byte stack overwrite in mod_vhost_alias (2.4.69 and 2.4.70, rated low).

Distribution package status on November 12

• RHEL 9: fixed in mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981). Red Hat rates RHEL 9 and 10 Important instead of Critical because their builds give each HTTP/2 stream its own allocator, which makes exploitation much harder.
• RHEL 10: fixed in mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978). EUS and SAP streams for 9.4, 9.6, 9.8, 10.0 and 10.2 also have advisories.
• RHEL 6, 7 and 8: not affected. Their mod_http2 predates 2.0.8 and does not contain the code.
• AlmaLinux and Rocky Linux: these rebuild Red Hat's packages. AlmaLinux had not posted an erratum when we checked this morning.
• Debian 13 (trixie): fixed in apache2 2.4.71-1~deb13u1 (DSA-6620-1). A 2.4.71 build is in bookworm-security, but the tracker still listed Debian 12 as vulnerable.
• Ubuntu: no CVE page or USN yet. Ubuntu 24.04 ships 2.4.58 and 26.04 ships 2.4.66, both inside the affected range. Ubuntu 22.04 ships 2.4.52.
• Control panels that bundle their own Apache build, such as cPanel's EasyApache 4, publish on their own schedule. Check the vendor changelog for a 2.4.71 package.

Checking a server for HTTP/2 exposure

Confirm the Apache version and whether the module is loaded:

apachectl -v
apachectl -M 2>/dev/null | grep -i http2

Find every Protocols line. It can be set server-wide and per virtual host, and one stray vhost is enough:

grep -RniE '^\s*Protocols' /etc/apache2 /etc/httpd 2>/dev/null

Test what the server negotiates from outside. A result of 2 means HTTP/2 is live:

curl -so /dev/null -w '%{http_version}\n' --http2 https://www.example.com/

If a CDN or load balancer sits in front, that test shows the proxy, not Apache. Test the origin directly with --resolve www.example.com:443:ORIGIN_IP, and test cleartext h2c with curl --http2-prior-knowledge http://ORIGIN_IP/.

Patching, or disabling HTTP/2 until packages arrive

On RHEL 9 or 10:

dnf update mod_http2
rpm -q mod_http2
systemctl restart httpd

On Debian 13:

apt update && apt install --only-upgrade apache2
dpkg -l apache2 | tail -1
systemctl restart apache2

Use a full restart, not a graceful reload, so the parent process loads the new module.

Where no fixed package exists yet, which includes every Ubuntu release today, turn HTTP/2 off. Set this in the main config and in every vhost that has its own Protocols line:

Protocols http/1.1

On Debian and Ubuntu, a2dismod http2 removes the module entirely. On RHEL-family systems, comment out the LoadModule http2_module line in /etc/httpd/conf.modules.d/10-h2.conf. Then run apachectl configtest, restart, and repeat the curl test until it returns 1.1. Sites keep working over HTTP/1.1. Pages with many small assets load somewhat slower until HTTP/2 comes back.

Once a fixed package is installed, revert the change, confirm the curl test returns 2, and check the package version against the advisory list above. On servers Falcon Internet manages, HTTP/2 stays off on any host without a fixed package, and we turn it back on after the vendor update is installed and tested.