Is your Apache server affected by CVE-2026-119618? How to check and fix the HTTP/2 flaw

What is CVE-2026-119618, and how serious is it?

CVE-2026-119618 is a critical flaw in mod_http2, the HTTP/2 module of Apache HTTP Server. Apache describes it as a concurrency flaw with improper synchronization in the assign_headers() function, which corrupts the heap and can lead to remote code execution ^[1]. The Apache Project fixed it in release 2.4.71 on 11 November 2026 ^[1].

Red Hat gives the flaw a CVSS 3.1 base score of 9.8 and rates it Critical, with no authentication needed ^[2]. For RHEL 9 and RHEL 10 it lowers the rating to Important, because each HTTP/2 stream there uses its own memory allocator, which makes exploitation harder ^[2].

Red Hat explains the root cause in plain terms. HTTP/2 lets a client send many requests at once over one connection, and mod_http2 handles them on several threads ^[2]. A worker thread writes into memory owned by the connection thread, through a shared allocator with no lock, and that corrupts the server's memory ^[2]. The result is remote command execution without logging in ^[2].

Which Apache versions are affected?

Apache HTTP Server 2.4.55 through 2.4.70 are affected, and 2.4.71 is the fixed release ^[1]. The standalone mod_h2 module from GitHub is affected from 2.0.8 through 2.0.42 ^[1]. Red Hat says mod_http2 builds before 2.0.8 do not contain the faulty code, so RHEL 8 and earlier are not affected ^[2].

Treat the version range as a first filter, because distribution builds can defeat it. PrivateDevOps reports that Ubuntu 22.04 ships Apache 2.4.52, below the range, but its backported module reports itself as mod_http2 2.0.42, which is inside the affected module range, so a version check alone would call it safe ^[6]. Ubuntu's own notice lists 20.04 and 22.04 as affected ^[4]. On those releases, treat the server as exposed wherever HTTP/2 is on ^[6].

Version alone does not make a server exposed either. Red Hat states that only servers with HTTP/2 enabled are affected, and that servers configured to serve only HTTP/1.1 are not vulnerable ^[2].

Is my server exposed?

You are exposed when all of these are true ^[5]:

• You run Apache 2.4.55 through 2.4.70, an RHEL 9 or 10 mod_http2 build older than the fixed one, or an Ubuntu build with an affected backported module.
• The mod_http2 module is loaded.
• HTTP/2 is turned on through a Protocols line that lists h2 for TLS or h2c for plain HTTP.
• Untrusted clients can reach that listener, directly or through a proxy that forwards HTTP/2 to Apache.

Defaults help here. In the official httpd Docker image the LoadModule line for mod_http2 is commented out, and on Debian and Ubuntu the module is installed but not enabled ^[6]. The Debian and Ubuntu config file does contain Protocols h2 h2c http/1.1, so running a2enmod http2 switches HTTP/2 on for every site ^[6].

How do I check my server in five minutes?

Run three checks on the server. The commands are from Ostorlab's write-up ^[5]. First, read the version and see whether mod_http2 is loaded. On Debian and Ubuntu:

apache2 -v
apache2ctl -M | grep http2

On RHEL, Fedora and other RPM distributions:

httpd -v
httpd -M | grep http2

Then look for h2 or h2c in any Protocols line:

grep -R "Protocols" /etc/apache2 /etc/httpd 2>/dev/null

If the module check prints nothing, mod_http2 is not loaded and you are not exposed. If it prints a line, read every Protocols match, because a Protocols line inside a virtual host overrides the global one ^[6].

To see what the server really negotiates, use curl. If a CDN or proxy sits in front, run the second form on the server itself, so you test Apache and not the proxy ^[6].

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

An answer of HTTP/2 200 means HTTP/2 was negotiated, and HTTP/1.1 200 OK means it was not ^[6]. Those two commands test HTTP/2 over TLS only. If you serve h2c on plain HTTP, test it separately ^[6]:

curl -sI --http2-prior-knowledge http://127.0.0.1/ | head -1

Each hostname and virtual host can differ, so repeat the test for each one. For a container, check the running process, not a freshly pulled image: docker exec <container> apache2 -v on Debian-based images, or httpd -v on the official httpd image ^[5].

Why can the version number mislead?

Distributions backport fixes into their own version numbers, so a patched Ubuntu or RHEL package may not say 2.4.71 ^[5]. On RHEL the problem is sharper: httpd -v still reports the base 2.4 release after the fix, because the update changes the mod_http2 package ^[5]. Check the package instead:

rpm -q mod_http2

Compare the result with the fixed builds in the table below. On Ubuntu, compare the installed apache2 version with the one named in your release's notice ^[5]. Debian's fixed builds do carry the upstream number, 2.4.71-1deb12u1 and 2.4.71-1deb13u1 ^[3].

Which distributions have a fix as of 13 November 2026?

Patch status moves fast. On the morning of 12 November, PrivateDevOps found Debian 12 and 13 still vulnerable ^[6], and the Debian tracker now lists fixed builds ^[3]. The AlmaLinux and cPanel rows carry their own dates and may have changed since.

