If you run a web server, check what is answering your traffic today. Apache released version 2.4.71 yesterday, November 11, and the headline fix is a critical flaw in its HTTP/2 module, mod_http2. Tracked as CVE-2026-119618 and rated 9.8 out of 10, it can let a remote attacker run code on the server — no login, no password, nothing but the ability to reach the server.
What happened
Apache’s own advisory describes the bug as heap corruption in mod_http2, in a function called assign_headers, caused by concurrent execution using a shared resource without proper synchronization. In plain terms, the code handling HTTP/2 request headers can corrupt its own memory, and an attacker who understands that corruption can turn it into remote code execution.
The affected range is wide: Apache HTTP Server versions 2.4.55 through 2.4.70. If you run the project’s own releases, 2.4.71 is the fixed version. Standalone builds of the module, released on GitHub as mod_h2, are affected from version 2.0.8 through 2.0.42.
One condition matters more than any other: only servers with HTTP/2 enabled are affected, according to Red Hat, which ships this server in Red Hat Enterprise Linux. HTTP/2 only runs where the Protocols directive turns it on — h2 for HTTP/2 over TLS, h2c for HTTP/2 over plain TCP. That directive can be set server-wide or for a single virtual host, so you have to check every virtual host too.
The flaw was reported on October 26 by Anthropic’s OSS Scanner, a free scanning service for open-source projects. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research also reported it last week. The same release fixes two smaller issues: a crash in mod_md, rated important, and a one-byte overwrite in mod_vhost_alias, rated low.
How bad is it, honestly?
The honest answer is: serious, conditional, and not yet settled. Serious, because an unauthenticated remote code execution flaw in one of the most widely deployed web servers on earth is never a small thing. Red Hat says an attacker who can reach the server could take full control of the server process. Conditional, because a server that never enabled HTTP/2 does not carry this risk at all — and plenty of Apache installs still serve plain HTTP/1.1 only.
Not settled, because the two assessments I trust most disagree on exploitability. Red Hat’s assessment, published yesterday, says public research has demonstrated a reliable exploit against a default server with mod_http2 enabled — though it does not name or link that research. Security company Wiz said later that day that no exploit was available and no exploitation in the wild had been reported. Both cannot be fully true at once, and I am not going to pretend otherwise. I take the disagreement as a short clock, not a reason to relax.
Two more points keep this from being a panic. Red Hat rates the flaw Important rather than Critical on Red Hat Enterprise Linux 9 and 10, because its mod_http2 packages give each HTTP/2 stream its own memory allocator, which makes an attack much harder. Red Hat shipped fixes for those releases yesterday, and Red Hat Enterprise Linux 8 and earlier do not contain the vulnerable code at all. On the other hand, do not assume last spring’s update saved you: an earlier HTTP/2 flaw was fixed in 2.4.67 back in May, and every release from there through 2.4.70 is still inside the range this new bug affects.
The distribution picture is uneven. Debian’s unstable branch has the fixed package, while Debian bookworm and trixie were still listed as vulnerable with no fix when The Hacker News checked. Amazon Linux fixes were pending, and Ubuntu’s tracker had no page for the flaw. If you run a distribution build, your package number will not say 2.4.71 — check your vendor’s advisory for its own fixed package.
What to actually do
First, find out whether HTTP/2 is on. Search your Apache configuration — the main config and every virtual host — for the Protocols directive and look for h2 or h2c. If neither appears anywhere, note that, keep an eye out for your distribution’s normal updates, and move on.
Second, if HTTP/2 is on, update. Move project builds to 2.4.71, or install your distribution’s fixed package — on Red Hat Enterprise Linux 9, for example, the fix ships as an updated mod_http2 package listed in Red Hat’s advisory. Restart Apache afterward and confirm the running version, because an installed package that never got loaded protects nothing.
Third, if you cannot update right away, Apache’s advisory offers no workaround, but Wiz advises one that works: remove h2 and h2c from the Protocols directive, leaving Protocols http/1.1, until you can patch. Your site stays up. You lose HTTP/2’s performance benefits for a while, a far better trade than leaving a 9.8 open. This matters most for the standalone mod_h2 builds, which have no fixed release so far — for them, turning HTTP/2 off is currently the only move.
My bottom line: check the directive first, because it decides whether this is your emergency or somebody else’s. If your server answers h2 or h2c on a version in the affected range, patch today or turn HTTP/2 off until you can. With assessments already disagreeing about whether a reliable exploit is public, waiting for certainty is the one option I would not pick.
Sources: The Apache HTTP Server Project, “Apache HTTP Server 2.4 vulnerabilities” — CVE-2026-119618, fixed in 2.4.71, released November 11, 2026 — httpd.apache.org; The Hacker News, “Critical Apache HTTP/2 Flaw Could Let Unauthenticated Attackers Execute Code Remotely” (November 12, 2026) — thehackernews.com.