Apache HTTP2 CVE-2026-119618 Explained: Critical 9.8 RCE Flaw, Affected Versions and the 2.4.71 Fix

Image: Apache Software Foundation — Apache HTTP Server feather logo (official logo), via Wikimedia Commons, Apache License 2.0.

TL;DR: Apache HTTP2 CVE-2026-119618 explained: a critical flaw in Apache HTTP Server's HTTP/2 module can let a remote attacker run code on the server without logging in. It affects versions 2.4.55 to 2.4.70, but only where HTTP/2 is switched on. The fix is version 2.4.71, released 11 November 2026 — update now, or switch HTTP/2 off until you can.

Key Highlights

• CVE-2026-119618 is rated critical by Apache. A race condition in the HTTP/2 module (mod_http2) can corrupt server memory and lead to remote code execution — no username or password needed.
• Red Hat scores it 9.8 out of 10. The vendor says an attacker who can reach the server could take full control of the server process when HTTP/2 is enabled.
• Only HTTP/2 servers are exposed. Apache's default is HTTP/1.1, so servers that never switched HTTP/2 on are not affected by this flaw.
• The fix is Apache HTTP Server 2.4.71, released 11 November 2026. The same release also fixes a crash bug in mod_md and a buffer flaw in mod_vhost_alias.
• No attacks in the wild have been confirmed as of 12 November, and the flaw is not in CISA's Known Exploited Vulnerabilities list — but public crash-reproduction material already exists, so the patching window is short.

Apache HTTP2 CVE-2026-119618 explained: what the flaw is

Apache HTTP Server — the open-source web server behind a large share of the world's websites — shipped a critical security fix on 11 November 2026. The headline flaw, CVE-2026-119618, sits in mod_http2, the module that handles HTTP/2 connections. Apache describes it as a case of concurrent execution using a shared resource without proper synchronisation, inside the module's assign_headers() function. In plain terms: when several threads handle HTTP/2 requests at the same time, two of them can write to the same piece of shared memory without the locking that should keep them apart, corrupting the server's heap. Apache says that corruption "can lead to RCE" — remote code execution.

Two independent teams found the bug. Apache credits Anthropic's OSS Scanner, a free scanning service for open-source projects, which reported it on 26 October, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research, who reported the same flaw independently on 3 November. The fix landed in the 2.4.x branch and shipped as version 2.4.71 on 11 November — just five days after 2.4.70 was released.

One number needs care. Apache itself publishes no CVSS score — it rates the flaw "critical" in its own terms. The 9.8 score comes from Red Hat, which ships Apache as part of Red Hat Enterprise Linux and describes the issue as unauthenticated remote code execution when HTTP/2 is enabled. Red Hat also says public research has demonstrated a reliable exploit against a server in its default configuration with mod_http2 enabled, though it does not link to that research. Security firm Wiz, meanwhile, said on 11 November that no exploit was available and no exploitation in the wild had been reported. Wordfence, which reviewed the public material, reports that a researcher has published crash-reproduction test setups — servers crashing on 2.4.70 — but no public demonstration of code execution. So the honest position is: the code-execution risk is real and rated critical, but no confirmed attacks have been reported yet.

Which versions are affected?

The affected range is wide, because the bug has been present since version 2.4.55. Any Apache HTTP Server from 2.4.55 through 2.4.70 that serves HTTP/2 is in scope. The standalone mod_h2 module distributed on GitHub is also affected, from version 2.0.8 through 2.0.42 — and no fixed standalone release has been published so far. The Hacker News reports that the standalone project's repository has been read-only since it was archived on 9 June, so servers using that build cannot simply upgrade the module and need a different plan, such as moving to the bundled module in 2.4.71.

Component	Affected versions	Fixed in
Apache HTTP Server (mod_http2)	2.4.55 – 2.4.70	2.4.71 (11 Nov 2026)
Standalone mod_h2 (GitHub)	2.0.8 – 2.0.42	No fixed release published yet
mod_md (crash bug, CVE-2026-106023)	2.4.30 – 2.4.70	2.4.71 (11 Nov 2026)
mod_vhost_alias (buffer flaw, CVE-2026-109163)	2.4.69 – 2.4.70	2.4.71 (11 Nov 2026)

Version 2.4.71 fixes three flaws in total. Besides the critical HTTP/2 issue, it fixes CVE-2026-106023, an "important" NULL pointer dereference in mod_md — the module that manages TLS certificates automatically — which can crash child processes, and CVE-2026-109163, a "low" one-byte stack buffer overwrite in mod_vhost_alias. Both are worth taking even if you never enabled HTTP/2.

Vendor packages are moving at different speeds. Red Hat shipped fixed mod_http2 packages for Red Hat Enterprise Linux 9 and 10 on 11 November, and rates the flaw "Important" rather than "Critical" on those builds; RHEL 8 and earlier do not contain the vulnerable code at all. Debian had the fix only in its unstable branch as of 12 November, with its stable releases still listed as vulnerable, and Ubuntu had not shipped a fix yet, according to CloudLinux's tracker. If your server comes from an operating system or control-panel vendor, follow that vendor's advisory — the fixed build may carry a different version number from upstream 2.4.71.

Illustrative image: a data centre. Image: BalticServers, via Wikimedia Commons, CC BY-SA 3.0.

Why it matters for India readers

Apache is the workhorse behind a huge number of Indian websites. Shared hosting, cPanel hosts and WordPress sites in India commonly run on Apache, and HTTP/2 is frequently switched on by hosts because it makes pages load faster — which is exactly the configuration this flaw needs. Security firm Wiz reported that 64% of the cloud environments it looked at had resources identified as vulnerable, with 51% publicly exposed, a sign of how widely the affected versions are deployed.

