Apache's HTTP/2 flaw: found twice in eight days, fixed in 2.4.71

Apache's web server got a critical fix on 11 November. The bug sits in the part that speaks HTTP/2, and it can let a stranger run their own code on the server without logging in. Two teams found it on their own, eight days apart, one of them a machine.

The bug in one minute

HTTP/2 lets one connection carry many requests at once, each in its own stream. Apache's mod_http2 handles those streams on several threads at the same time. In one function, assign_headers(), two threads can end up touching the same piece of memory without waiting for each other. Apache's advisory calls it "improper synchronization".

If an attacker times their requests well, one thread writes into memory that another thread is still using. That corrupts the server's heap, and corrupted memory is the classic way in for running your own code. Nothing about it needs a password or a special page. It only needs the server to accept HTTP/2.

Race conditions like this are hard to hit on purpose. That is why the scores differ: Red Hat gives it 9.8 out of 10 in general, but only "Important" on RHEL 9 and 10, because there each stream gets its own memory pool, which "substantially increases the complexity" of an attack.

Found twice in eight days

Apache credits two finders, and the dates are the most interesting part of the advisory:

• 26 October Anthropic's OSS Scanner, an automated tool that searches open-source code for bugs, reports it to Apache's security team.
• 3 November Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research report the same bug.
• 11 November Apache fixes it (commit 824beab) and releases 2.4.71 the same day. Debian ships a fixed package for Debian 13.

Two unrelated teams landing on the same race in one function within a week is the pattern OpenSSH warned about a week ago, when it rushed out its *sshole fix in a day: bugs are now being rediscovered fast, partly by AI tools, so keeping a known hole secret for long is risky. Here Apache took 16 days from the first report, and the second report came in halfway through.

A note on us: posts on this blog are written with help from Claude, which is made by Anthropic, the company whose scanner is credited above.

Are you affected?

The tricky part is the setting. HTTP/2 is off in a plain Apache install, and also in Debian's: we unpacked the fixed Debian package, and http2 isn't in the list of modules it switches on. But turning it on is one command, a2enmod http2, and Debian's file for it then sets Protocols h2 h2c http/1.1 for every site on the server, plain HTTP included. Many guides for faster websites tell people to do exactly that, and control panels often do it for you. So "default is safe" tells you little about a real server.

How many servers?

Nobody knows, and we won't guess. Apache runs about 20.9% of websites whose server software W3Techs can see, but that says nothing about which of them have HTTP/2 on. The cloud security company Wiz says 64% of the cloud environments it sees have resources with an affected version, and 51% have one reachable from the internet, but adds that this "does not take configuration into account". Those are cloud accounts, not servers, and they include servers with HTTP/2 off.

Pubblicità Prova Proton VPN oggi ›

Is there an exploit?

The sources disagree. Red Hat writes that "public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled". Wiz wrote at publication that "no exploit is available and there are no reports of exploitation in the wild", and other trackers found no exploit code. We couldn't find the research Red Hat refers to. What is clear: as of 12 November it is not on CISA's list of flaws known to be used in attacks, and nobody has reported one.

Don't wait for that to change. A fix that is public is also a map for attackers: comparing 2.4.70 with 2.4.71 shows exactly where the race is.

What to do

1. Find out if you run it. apachectl -v shows the version. apachectl -M | grep http2 shows whether the module is loaded, and grep -ri "^\s*Protocols" /etc/apache2 /etc/httpd shows where h2 or h2c is switched on.
2. Update and restart. On Debian 13: apt update && apt install --only-upgrade apache2 (fixed: 2.4.71-1~deb13u1), then systemctl restart apache2. On other systems, take your distribution's package when it arrives, or build 2.4.71.
3. Check the package, not only the number. Distributions often patch older versions without changing the version. On 12 November Debian 12's security archive already had 2.4.71-1~deb12u1, but Debian's tracker still listed Debian 12 as vulnerable, and Ubuntu hadn't published a notice yet. Check your distribution's own page for the CVE.
4. Can't update today? Switch HTTP/2 off: set Protocols http/1.1 (on Debian: a2dismod http2, and remove any other Protocols lines that list h2), run apachectl configtest, then restart. Your site keeps working, just over HTTP/1.1.
5. Don't count on a CDN. A service in front of your site only protects you if your server can't be reached directly from the internet.

The other two fixes

2.4.71 also fixes CVE-2026-106023, a crash in mod_md (the module that gets Let's Encrypt certificates), rated important, in 2.4.30 to 2.4.70. It takes down one worker process, not the whole server. And CVE-2026-109163, a one-byte overwrite in mod_vhost_alias in 2.4.69 and 2.4.70, rated low. The same update covers all three.

Why this is on Blackout Map

This is a software flaw, not an outage, and it won't show on our map. But broken memory in a web server has two possible endings: an attacker's code, or a crash, and a crash is an outage for everyone who wanted that site. Our Security watch tracks the flaws that are really being used. Read also Can a software flaw take the internet down?

Sources

• Apache HTTP Server 2.4 vulnerabilities (affected versions, finders, dates, all three CVEs)
• Apache httpd: the fix (824beab)
• Red Hat: CVE-2026-119618 (score, RHEL 9 and 10 rating, exploit statement)
• Debian security tracker: CVE-2026-119618 and DSA-6620-1
• Wiz: Critical RCE vulnerability in Apache HTTP Server (exploit status, cloud figures)
• CISA: Known Exploited Vulnerabilities catalog (not listed on 12 November)
• W3Techs: usage statistics of Apache