Apache 2.4.71 Closes a Critical HTTP/2 Flaw in mod_http2

On November 11, 2026, the Apache Software Foundation released Apache HTTP Server 2.4.71. Its main fix is CVE-2026-119618, a race condition in mod_http2, the module that lets Apache speak HTTP/2. Apache rates it critical. Someone who can open an HTTP/2 connection to the server, with no account and no help from a user, can corrupt the server's memory and, according to the advisories, run code inside the Apache process. Versions 2.4.55 through 2.4.70 are affected, along with releases 2.0.8 through 2.0.42 of the standalone mod_h2 module.

The flaw only matters where HTTP/2 is switched on, and in every default installation we tested it is off until someone turns it on. Where it is on, one configuration change closes the hole until a fixed package arrives. This article covers where each fix stands on November 12, how to tell in a minute whether a server is exposed, how to switch HTTP/2 off safely, and how to patch.

Where the Fix Stands on November 12

We confirmed the Debian, Ubuntu and AlmaLinux rows by installing Apache in fresh containers on the morning of November 12 and reading what the package manager offered. Debian has fixed the package only in unstable, as 2.4.71-1. The last apache2 update for every supported Ubuntu release was published on November 9, two days before the disclosure. Red Hat shipped its errata on the day of the release.

Ubuntu 22.04 needs a second look. Its package is Apache 2.4.52, which sits below the affected range, and a version check alone would call it safe. Canonical has backported newer HTTP/2 code into that package over the years, though, and the module inside reports itself as mod_http2 2.0.42, which is inside the affected range of the module. Treat 22.04 as exposed wherever HTTP/2 is on, until Canonical says otherwise.

What Goes Wrong

HTTP/2 lets a browser send many requests at once over a single connection. mod_http2 handles those requests on several threads, so one connection can have a worker thread busy on each request while the connection's own thread keeps reading new ones.

The bug sits in assign_headers(), the function that copies a request's HTTP/2 headers into the structure Apache's request handling works with. In one case, a request that carries a Content-Type header but whose body has already ended, Apache adds Content-Length 0. It wrote that value into the header table shared with the connection's thread, not into the request's own copy. Red Hat describes the result as a worker thread writing into memory owned by the connection thread through a shared allocator with no lock. When two threads change the same structure at the same moment, the heap is corrupted, and the advisories say that corruption can be turned into code execution.

That code runs with the rights of the web server user, www-data on Debian and Ubuntu and apache on Red Hat systems, not as root. It is still serious, since the web server user can read the site's code, its configuration files and any database passwords stored in them.

The fix is a single line in modules/http2/h2_request.c. Apache now writes that Content-Length into the request's own header table.

How Serious It Is

Apache rates CVE-2026-119618 critical. The National Vulnerability Database received the record on November 11 and has not scored it yet. Red Hat gives it a CVSS 3.1 score of 9.8, because the attack needs only network access, no login and no user action.

Red Hat lowers its own rating to Important for Red Hat Enterprise Linux 9 and 10. The mod_http2 builds there give every HTTP/2 stream its own allocator, which makes the race much harder to exploit. The flaw is still present in those builds, and they are patched. Red Hat Enterprise Linux 8 and older carry a mod_http2 older than 2.0.8, which does not contain the affected code.

On exploitation the sources differ, so here is what each one says. Red Hat's statement says public research has shown a reliable exploit against a default-configured server with mod_http2 enabled. Wiz wrote on November 11 that no exploit was available and that it had seen no attacks in the wild. The flaw was not in CISA's catalogue of known exploited vulnerabilities on the morning of November 12. Two separate teams found the bug, Anthropic on October 26 and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research on November 3. Now that the fix is public, the patch itself points to the faulty code, so it is sensible to act this week and not wait for a public exploit.

Is Your Server Exposed

Two things have to be true. The Apache version has to fall in the affected range, and the server has to actually offer HTTP/2. That means mod_http2 is loaded and h2 or h2c is listed in a Protocols directive. Red Hat states that servers serving only HTTP/1.1 are not affected.

The defaults are friendly here. In the official httpd Docker image, the LoadModule line for mod_http2 is commented out. On Debian and Ubuntu the module is installed but not enabled. Its own configuration file contains Protocols h2 h2c http/1.1, so the moment someone runs a2enmod http2, every site on the server offers HTTP/2 over TLS and h2c over plain HTTP. On AlmaLinux 9 and 10, which follow Red Hat Enterprise Linux, the module is loaded by default, but no Protocols line exists anywhere in the configuration, and Apache's built-in default is http/1.1 only. On cPanel, HTTP/2 comes from the optional ea-apache24-mod_http2 package, which cannot be installed together with the prefork or ITK MPM.

In practice, plenty of servers have HTTP/2 turned on, because hosting guides and tuning checklists recommend it. Check on the server itself.

# The Apache version (apache2 -v on Debian and Ubuntu, httpd -v on Red Hat)
apachectl -v

# Is mod_http2 loaded? Any output means yes
apachectl -M 2>/dev/null | grep -i http2

