Apache HTTP/2 Flaw CVE-2026-119618: How to Check Your Servers and Patch to 2.4.71

A web server that talks HTTP/2 can be taken over by a stranger who never logs in. That is the risk behind CVE-2026-119618, a critical flaw in the Apache HTTP Server's HTTP/2 module, and the fix is already out.

Today is November 13, 2026. Apache released version 2.4.71 on November 11 to close this hole, and security teams are now asking the same question: are we actually exposed? The honest answer depends on more than a version number. It depends on whether HTTP/2 is switched on, whether your Linux vendor has already patched its package, and how traffic reaches Apache. This guide walks through all three, using Rohit, a system administrator at a company we will call Acme, as our example.

What happened, in plain words

HTTP/2 is a newer version of the web's main protocol. Its big idea is that many requests and responses can share one connection at the same time, which makes websites faster. In Apache, this feature comes from a module called mod_http2.

Sharing one connection means several parts of the server work at once, and they must be careful about who uses which piece of memory. According to Red Hat's technical assessment, that care broke down here. A worker thread (a part of the server handling one request) could write into memory owned by the connection thread (the part managing the whole connection) through a shared, lock-free memory allocator. The problem sits in a function called assign_headers(). When two parts write to the same memory without coordination, internal memory can get corrupted, and memory corruption is often the doorway to running an attacker's code.

Red Hat gives the flaw a CVSS v3.1 score of 9.8 out of 10. That score means the attack works over the network, needs no password and needs no help from a user.

Which versions are affected

Apache lists these ranges as affected:

• Apache HTTP Server 2.4.55 through 2.4.70.
• The separately released mod_h2 module from GitHub, versions 2.0.8 through 2.0.42.

The fixed release is Apache HTTP Server 2.4.71, or a vendor package that explicitly includes the fix.

Red Hat adds important detail for its own platforms:

• RHEL 8 and earlier are not affected, because the vulnerable code is not there.
• RHEL 9 and RHEL 10 are rated Important rather than Critical. Their HTTP/2 streams use separate allocators, which makes exploitation much harder. They still need the update, and Red Hat released fixes for several RHEL 9 and 10 streams on November 11.

What an attacker could actually get

Successful exploitation could give an attacker control of the web-server process. That is not automatically the same as full control of the machine. What the attacker can reach depends on what the Apache process can reach: the application's data, website folders it can write to, credentials stored in config files, and any backend services such as databases on the internal network.

So the damage on a well-isolated server running as a low-privilege user is smaller than on a server where Apache can read every secret on the box. This is a good moment to check that, too.

Is your server really exposed?

Here is where many teams get it wrong in both directions. A version number alone is not proof of danger, and a safe-looking public website is not proof of safety.

Loading the module is not enough. Luxembourg's CIRCL notes that the vulnerable path is only reachable when the service actually accepts HTTP/2. If mod_http2 is loaded but no listener offers HTTP/2, that path is not reachable.

Both kinds of HTTP/2 count. Encrypted HTTP/2 over TLS is called h2. Cleartext HTTP/2 without TLS is called h2c. Either one enabled on any listener matters.

Virtual hosts can differ. Apache lets you set protocols for the whole server and again for each virtual host. Reviewing only the main config file can miss one site that turns HTTP/2 on by itself.

Proxies change the picture. If a CDN, load balancer or reverse proxy sits in front and speaks HTTP/2 to visitors but only HTTP/1.1 to Apache, the outside HTTP/2 session does not by itself expose this bug. But direct access to the origin server, an internal listener, or a proxy that forwards HTTP/2 to Apache would.

Rohit's situation shows why this matters. Acme's main website sits behind a CDN, so a public scan shows HTTP/2 everywhere. Inside, he finds three cases: the main site's Apache only receives HTTP/1.1 from the CDN, an internal wiki is reached directly over h2, and one old marketing virtual host enables h2c on its own. Two of the three need urgent work, and the public scan would have told him nothing about them.

Step-by-step: what Rohit does today

Step 1: Find every Apache server and its version

List the servers, then check each one. The command name differs by distribution.

# RHEL, Rocky, Alma, Fedora
httpd -v
# Debian, Ubuntu
apache2 -v

Remember that vendors often fix a bug without changing the main version number (this is called backporting). Check the package against your vendor's advisory, not just the version string.

# RHEL family: is the fix for this CVE available or installed?
dnf updateinfo list --cve CVE-2026-119618
# Debian and Ubuntu: does the installed package mention the CVE?
apt changelog apache2 | grep -i CVE-2026-119618

Step 2: Check whether HTTP/2 is actually offered

First see whether the module is loaded, then search every config file for protocol settings, including virtual hosts.

# Is mod_http2 loaded?
apachectl -M 2>/dev/null | grep -i http2
# Where is HTTP/2 enabled? Look for h2 or h2c on any Protocols line
grep -RniE '^\s*Protocols' /etc/httpd/ /etc/apache2/ 2>/dev/null

Then test from outside and inside. --http2 asks for h2 over TLS, and --http2-prior-knowledge tries cleartext h2c. A result of 2 means HTTP/2 was used.

curl -s -o /dev/null -w '%{http_version}\n' --http2 https://app.example.com/
curl -s -o /dev/null -w '%{http_version}\n' --http2-prior-knowledge http://203.0.113.10/

Run these against the origin address and internal names too, not only the public website.