For most Indian website owners, the practical point is that this is a server problem, not a website problem. Updating WordPress, its plugins or its themes will not fix it — the flaw sits in the web server software underneath, before a request ever reaches PHP or WordPress. If your site is on shared or managed hosting, only your host can patch Apache, so the fix starts with a message to them. If you run your own server, the update is yours to apply. And because the flaw needs no login, an unpatched HTTP/2 server is exposed to anyone on the internet who can reach it — there is no password standing in the way.

There is also a subtlety worth knowing before you panic or relax. A site can show HTTP/2 support in the browser while its Apache server is safe, because a CDN, load balancer or nginx box in front may terminate HTTP/2 while the Apache origin behind it receives only HTTP/1.1. What matters is the protocol at the Apache origin itself, including any direct or internal route to it — not the protocol your visitors see.

How to check and fix it

Start by finding out whether you are exposed at all. If you manage the server, check the installed Apache version and whether mod_http2 is loaded, then look at the Protocols directive in your configuration: HTTP/2 is on only where it lists h2 (HTTP/2 over TLS) or h2c (HTTP/2 over plain TCP). Servers that serve only HTTP/1.1 are not vulnerable, Red Hat confirms. If you are on shared or managed hosting, your dashboard cannot tell you this — ask your provider directly: "Does the Apache server hosting my site accept h2 or h2c, and has CVE-2026-119618 been fixed in the installed package?" Ask them to confirm Apache was restarted after the update, since a patched package only takes effect after a restart.

Then apply the fix in this order:

• Update Apache to 2.4.71, or install your operating system or control-panel vendor's fixed package, and restart Apache. That is the complete fix for the critical flaw and the two smaller bugs in the same release.
• If no fixed package is available yet, disable HTTP/2 temporarily. Remove h2 and h2c from the Protocols directive, leaving Protocols http/1.1, and restart Apache. Wiz and Wordfence both recommend this as the stopgap; re-enable HTTP/2 after the fixed package is installed.
• Check for the standalone mod_h2 module. If your server uses the GitHub-distributed mod_h2 (2.0.8–2.0.42), there is no fixed release to upgrade to — plan to move to the bundled module in Apache 2.4.71 or disable HTTP/2 in the meantime.
• Keep a current backup of your site files and database. A backup does not prevent the vulnerability, but it is what recovery depends on if a server is ever compromised.

Should you care?

✅ Yes — patch this week, today if you run the server yourself. A critical, no-login flaw in one of the internet's most widely used web servers, with a fix already released and crash-reproduction material already public, is the definition of a patch-now issue. If your host manages Apache, one message asking for its CVE-2026-119618 status is the whole job. If you run Apache yourself, update to 2.4.71 — or switch HTTP/2 off until you can. There is no confirmed exploitation yet, so this is a race you can still win.

FAQs

Is Apache HTTP Server vulnerable to CVE-2026-119618?
Versions 2.4.55 through 2.4.70 are vulnerable, but only when HTTP/2 is enabled through mod_http2. Servers running only HTTP/1.1 are not affected, and version 2.4.71 contains the fix. The standalone mod_h2 module versions 2.0.8 through 2.0.42 are also affected, with no fixed release published yet.

How do I check if my server has HTTP/2 enabled?
If you manage the server, check the Protocols directive in your Apache configuration — HTTP/2 is on if it lists h2 or h2c. If you use shared or managed hosting, ask your provider whether the Apache server accepts h2 or h2c and whether CVE-2026-119618 has been fixed. A public HTTP/2 check on your site is not enough, because a CDN or load balancer may handle HTTP/2 while Apache behind it does not.

How do I fix CVE-2026-119618?
Update to Apache HTTP Server 2.4.71, or install your vendor's fixed package, then restart Apache. If no fixed package is available for your system yet, remove h2 and h2c from the Protocols directive, leaving only http/1.1, and restart — that removes the attack path until the update can be applied. Updating WordPress, plugins or themes does not fix it.

Has CVE-2026-119618 been exploited in the wild?
No confirmed exploitation in the wild has been reported as of 12 November 2026, and the flaw is not in CISA's Known Exploited Vulnerabilities catalogue. Red Hat says public research has demonstrated a reliable exploit against a default configuration, while Wiz reported no exploit was available and no exploitation had been seen. Public material so far demonstrates server crashes, not code execution.

Takeaway

CVE-2026-119618 is a critical no-login flaw in Apache's HTTP/2 module affecting versions 2.4.55 to 2.4.70 — and the fix, 2.4.71, has been out since 11 November. Check whether your server runs HTTP/2, and get it patched or switched off before the window of no confirmed attacks closes.

If your site runs on Apache, check with your host today whether CVE-2026-119618 is fixed on your server — and if you run a server yourself, update to 2.4.71 now. For the week's other critical flaws, see our explainers on Red Hat Quay CVE-2026-123710, another 9.8 flaw disclosed this week, CERT-In's Chrome zero-day warning from earlier this week and Microsoft's November Patch Tuesday, which fixed over a thousand flaws.

Sources

Apache HTTP Server Project — Apache HTTP Server 2.4 vulnerabilities (CVE-2026-119618, CVE-2026-106023, CVE-2026-109163; fixed in 2.4.71, released 11 November 2026)
Apache HTTP Server Project — Apache HTTP Server 2.4.71 announcement
CVE.org — CVE-2026-119618 record
Red Hat — CVE-2026-119618 (CVSS 9.8, RHEL fixed packages)
Wordfence — PSA: Critical Apache HTTP/2 Vulnerability: What WordPress Site Owners Should Know (12 November 2026)
GBHackers — Apache HTTP Server Patches Critical RCE Vulnerability (12 November 2026)