# Where is HTTP/2 offered? Look for h2 or h2c
grep -rni "^\s*Protocols" /etc/apache2 /etc/httpd 2>/dev/null

A Protocols line inside a VirtualHost overrides the global one, so read every line the grep returns, not just the first.

From the outside, curl shows what the server negotiates. Run it against Apache itself. If a CDN or proxy sits in front, the first command tests the proxy, so use the second form from the server.

curl -sI --http2 https://example.com/ | head -1
# "HTTP/2 200" means HTTP/2 was negotiated, "HTTP/1.1 200 OK" means it was not

curl -sI --http2 --resolve example.com:443:127.0.0.1 https://example.com/ | head -1

# h2c on plain HTTP
curl -sI --http2-prior-knowledge http://127.0.0.1/ | head -1

Behind a CDN or a Load Balancer

The attack needs an HTTP/2 connection to Apache itself. If Cloudflare, a load balancer or another proxy takes the visitor's connection and talks HTTP/1.1 to Apache, the visitor's HTTP/2 never reaches mod_http2. Two things undo that protection. One is a proxy set to speak HTTP/2 to the origin, such as Cloudflare's HTTP/2 to Origin setting or an AWS target group with the HTTP2 protocol version. The other is an Apache port that the internet can reach directly, around the proxy. Check both before you decide a server can wait.

Switch HTTP/2 Off Until the Patch Arrives

Browsers negotiate the protocol on every connection and fall back to HTTP/1.1 on their own, so switching HTTP/2 off does not break a site. Pages with many small files load somewhat slower. If a CDN serves your visitors, they keep HTTP/2 from the CDN anyway.

On Debian and Ubuntu, disable the module and reload.

sudo a2dismod http2
sudo apachectl configtest && sudo systemctl reload apache2

On any system, the alternative is to set the protocol list explicitly in the main configuration and remove h2 and h2c from every VirtualHost that lists them.

Protocols http/1.1

On cPanel, remove mod_http2 in WHM under EasyApache 4 and provision the profile. Then run the curl checks again. Each should now print HTTP/1.1.

Turning HTTP/2 off does nothing for the two smaller fixes in 2.4.71, covered below. It does take away the path to the critical one.

Patch

On Red Hat Enterprise Linux 9 and 10 the fix is already in the repositories. Update the module and restart Apache, since a restart loads the new module.

sudo dnf update mod_http2
sudo systemctl restart httpd
rpm -q mod_http2

AlmaLinux and Rocky Linux rebuild these errata and publish their own. Run the same update once dnf offers a mod_http2 newer than the one installed.

On Debian and Ubuntu, wait for the Debian Security Advisory or Ubuntu Security Notice that names CVE-2026-119618, then upgrade the apache2 packages and restart.

sudo apt update
sudo apt install --only-upgrade apache2 apache2-bin
sudo systemctl restart apache2
dpkg -l apache2-bin

Compare the installed version with the one in the advisory. Distributions backport fixes into their own version numbers, so a patched Debian or Ubuntu package will not say 2.4.71.

For containers built on the official image, pull httpd:2.4.71 or rebuild anything that starts FROM httpd:2.4, then redeploy. Images that install apache2 from Debian or Ubuntu need the distribution fix first. Servers built from source can move to the 2.4.71 tarball. Once a server is patched and the version is confirmed, HTTP/2 can go back on.

The Other Two Fixes in 2.4.71

CVE-2026-106023 is rated important. It is a NULL pointer dereference in mod_md, the module that obtains certificates from Let's Encrypt and other ACME providers inside Apache through MDomain directives. It triggers during request processing and crashes an Apache child process. It affects 2.4.30 through 2.4.70, and only servers that load mod_md.

CVE-2026-109163 is rated low. It is a one-byte stack buffer overwrite in mod_vhost_alias, a follow-up to CVE-2026-63292, and it affects only 2.4.69 and 2.4.70.

Neither depends on HTTP/2, so both are reasons to take the 2.4.71 update even on servers that never offered HTTP/2.

What This Means for Your Team

List every server that runs Apache, including the ones behind a CDN and the ones inside containers. For each, record the version and whether HTTP/2 is offered. Patch Red Hat Enterprise Linux 9 and 10 today. On Debian, Ubuntu, AlmaLinux and cPanel, switch HTTP/2 off wherever it is on, and set a reminder to install the distribution fix as soon as its advisory appears. Ubuntu 22.04 belongs on that list too, despite its older version number. Re-enable HTTP/2 only after the patched package is confirmed on the server.

Sources

• Apache HTTP Server 2.4 vulnerabilities, CVE-2026-119618
• NVD entry for CVE-2026-119618
• CVE record for CVE-2026-119618
• Red Hat CVE page for CVE-2026-119618
• Debian security tracker, CVE-2026-119618
• apache2 package publishing history on Launchpad
• The fix commit in Apache httpd
• Wiz, CVE-2026-119618 overview
• Apache mod_http2 documentation
• Apache Protocols directive
• cPanel EasyApache 4 change log
• CISA Known Exploited Vulnerabilities catalog