Distribution	Status	Source
Debian 12 bookworm	Fixed in the security suite: 2.4.71-1~deb12u1	Debian tracker [3]
Debian 13 trixie	Fixed in the security suite: 2.4.71-1~deb13u1	Debian tracker [3]
Debian forky (testing)	Listed as vulnerable at 2.4.69-1; sid has 2.4.71-1 fixed	Debian tracker [3]
Ubuntu 20.04, 22.04, 24.04, 26.04, 26.10	Update notice USN-9090-1 published 12 November	Ubuntu [4]
RHEL 9.9	Fixed in mod_http2 2.0.26-7.el9_9.1	Ostorlab [5]
RHEL 10.3	Fixed in mod_http2 2.0.29-5.el10_3.1	Ostorlab [5]
RHEL 8 and earlier	Not affected	Red Hat [2]
AlmaLinux 9 and 10 (12 November)	No fixed mod_http2 in the repositories	PrivateDevOps [6]
cPanel EasyApache 4 (12 November)	Moved to 2.4.70 on 11 November, still affected	PrivateDevOps [6]

Ubuntu's notice names this CVE as affecting 20.04, 22.04, 24.04, 26.04 and 26.10 ^[4]. The cached copy of the notice shows no package versions, so open USN-9090-1 for the version that applies to your release, then compare it with the output of dpkg -s apache2. Red Hat points to an affected packages table for each of its products, so check it if you are not on 9.9 or 10.3 ^[2].

How do I fix it?

Update the package, then restart Apache so it loads the fixed module ^[6]. Ostorlab and PrivateDevOps list these commands ^[5][6]:

On Debian and Ubuntu:

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

On RHEL, Fedora and clones:

sudo dnf update httpd mod_http2
sudo systemctl restart httpd

If you build from source or use the upstream tarball, move to 2.4.71, which carries the fixed module ^[5]. A standalone mod_h2 build from GitHub is a separate case: PrivateDevOps reported no fixed release on 12 November, with 2.0.42 the newest, and advised switching HTTP/2 off ^[6].

What if my distribution has no package yet?

Turn HTTP/2 off until the fix arrives. Ostorlab calls this a workaround, not a fix, and says the patched module is the durable answer ^[5].

• On Debian and Ubuntu, run sudo a2dismod http2, then sudo apachectl configtest && sudo systemctl reload apache2 ^[6]. Also remove h2 and h2c from every virtual host that lists them ^[6].
• On RHEL and Fedora, comment out the LoadModule http2_module line, make sure Protocols does not list h2 or h2c, and restart httpd ^[5].
• On any system, a second route is to set Protocols http/1.1 explicitly in the main configuration ^[6].
• On any system, confirm the module is gone with apache2ctl -M | grep http2 or httpd -M | grep http2. No output means HTTP/2 is off ^[5].

Apache's own advisory lists no workaround, so these steps come from the Ostorlab write-up, not from the Apache Project ^[1][5].

Does a CDN or reverse proxy protect me?

Often, but not always. The attack needs an HTTP/2 connection to Apache itself, so a CDN or load balancer that speaks HTTP/1.1 to your origin keeps the visitor's HTTP/2 away from mod_http2 ^[6]. Two things undo that. One is a proxy set to use HTTP/2 to the origin, such as Cloudflare's HTTP/2 to Origin setting or an AWS target group with the HTTP2 protocol version ^[6]. The other is an Apache port that the internet can reach directly ^[6]. The proxy can also be affected if it runs an affected Apache build ^[5].

Is there a public exploit?

Red Hat says public research has demonstrated a reliable exploit against a default-configured server with mod_http2 enabled, and it does not name that research ^[2]. Ostorlab says no public exploit code is linked and no use in the wild is known, and that the CVE was not in CISA's Known Exploited Vulnerabilities catalog as of 12 November 2026 ^[5]. The two statements can both hold, so assume the flaw is exploitable.

Apache rates it critical and the fix has been public since 11 November ^[1], so patch or disable HTTP/2 now instead of waiting for a confirmed attack.

How do I look for signs of an attack?

Start with crashes. Ostorlab suggests searching the Apache error log for segfaults and unexpected child exits, especially on servers that had HTTP/2 exposed before you patched ^[5]. The log path is /var/log/apache2/error.log on Debian and Ubuntu and /var/log/httpd/error_log on RHEL ^[5].

grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/apache2/error.log
coredumpctl list apache2

Use httpd in place of apache2 on RPM-based systems. Ostorlab adds that a crash is a lead and not proof of exploitation, because other bugs and resource limits can also kill a worker process ^[5]. A clean log does not prove the server was safe, because a successful exploit can leave no trace beyond the corrupted memory it used ^[5]. If you find repeated crashes on an exposed server, copy the logs and any core dumps off the host before you restart or rebuild it, and treat it as a possible incident.

Does Apache 2.4.71 fix anything else?

Yes. Release 2.4.71 carries three CVEs: one critical, one important and one low ^[1]. The important one, CVE-2026-106023, is a NULL pointer dereference in mod_md that can crash a child process, and it affects 2.4.30 through 2.4.70 ^[1]. mod_md is a different module from mod_http2, so turning HTTP/2 off as a stopgap does not address it ^[6]. Ubuntu's notice for the same release bundles several Apache fixes, so updating the package picks all of them up at once ^[4].

Who found the flaw?

Apache credits two finders. Anthropic's OSS Scanner reported it on 26 October 2026, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it on 3 November 2026 ^[1]. Red Hat's page thanks the two Google researchers and does not mention Anthropic ^[2]. The upstream fix is commit 824beab on the 2.4.x branch ^[1].