Data centre server racks with active equipment

Apache's critical HTTP/2 flaw: what CISOs should check before an exploit lands

On Wednesday 11 November the Apache HTTP Server Project released version 2.4.71, fixing a flaw it rates as critical. Tracked as CVE-2026-119618, it sits in mod_http2, the module that lets Apache speak HTTP/2, and it can lead to remote code execution. Red Hat scores it 9.8 out of 10 and says an attacker needs no login and no user interaction to exploit it.

Apache is one of the most widely used web servers in the world, and it turns up in places people forget about: old marketing microsites, internal portals, appliances and the web front ends of bought-in software. That is why this one matters to security leaders even before anyone has seen it used in an attack.

What has happened

The bug is a race condition. HTTP/2 lets a client send many requests over one connection, and Apache handles them on several threads at once. In one function, assign_headers(), those threads can write to shared memory without proper locking, which corrupts the server's memory. Apache's advisory says this "can lead to RCE".

The key facts so far:

Affected versions are Apache HTTP Server 2.4.55 to 2.4.70, plus the standalone mod_h2 module from 2.0.8 to 2.0.42. The fix is 2.4.71.
Only servers with HTTP/2 switched on are exposed. Red Hat is clear that servers serving only HTTP/1.1 are not vulnerable.
Two teams found it independently: Anthropic's OSS Scanner reported it on 26 October and Google Cloud Vulnerability Research on 3 November.
Wiz Research says 64% of cloud environments it sees have resources running a vulnerable version, and 51% have publicly exposed instances. Wiz notes those figures do not take configuration into account, so not all of them will have HTTP/2 enabled.
When Wiz published on 11 November there was no public exploit and no reports of exploitation in the wild. At the time of writing it is not in CISA's Known Exploited Vulnerabilities catalogue.

There is one line that should make CISOs move faster rather than slower. Red Hat's assessment says public research "has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled". No confirmed attacks yet does not mean there is time to wait for the next patch cycle.

Why it deserves attention now

Three things stand out.

First, the gap between disclosure and attack keeps shrinking. Two separate teams landed on the same bug within about a week of each other, which tells you it is findable. Once a bug is findable and the fix is public, attackers can compare the old and new code to work out what changed.

Second, the attack needs nothing from the victim. No phishing email, no stolen password. If an attacker can reach the server over HTTP/2, that is enough.

Third, an AI scanner was one of the two finders. That is good news for defenders, because these tools are finding serious flaws in widely used open source code before criminals do. It also means security teams should expect more critical fixes, more often, in software they rely on every day. Patching processes built for a few big fixes a quarter will struggle.

What to check today

1. Find out where Apache runs

Start with the inventory. Ask teams to list every Apache HTTP Server instance, including the ones bundled inside products and appliances. Do not forget containers and cloud images, where an old base image can quietly carry a vulnerable version.

2. Work out which ones speak HTTP/2

This is the question that shrinks the list. A server is exposed if mod_http2 is loaded and the Protocols directive includes h2 or h2c. Red Hat suggests a simple check from outside: a curl request with the --http2 option. If the first line comes back as HTTP/1.1, HTTP/2 is not in use on that endpoint. If it comes back as HTTP/2, it is.

Check each virtual host, because the setting can differ between them. If a load balancer or CDN sits in front and only passes HTTP/1.1 back to Apache, the internet may not reach mod_http2 at all, but it is worth confirming how each back end is set up.

3. Patch the internet-facing HTTP/2 servers first

Install 2.4.71 or your Linux distribution's fixed package. Red Hat says fixes are now available for most of its affected products, with the rest being expedited. Its RHEL 9 and RHEL 10 packages are rated Important rather than Critical, because the way they allocate memory makes the flaw much harder to exploit, and RHEL 8 and earlier are not affected. Other distributions will have their own advice, so check with each supplier.

For products that bundle Apache, ask the vendor for a fixed build and a date.

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

Both Wiz and Red Hat give the same temporary fix: set Protocols to http/1.1 only, removing h2 and h2c, then restart the web server. Browsers and API clients fall back to HTTP/1.1 without breaking. Red Hat notes that pages may load a little more slowly and use more bandwidth, which is a fair trade for closing the hole. Remember this is a stopgap. Version 2.4.71 also fixes two other flaws, so the update still needs to happen.

5. Watch for changes

Keep an eye on the CISA KEV catalogue and your suppliers' advisories. If exploitation is confirmed, any server still unpatched should be treated as possibly compromised and checked, not just updated.

Questions the board may ask

If the board or the executive team asks about this, it helps to have short answers ready:

How many Apache servers do we run, and how many have HTTP/2 enabled?
How many of those face the internet, and when will they be patched?
Which suppliers ship Apache inside their products, and have they confirmed a fix?
If an attacker did get in through a web server, what could they reach from there?

That last question matters most. A web server should not be a short route to the rest of the network. If it is, this flaw is a good reason to fix that too.

The bigger lesson

This week has already seen urgent fixes for SSH and for widely used business software. Critical flaws in core internet software are arriving faster, and some are now being found by AI tools as well as human researchers. The organisations that cope best are the ones that already know what they run, can tell quickly which systems are exposed, and have a tested way to patch or switch off a feature within hours, not weeks.

If you can answer "where does Apache run, and which of those speak HTTP/2?" in an afternoon, you are in good shape. If you cannot, that is the gap to close.