Apache HTTP/2 Flaw CVE-2026-119618: What WordPress Site Owners Should Ask Their Host

What happened

On November 11, 2026, the Apache HTTP Server project released version 2.4.71 and published three security fixes. The most serious, CVE-2026-119618, is rated critical by Apache. Apache describes it as a concurrency bug in the assign_headers() function of mod_http2 that "can lead to RCE" (remote code execution). Apache lists Apache HTTP Server 2.4.55 through 2.4.70 as affected, plus standalone mod_h2 releases 2.0.8 through 2.0.42.

Apache credits two independent reports: Anthropic's OSS Scanner, which reported it on October 26, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research, who reported it on November 3. The NVD record was published on November 11 and was still awaiting NVD analysis when we checked on November 13.

Red Hat's advisory says a remote attacker who can reach the server could run commands without authentication, and that only servers with HTTP/2 enabled are affected. Servers that serve only HTTP/1.1 are not vulnerable to this flaw.

Is anyone exploiting it?

When Wiz published its analysis on November 11, it reported no public exploit and no reports of exploitation in the wild. Wordfence's November 12 PSA for WordPress site owners notes that a public researcher has posted a test setup that crashes Apache 2.4.70, but that the public material does not show code execution. As of November 13, the flaw is not on CISA's Known Exploited Vulnerabilities catalog. That can change quickly once details are public, so treat this as an update to do this week, not someday.

Why WordPress updates do not fix this

Apache sits in front of WordPress. It handles the connection before a request ever reaches PHP or WordPress. That means:

• Updating WordPress core, plugins, or themes does not change Apache.
• A WordPress security plugin firewall runs inside PHP, after Apache has already processed the HTTP/2 connection, so it cannot block this flaw. Wordfence says this directly in its PSA.
• Your WordPress dashboard can show the PHP version, but it cannot tell you which Apache build your host runs or whether HTTP/2 is enabled on it.

This is the same pattern we saw with the Brotli / HTTP2Shell issue and the October PHP security release: the risky code is in the server stack your host manages, not in WordPress itself.

Am I exposed?

Your site is only exposed if all of these are true:

1. The origin server runs Apache HTTP Server 2.4.55 through 2.4.70 (or a vendor build that has not backported the fix).
2. mod_http2 is loaded and Apache offers HTTP/2 (h2 or h2c in the Protocols directive) on a listener someone can reach.
3. The fixed package has not been installed, or Apache has not been restarted since.

Two cautions. First, Apache's own default protocol is HTTP/1.1, so HTTP/2 is only on if someone enabled it. Second, a site can show HTTP/2 in the browser because of a CDN, load balancer, or nginx in front, while the Apache origin behind it only speaks HTTP/1.1. The reverse can also be true if the origin is reachable directly. Exposure depends on the Apache origin's configuration, not on what the browser shows.

Version numbers alone can mislead. Linux distributions and control panel vendors often backport fixes without changing to 2.4.71. CloudLinux, for example, has published its own list of affected products and fixed builds, including EasyApache 4 on cPanel servers.

What to do now

If you use shared or managed WordPress hosting

• Check your host's status page or security announcements for CVE-2026-119618.
• If you cannot find a clear answer, ask: "Does the Apache server hosting my site accept HTTP/2 (h2 or h2c), and has CVE-2026-119618 been fixed in the installed package? Was Apache restarted after the update?"
• Keep the reply. If the host cannot answer, that is useful information about your hosting too.

If you or your developer manage the server

• Install Apache 2.4.71 or your operating system or control panel vendor's fixed mod_http2 package, then restart Apache.
• If a fixed package is not available yet, temporarily remove h2 and h2c from the Protocols directive (for example Protocols http/1.1) in the main config and any virtual hosts, restart Apache, and confirm the origin no longer accepts HTTP/2. Turn it back on after patching.
• Check every Apache origin, including staging servers and any direct or internal route that bypasses your CDN.

For everyone

• Confirm you have a recent, tested backup of both site files and the database, stored off the server. A backup will not prevent this flaw, but it is what you recover from if a server is ever compromised.
• Keep WordPress, plugins, and themes updated as usual. That is still your job, even though it does not fix this particular issue.

Where NTx fits

Most small business owners should not have to know which web server their host runs. But issues like this one are a good reason to know who is responsible for each layer of your site, and to have someone who can ask your host the right question and check the answer. Our WordPress Security and WordPress Maintenance work covers that, and if a site is already in trouble, WordPress Rescue is where we start.

FAQ

What is CVE-2026-119618?

It is a critical vulnerability in mod_http2, the HTTP/2 module of Apache HTTP Server. Apache says it can lead to remote code execution and affects Apache 2.4.55 through 2.4.70 and standalone mod_h2 2.0.8 through 2.0.42. Apache fixed it in version 2.4.71, released November 11, 2026.

Does updating WordPress fix CVE-2026-119618?

No. The flaw is in the Apache web server, which handles requests before WordPress or PHP run. Updating WordPress, plugins, themes, or a security plugin does not patch Apache. Your host or server administrator has to install the fixed Apache or mod_http2 package and restart Apache.

Is my WordPress site affected if my host uses nginx or LiteSpeed?

This specific flaw is in Apache's mod_http2. A server that does not run Apache with HTTP/2 enabled is not exposed to it. Some hosts run nginx in front of an Apache origin, so ask your host which server handles requests at the origin and whether that Apache accepts HTTP/2.

Can I turn off HTTP/2 instead of patching?

As a temporary step, yes. Red Hat says servers that serve only HTTP/1.1 are not affected. Removing h2 and h2c from Apache's Protocols directive and restarting Apache removes this attack path until the fixed package is installed. Re-enable HTTP/2 after patching.

Is CVE-2026-119618 being exploited?

As of November 13, 2026, it was not listed in CISA's Known Exploited Vulnerabilities catalog, and Wiz reported no known exploitation in the wild on November 11. A public crash test exists. Because details are public, patch soon rather than waiting for exploitation reports.

Sources

1. Apache HTTP Server, "Apache HTTP Server 2.4 vulnerabilities" (CVE-2026-119618, fixed in 2.4.71). https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2026-119618
2. NVD, CVE-2026-119618 detail. https://nvd.nist.gov/vuln/detail/CVE-2026-119618
3. CVE.org, CVE-2026-119618 record. https://www.cve.org/CVERecord?id=CVE-2026-119618
4. Red Hat, CVE-2026-119618 advisory. https://access.redhat.com/security/cve/cve-2026-119618
5. Wordfence, "PSA: Critical Apache HTTP/2 Vulnerability: What WordPress Site Owners Should Know" (November 12, 2026). https://www.wordfence.com/blog/2026/11/cve-2026-119618-apache-http2/
6. Wiz, CVE-2026-119618 analysis (November 11, 2026). https://www.wiz.io/blog/cve-2026-119618-rce-apache-http-server-vulnerability
7. CloudLinux, "Critical Apache mod_http2 flaw CVE-2026-119618". https://cloudlinux.com/security/critical-apache-mod-http2-flaw-cve-2026-119618-cloudlinux
8. oss-security mailing list, Apache advisory post (November 11, 2026). https://www.openwall.com/lists/oss-security/2026/11/11/13
9. Apache HTTP Server docs, Protocols directive. https://httpd.apache.org/docs/2.4/mod/core.html#protocols
10. CISA, Known Exploited Vulnerabilities catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog