Apache HTTP/2 vulnerability: who’s exposed, and the h2 off switch

The Apache HTTP/2 vulnerability is a race condition, a bug where two parts of a program touch the same memory at the same moment without proper locking. HTTP/2 lets a browser send many requests at once over one connection, and Apache’s mod_http2 module hands those requests to separate worker threads.

Red Hat explains that a worker thread can scribble over memory owned by the connection thread, because both draw from a shared allocator that has no lock. Corrupted memory like that can be steered into running an attacker’s commands. Apache’s own advisory labels it a synchronization problem in a function called assign_headers() and rates it critical, a label the project keeps for flaws that allow remote code execution.

Here are the key facts in one place:

• CVE: CVE-2026-119618, rated critical by Apache.
• Affected: Apache HTTP Server 2.4 releases fifty-five through seventy, plus standalone mod_h2 builds from GitHub, versions 2.0 releases eight through forty-two.
• Fixed in: Apache HTTP Server 2.4 release seventy-one.
• Condition: HTTP/2 must be enabled with h2 or h2c in the Protocols directive.
• Red Hat score: 9.8 out of 10 (Critical in general, Important on RHEL 9 and RHEL 10).

The picture is mixed, and it is worth knowing why. Red Hat’s assessment says public research has shown a reliable exploit against a default setup with mod_http2 loaded, yet it neither names nor links that research. Security company Wiz said the same day that it knew of no available exploit and no attacks in the wild.

Apache’s advisory says nothing about active attacks either. So there is no confirmed exploitation right now. Still, Red Hat calls the risk critical and the fix is out, so treat this as urgent rather than a reason to panic.

Whether you are at risk depends on three things: your Apache version, whether HTTP/2 is on, and who built your Apache package.

• Servers serving only HTTP/1.1 are safe. Red Hat says plainly that a server that never speaks HTTP/2 is not vulnerable.
• Red Hat Enterprise Linux 8 and older are not affected. Their mod_http2 predates the vulnerable code.
• RHEL 9 and RHEL 10 are affected but harder to attack. Red Hat’s builds give each HTTP/2 stream its own memory allocator, so it downgrades the risk to Important. Fixed packages shipped November 11, for example mod_http2-2.0.26-7.el9_9.1 on RHEL 9.
• Debian and Amazon Linux have opened entries in their security trackers. Ubuntu had no tracker page when this flaw first surfaced.
• People who installed the standalone mod_h2 module are in the worst spot. No fixed mod_h2 release exists. Its GitHub release list stops at 2.0 release forty-two, the last affected version, and the repository was archived and made read-only on June 9.

One catch trips people up. Linux distributions often backport fixes, meaning they patch the code without bumping the version number. A server that still reports 2.4 release seventy could already be safe if your distribution shipped a patched package. Check your distribution’s advisory and package changelog rather than trusting the number alone.

The fix for most people is to install Apache HTTP Server 2.4 release seventy-one, or your distribution’s patched package, and restart. Start with machines reachable from the internet that have HTTP/2 enabled.

1. Find out whether HTTP/2 is on. Search your Apache configuration for the Protocols directive. If it lists h2 (HTTP/2 over TLS) or h2c (HTTP/2 over plain TCP), the module is active. The setting can live at the server level or inside a single VirtualHost, so check the main config and every virtual host file.
2. Check your version. Compare what your server reports with the affected range of 2.4 releases fifty-five through seventy. On a distribution build, look up the package version in that vendor’s advisory instead.
3. Update. If you compile Apache yourself, move to 2.4 release seventy-one from the project’s download page. If you use packages from Red Hat, Debian, Amazon Linux or another vendor, install the vendor’s patched package through your normal update tool.
4. Test before you restart. Apache’s apachectl script includes a configtest command that checks your configuration for syntax errors, so a typo does not take your site down.
5. Restart gracefully. The apachectl graceful option reloads Apache without cutting off visitors who are mid-request.

If you run several servers, a sensible order is to list everything facing the internet, try the fixed build on a staging copy, then roll it out and watch your apps for odd behavior.

No patch yet? The temporary workaround

Apache’s advisory offers no workaround. Wiz, in its analysis, suggests a stopgap for anyone who cannot update today: take h2 and h2c out of the Protocols directive so it reads Protocols http/1.1, then restart.

This switches your site back to HTTP/1.1, so visitors still reach you, just without HTTP/2. The same change is also the only protection available for people stuck on the abandoned standalone mod_h2 builds.

If you pay for shared hosting or a managed WordPress plan, you don’t control Apache yourself. Your host does. HTTP/2 is switched on at most hosting providers, so it is reasonable to send your host a short support message asking whether their servers have the 2.4 release seventy-one fix or a patched vendor package.

If you rent a bare VPS or cloud server, the job is yours. Don’t assume you are in the safe group: check the Protocols line in your configuration, then patch or switch HTTP/2 off.

This is not the first HTTP/2 scare this year. An earlier HTTP/2 flaw, CVE-2026-23918, was fixed in version 2.4 release sixty-seven on May 4. Anyone who stopped there, or who later updated to anything up to 2.4 release seventy, is still exposed to this new bug.

Version 2.4 release seventy-one also arrived only five days after 2.4 release seventy, which came out November 6. The new release fixes two smaller bugs as well: a mod_md crash rated important and a one-byte stack overwrite in mod_vhost_alias rated low.

The way the bug was found is a sign of the times. Anthropic’s OSS Scanner, a free service that uses the company’s AI models to scan open-source code, flagged it on October 26. Two researchers on Google’s Cloud Vulnerability Research team, Simon Scannell and Anthony Weems, sent in their own report in early November. About two weeks passed between the first report and the patch.