Step 3: Patch to 2.4.71 or the vendor's fixed package

Apply your vendor's update (or build 2.4.71 if you run Apache from source), then restart the service so the new code is really running. A reload is not always enough after a package update; a restart is the safe choice.

# RHEL family
sudo dnf update httpd mod_http2
sudo systemctl restart httpd
# Debian and Ubuntu
sudo apt update && sudo apt install --only-upgrade apache2
sudo systemctl restart apache2

Then repeat Step 1 to confirm the running build is the fixed one.

Step 4: If you cannot patch yet, switch HTTP/2 off

As a temporary measure, limit the protocol to HTTP/1.1. Put this in the main config and in every virtual host that sets its own protocols, removing any h2 and h2c entries:

Protocols http/1.1

Validate the config, apply it, and test again with the curl commands from Step 2. You want to see 1.1, not 2.

apachectl configtest && sudo systemctl reload httpd    # or apache2

On Debian and Ubuntu you can also disable the module with sudo a2dismod http2, followed by a restart. Expect slightly slower page loads for some visitors until HTTP/2 comes back after patching.

Step 5: Look for signs of earlier trouble

Patching closes the door, but it does not tell you whether someone walked through it first. CIRCL suggests reviewing unexpected Apache worker crashes, strange child processes, unauthorised file changes in web folders, and unusual outbound connections from the server. None of these prove an attack on their own, but each deserves a look.

About the exploit reports

Sources disagree, so read the headlines carefully. Red Hat says public research showed reliable exploitation against a default server with mod_http2 enabled. Wiz, on November 11, said no exploit was available and no attacks had been seen in the wild at that time. CIRCL notes that a demonstration does not prove attacks in the wild.

Wiz also reported that 64% of cloud environments in its own data contain resources vulnerable to this flaw. That figure describes Wiz's dataset, not the share of all Apache servers on the internet.

The safe reading: there is no confirmed attack campaign in these reports, but a working technique has been shown, so patch quickly.

Who found it, and what else 2.4.71 fixes

Apache credits Anthropic's OSS Scanner and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research. The timeline shows a report from Anthropic on October 26, a report from Google on November 3, and the fix and release on November 11.

Version 2.4.71 also fixes two smaller issues:

• CVE-2026-106023 (Important): a null-pointer dereference in mod_md that can crash a child process, in versions 2.4.30 to 2.4.70.
• CVE-2026-109163 (Low): a stack-buffer overwrite in mod_vhost_alias, in versions 2.4.69 and 2.4.70.

Conclusion

CVE-2026-119618 is serious: no login, network reachable, possible control of the web server. But real exposure depends on whether HTTP/2 or h2c is offered, on your vendor's package, and on how traffic reaches Apache. Find every server, check every virtual host, patch to 2.4.71 or the vendor fix, switch HTTP/2 off where you must wait, and then look back for signs of earlier misuse.

Merits

• The fix is already released, so there is a clear path to safety.
• HTTP/2 can be switched off with one config line as a stop-gap.
• RHEL 8 and older are not affected, and RHEL 9 and 10 are harder to exploit.
• A proxy that speaks only HTTP/1.1 to Apache reduces exposure.
• The review is a good chance to tighten what the Apache process can access.

Demerits

• The flaw needs no login and scores 9.8, so exposed servers are at real risk.
• Version strings can mislead because vendors backport fixes.
• Per-virtual-host settings make it easy to miss one exposed site.
• Turning off HTTP/2 can make some pages load a little slower.
• Patching does not reveal whether a server was attacked before the fix.

Caution

This article is educational. Host names, IP addresses and the company name Acme are placeholders and must be replaced with your own. Commands differ between distributions and versions, so read your vendor's advisory and test changes on a non-production server first. Claims about exploits and affected ranges come from the vendor and researcher statements summarised here and may change, so verify them against the official Apache and vendor advisories before you rely on them.

Frequently asked questions

• What is CVE-2026-119618? — It is a critical memory-corruption flaw in Apache HTTP Server's HTTP/2 module that can allow remote code execution without authentication.
• Which Apache versions are affected? — Apache HTTP Server 2.4.55 through 2.4.70, plus the separate mod_h2 module versions 2.0.8 through 2.0.42.
• Which version fixes it? — Apache HTTP Server 2.4.71, released on November 11, 2026, or a vendor package that explicitly includes the fix.
• Is my server safe if mod_http2 is loaded but HTTP/2 is not enabled? — The vulnerable path needs the service to accept HTTP/2, so a server that offers neither h2 nor h2c on any listener is not reachable through this flaw.
• Am I safe behind a CDN or load balancer? — Only if the proxy talks HTTP/1.1 to Apache and nobody can reach the origin server directly over HTTP/2.
• Is RHEL affected? — RHEL 8 and earlier are not affected; RHEL 9 and 10 are rated Important and should apply Red Hat's updates.
• How do I disable HTTP/2 in Apache temporarily? — Set Protocols http/1.1 in the main config and every virtual host, run a config test, then reload Apache.
• Is this flaw being exploited in the wild? — The reports cited here describe a public demonstration but no confirmed attacks in the wild, so patch quickly without assuming a campaign.

Tags

#apache #cybersecurity #cve2026119618 #http2 #modhttp2 #vulnerabilitymanagement #patchmanagement #linuxsecurity #webserver #devsecops