- Apache fixed CVE-2026-119618, a flaw in its HTTP/2 module that Wordfence and Red Hat link to remote code execution, in version 2.4.71 on November 11.
- Wordfence says WordPress, plugin and firewall updates cannot fix it, because the web server handles the connection first. Only the host or server administrator can patch.
- Ask your host whether Apache accepts HTTP/2 and whether the fix is installed. Disabling HTTP/2 is a stopgap if no fixed package exists.
Many WordPress owners keep their site safe by keeping WordPress safe. They update the core, the plugins and the themes, and they run a firewall plugin. A new Apache flaw shows where that habit stops. Some risk sits in a layer the owner cannot see, let alone patch.
What Apache fixed
Apache released HTTP Server 2.4.71 on November 11, 2026. It fixes CVE-2026-119618, a flaw in mod_http2, the module that serves HTTP/2 requests. Apache rates it critical. Red Hat characterises the flaw as a way for an anonymous outsider to run code remotely, provided HTTP/2 is switched on.
Wordfence, the WordPress security firm, published a guide for site owners. It reports that the affected Apache range starts at 2.4.55 and ends at 2.4.70. The separate mod_h2 add-on is also affected, from release 2.0.8 up to 2.0.42.
Two research groups reported the flaw. Apache credits Anthropic's OSS Scanner, which reported it on October 26. A second, independent report came on November 3 from Anthony Weems and Simon Scannell, who do vulnerability research at Google Cloud. Wordfence notes that October 26 is only the first report date Apache has published. It does not show when the flaw was first found.
Why your WordPress tools cannot help
Apache is the software that receives a visitor's connection. It does this before the request reaches PHP or WordPress. Wordfence warns that a successful attacker would gain the same rights as the web server itself. That could be enough to read or change sites and data stored on that machine.
The Wordfence firewall only sees traffic once PHP is running. That is later than Apache's handling of the HTTP/2 connection. Wordfence's conclusion is that the cure is an Apache or hosting-vendor update. Patching WordPress, its plugins, its themes or the Wordfence plugin does not touch Apache. The WordPress dashboard cannot confirm the Apache build either.
The lesson here is about where responsibility sits. A site owner can do everything right in the application and still depend on a layer someone else runs. On shared or managed hosting, that someone is the provider.
Who is actually exposed
Not every Apache server is affected. Apache's default protocol is HTTP/1.1. HTTP/2 must be switched on in the configuration. Wordfence says servers that never offer h2 or h2c through this module fall outside the flaw's reach.
Public HTTP/2 support also does not settle the question. Visitors may speak HTTP/2 to a CDN, a load balancer or nginx, which then talks to Apache in HTTP/1.1. Wordfence gives AWS load balancers as an example, because their default backend traffic is HTTP/1.1. So test the protocol on the Apache server itself. Also test any route that bypasses the front layer, including internal ones.
Version numbers can mislead too. Vendors can backport fixes, so a build labelled with an older number may be patched. As one example of vendor guidance, Wordfence cites CloudLinux. It has posted ways to check products and patched builds for several hosting setups.
What is known about exploitation
The evidence is mixed, and the sources are careful about it. One independent researcher has published a lab environment. In it, Apache 2.4.70 suffers corrupted memory and crashing worker processes. The same material runs control tests against 2.4.71 and against HTTP/1.1 alone. Those are the researcher's results. Wordfence reads the material as stopping short of showing an attacker running commands on the server.
Red Hat describes a dependable exploit as already shown by public research. Wordfence checked Red Hat's advisory and found no link to a demonstration of code execution. Wiz, in its November 11 article, knew of no attacks in the wild. Taken together, Wordfence finds nothing in these sources that proves a WordPress site has been taken over through this flaw.
What to ask and do
If you use shared or managed hosting, put two questions to your provider. First, does the Apache server behind your site offer h2 or h2c? Second, is the CVE-2026-119618 fix in the installed package? Wordfence also advises asking for confirmation that Apache was restarted once the update went in.
If your team runs its own servers, have it check four things:
First, the installed Apache and mod_http2 packages. Second, whether the module is loaded. Third, whether any reachable listener or virtual host offers h2 or h2c. Fourth, the fixed package in your operating system or control panel vendor's advisory.
If no fixed package exists yet, Wordfence says temporarily disabling HTTP/2 removes this attack path. Remove h2 and h2c from the configuration, restart Apache and confirm the origin no longer accepts HTTP/2. Re-enable it after the fix is installed. Keep a current backup of files and database too. A backup helps recovery but does not prevent this flaw.
A security budget can end up covering only the layer you can see. This flaw is a reminder to ask who owns the layers underneath, and to get the answer in writing.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wordfence.
