Apache HTTP/2 RCE CVE-2026-119618: check your server

If your Apache server speaks HTTP/2, patch it today. The Apache HTTP/2 vulnerability CVE-2026-119618 is a race in mod_http2 that Apache rates critical and says can lead to remote code execution. It affects 2.4.55 through 2.4.70 and is fixed in 2.4.71, released on 11 November 2026. Servers that only allow HTTP/1.1 aren’t exposed, and a one-minute check tells you which kind you run.

What Apache fixed in CVE-2026-119618

Apache’s security page for httpd 2.4 (updated 11 November 2026) titles it “mod_http2: heap corruption and RCE in assign_headers”. In plain terms, assign_headers() has improper synchronization of a shared resource, which means two pieces of work touch the same memory without the right locking. Apache rates it critical.

• Affected: Apache HTTP Server 2.4.55 through 2.4.70, plus the standalone mod_h2 module from GitHub, 2.0.8 through 2.0.42.
• Fixed: 2.4.71, released 11 November 2026 (commit 824beab).
• Found by: Anthropic’s OSS Scanner and, separately, Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research.

2.4.71 fixes two more bugs as well, so it is worth taking even if HTTP/2 is off. CVE-2026-106023 (important) is a NULL pointer dereference in mod_md that crashes a child process, affecting 2.4.30 through 2.4.70. The smaller one, CVE-2026-109163 (low), is a one-byte stack overwrite in mod_vhost_alias in 2.4.69 and 2.4.70.

Wiz’s write-up (11 November 2026) says the attacker can be remote and unauthenticated. At publication no exploit was public and no exploitation had been reported. By Wiz’s count, 64% of the cloud environments it sees have resources vulnerable to CVE-2026-119618 and 51% have publicly exposed instances. Wiz adds that this “does not take configuration into account”. That caveat matters, because an old version with HTTP/2 switched off isn’t the same risk as one serving h2 to the internet.

Timeline

Date (2026)	What happened
26 Oct	Anthropic reports the bug to the Apache security team
3 Nov	Google Cloud Vulnerability Research reports it independently
11 Nov	Fix committed (824beab), Apache 2.4.71 released, advisory published
11 Nov	Wiz publishes its analysis and exposure figures
12 Nov	Debian’s tracker lists DSA-6620-1 with trixie fixed; bookworm still marked vulnerable

Who the Apache HTTP/2 vulnerability actually reaches

Only servers that let clients negotiate HTTP/2. Apache’s Protocols directive defaults to Protocols http/1.1, and HTTP/2 only turns on when a config adds h2 (HTTP/2 over TLS) or h2c (HTTP/2 over plain HTTP). Red Hat’s page says servers using HTTP/1.1 only are not vulnerable.

What catches people is how easily h2c sneaks in. On Debian, a fresh install of the apache2 package doesn’t enable mod_http2 (its postinst script enables a fixed list that doesn’t include it). But once someone runs a2enmod http2, the packaged http2.conf sets Protocols h2 h2c http/1.1. That turns on h2 for TLS vhosts and h2c on port 80, often without anyone deciding they wanted cleartext HTTP/2.

Distro status on 12 November

Distro packages carry their own version numbers and often backport fixes, so apache2 -v alone can mislead you. Check the package against your distro’s tracker.

Distro	Status on 12 Nov 2026
Debian 13 trixie	Fixed in trixie-security 2.4.71-1~deb13u1 (DSA-6620-1), per the Debian tracker; the main trixie suite still shows 2.4.68
Debian sid	Fixed in 2.4.71-1 (forky still on 2.4.69, vulnerable)
Debian 12 bookworm	Listed as vulnerable (2.4.68-1deb12u1, security 2.4.67-1deb12u3), no DSA or DLA yet
RHEL 8 and earlier	Not affected, per Red Hat
RHEL 9 and 10	Rated Important rather than Critical by Red Hat; the page showed no fix state for these releases
Ubuntu	No Ubuntu CVE page for this ID yet (checked 12 Nov)

Red Hat scores the CVE 9.8 and explains the lower RHEL 9 and 10 rating. Their mod_http2 packages give each HTTP/2 stream its own allocator, which Red Hat says makes exploitation substantially harder. It doesn’t make it impossible, so patch when the package lands.

