Apache HTTP/2 vulnerability: critical flaw patched in 2.4.71. Here's what to check

On 26 October, an automated code scanner run by Anthropic flagged a bug deep inside the part of Apache HTTP Server that speaks HTTP/2. On 3 November, two Google researchers reported the same bug on their own. On 11 November, the Apache project shipped the fix in version 2.4.71 and rated the flaw critical.

The bug is tracked as CVE-2026-119618. Apache says it can lead to remote code execution, which means someone on the internet could make your web server run their commands. It affects Apache HTTP Server 2.4.55 through 2.4.70. Apache is one of the most common pieces of software behind websites, so this Apache HTTP/2 vulnerability is worth ten minutes of your morning even if you have never logged into a server.

How the Apache HTTP/2 vulnerability works

HTTP/2 is a faster way for browsers and servers to talk, and Apache handles it in a module called mod_http2. Apache describes the problem as a race condition: two parts of the server touch the same piece of memory at the same moment without taking turns, and that memory can get corrupted. According to SecurityWeek, Red Hat says an attacker could exploit it remotely without logging in, scored it 9.8 out of 10, and noted that "only servers that have HTTP/2 enabled are affected; servers configured to serve only HTTP/1.1 are not vulnerable."

The same release fixes two smaller bugs: CVE-2026-106023, rated important, which can crash server processes, and CVE-2026-109163, rated low.

What's confirmed versus unknown

Confirmed: Apache released 2.4.71 on 11 November with a fix for CVE-2026-119618, rated critical, affecting 2.4.55 to 2.4.70, and credits Anthropic's OSS Scanner and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research. SecurityWeek reports that Wiz found affected Apache versions in 64% of cloud environments it sees, with 51% exposed publicly, though Wiz cautioned that those figures ignore configuration, so they are not a count of exploitable servers. Wiz said that, when it published on 11 November, there was no exploit available and no reports of attacks. A public proof of concept on GitHub reproduces crashes but not code execution, SecurityWeek says.

Unknown or not yet stated in the sources: Red Hat says public research has shown a reliable exploit against a server with mod_http2 enabled, but its advisory does not say which research. Nobody in these sources reports attacks in the wild yet. That can change quickly once a fix is public, because attackers read patches too.

Three things to do today

1. Find out what web server your sites use. If you are on shared or managed hosting, ask your host plainly whether they run Apache 2.4.55 to 2.4.70 with HTTP/2 enabled, and when they will be on 2.4.71 or a patched vendor package.
2. If you run your own server, install Apache 2.4.71 or your Linux distribution's patched package. If you cannot update today, the reporting says turning off HTTP/2 temporarily blocks this flaw. Turn it back on after patching.
3. Agencies: list every client site you host or maintain on Apache, patch them in order of exposure, and send clients a short note about what you checked and when.

A next step

If a server was exposed and you later see strange processes, new admin accounts, or files you did not create, treat it as a possible breach. Our free guide What to do after a breach walks a small team through the first hours.