Check your server in a minute

Run these on the box first, then the outside test.

1. Version and package.

apache2 -v          # Debian, Ubuntu
httpd -v            # RHEL, Alma, Rocky, source builds
dpkg -l apache2     # Debian, Ubuntu package version
rpm -q httpd mod_http2

Upstream builds want 2.4.71 or later. For distro packages, compare the package version with the tracker table above.

2. Is mod_http2 loaded?

apache2ctl -M | grep http2    # Debian, Ubuntu
apachectl -M | grep http2     # RHEL family

No http2_module line means HTTP/2 can’t be negotiated, and this CVE isn’t reachable on that server.

3. Which protocols are on?

grep -Rni "^\s*Protocols" /etc/apache2 /etc/httpd 2>/dev/null

Look at the main config and every vhost. A vhost that sets its own Protocols line overrides the server-wide one, which is easy to miss.

4. Confirm from outside. This is the check that settles it, because it asks the server what it really negotiates.

curl -sI --http2 https://your-host/ -o /dev/null -w '%{http_version}\n'
curl -sI --http2 http://your-host/ -o /dev/null -w '%{http_version}\n'
curl -sI --http2-prior-knowledge http://your-host/ -o /dev/null -w '%{http_version}\n'

Per the curl manual, each line tests a different path:

• --http2 on HTTPS negotiates HTTP/2 in the TLS handshake.
• --http2 on plain HTTP tries the Upgrade: header, which is the h2c path.
• --http2-prior-knowledge speaks HTTP/2 directly without the upgrade step.

http_version prints the version curl actually used. A 2 from any line means HTTP/2 is reachable there, while 1.1 everywhere means it isn’t. Run it against the origin’s own address too, not only the public hostname.

Fix the Apache HTTP/2 vulnerability, or switch HTTP/2 off

Apache 2.4.71, or your distro’s fixed package, closes the Apache HTTP/2 vulnerability. For a standalone mod_h2 build, upgrade past 2.0.42.

If you can’t patch yet, Wiz’s stopgap is to remove h2 and h2c so only HTTP/1.1 is left:

Protocols http/1.1

Put it in the main config and change every vhost that has its own Protocols line. Then test and reload:

apachectl configtest && apachectl graceful

Re-run the curl checks. They should all print 1.1. Clients fall back to HTTP/1.1 and lose multiplexing until you patch.

A CDN or reverse proxy in front changes less than you’d think

A CDN or nginx in front doesn’t make an origin with the Apache HTTP/2 vulnerability safe by default. It only reduces exposure if all three of these hold:

• The front terminates HTTP/2 and talks HTTP/1.1 to Apache.
• It doesn’t pass an h2c Upgrade through to the origin.
• Nobody can reach the origin directly.

That first condition is often false. Cloudflare’s docs on HTTP/2 to origin (updated 14 August 2026) say it is enabled by default on every plan, and that Cloudflare only falls back to HTTP/1.1 when the origin doesn’t support HTTP/2. nginx works the other way round. Its proxy module docs give proxy_http_version 1.1 as the default since 1.29.7 (1.0 before that), and say the client’s Connection header isn’t passed upstream by default. So nginx in front speaks HTTP/1.x to Apache unless someone set proxy_http_version 2.

Check the third condition yourself. If the origin’s IP answers on 443 or 80 from the internet, the front is irrelevant and an attacker can talk to Apache directly. Firewall the origin to the front’s address ranges, or keep it on a private network.

Scraper backends, result APIs and self-hosted dashboards behind Apache are easy to miss here, because a scraping architecture often has several of them, each set up once with a CDN or nginx added later. Keep the two kinds of proxy apart. A reverse proxy sits in front of your own Apache, while the residential proxies your scrapers send requests through change the IP a target sees. Only patching protects the Apache box that stores and serves your results.

What to do now

List every Apache you run, including the ones in containers and behind other proxies, and run the four checks on each. Patch to 2.4.71 or the fixed distro package, with Protocols http/1.1 as the stopgap where you can’t yet. Then firewall each origin to its front, because a reachable origin IP undoes whatever the CDN or proxy does.