CVE-2026-119618: the Apache HTTP/2 flaw your WordPress updates cannot fix

On 11 November 2026 the Apache project released Apache HTTP Server 2.4.71 with a fix for CVE-2026-119618, a critical flaw in the module that serves HTTP/2. Red Hat's advisory describes the worst case in four words: unauthenticated remote code execution, on servers where HTTP/2 is enabled. Wordfence published the WordPress-side read of the disclosure the following morning; this piece is the hosting-side one, because that is where the whole story sits.

Here is the part every WordPress owner should sit with. The fix for this flaw does not exist anywhere in WordPress. Not in core, not in a plugin, not in a firewall extension, not in a settings screen. It lives one layer below the application, in the web server itself, in a package only the operator of that server can install and restart. Who that operator is decided your exposure before you had heard of the CVE.

What the flaw actually is

Apache's default protocol is HTTP/1.1, and HTTP/2 has to be enabled deliberately. When it is, the work is done by mod_http2, and the vulnerability sits in that module. Apache lists versions 2.4.55 through 2.4.70 as affected, along with standalone mod_h2 releases 2.0.8 through 2.0.42.

A server that never offers h2 or h2c through the affected module is not exposed to this particular flaw. An attacker who does exploit it runs code with the web server process's privileges, which puts every site and database that process can reach in scope. On a classic setup, that happens before PHP, WordPress or any application-layer firewall has been consulted at all.

Two research groups reported it to Apache independently: Anthropic's OSS Scanner on 26 October, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research on 3 November. The public evidence so far is a researcher's test setup showing memory corruption and Apache child-process crashes on 2.4.70. Wordfence, reviewing the public material, found no demonstrated remote command execution, and Wiz reported no known exploitation in the wild as of 11 November. Read that as timing, not safety. Working exploit code for this class of bug has a habit of arriving, and what decides who is exposed when it does is the patching record of whoever runs the server.

Why nothing in WordPress can patch it

Apache handles the connection before a request ever reaches PHP. Wordfence made the point directly: updating WordPress, plugins, themes or the Wordfence plugin itself does not patch Apache, because the Wordfence firewall runs at the PHP application layer, downstream of the connection handling where this flaw lives.

There is a second trap: version numbers do not answer the question. Distributors backport security fixes into older version strings, so a server reporting 2.4.58 may already carry the fix, and one reporting a newer number may not. Only the vendor's advisory for the installed package says. That is why the checklist below is about asking and verifying rather than reading numbers off a panel.

How to work out whether you are exposed

On shared or managed hosting, your dashboard will happily show the PHP version and nothing about the web server. Wordfence suggests the exact question to put to your host, and it is worth using verbatim because a host can either answer it precisely or not at all: 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, because a patched package with a stale process still serves from the old code.

If you manage the server yourself, check the installed Apache and mod_http2 packages, whether the module is loaded, and whether any listener or virtual host offers h2 or h2c, then follow your OS or control-panel vendor's advisory for the fixed build.

One nuance catches careful people: a public site can serve HTTP/2 through a CDN or load balancer while its Apache origin speaks HTTP/1.1, and AWS Application Load Balancers, for instance, talk HTTP/1.1 to backend targets by default. Exposure is decided at the origin, including any direct route that bypasses the edge, not by what the browser shows.

If no fixed package exists for your stack yet, the interim mitigation is to remove h2 and h2c from the configuration, restart Apache and verify the origin no longer accepts HTTP/2. Servers serving only HTTP/1.1 are not affected. Keep a current backup of files and database throughout; it does not prevent this class of compromise, it caps the cost of one.

The third deep-stack event in a month

Since late October this is the third critical flaw to land below the application layer. PHP's paired remote-code-execution bugs, disclosed in a rushed global release on 21 October, which we covered in the PHP2Shell timeline. A set of October Nginx security advisories. Now Apache's HTTP/2 module. Three different pieces of infrastructure with one property in common: their user is not the site owner. It is the host.

That is why these weeks keep turning into the same conversation. A flaw in a plugin, you patch the plugin. A flaw in the language runtime or the web server, the patch belongs to whoever holds root, and every site on that server inherits their patch discipline or the absence of it.

What a managed platform does while you sleep

Managed hosting earns its fee in weeks like this. On a platform like Cloudways the web server, the PHP runtime and the caching layers are operated by the platform, and the public status page shows what that means in practice, timestamps included. During October's PHP emergency, interim configuration-level mitigations went in across the fleet before the official patches finished rolling out, the rollout covered every supported PHP version plus deprecated ones back to 5.6 through ELTS partners, and when a regression surfaced days later, protections were already in place before the new issue had a CVE number. On 2 November an Nginx upgrade addressing the October advisories rolled across the fleet with millisecond restarts and a line worth reading twice: no action is required on your part.

As of publication there is no CVE-2026-119618 entry on that status page; the disclosure is a day old, and this article claims nothing about Cloudways and Apache beyond the pattern. The pattern is the argument: platform-level software gets patched by the platform, at fleet scale, on a schedule set by the platform's security team rather than by when the site owner next logs in. The customer's job in an incident week is to read the status email.

The same week on an unmanaged VPS reads differently. See the advisory, work out whether your configuration matches the vulnerable profile, find your distro's or CloudLinux's fixed build, schedule restarts across every server, verify the protocol at each origin, and repeat for the next advisory three weeks later. Both weeks are survivable. One of them is a job.

Disclosure: this site runs on Cloudways, and our Cloudways review carries an affiliate relationship. The incident record above comes from their public status page.

The question to answer before the next one

There will be another web-server CVE, and another after that, and the reliable predictor of how yours goes is not the flaw. It is who applies the patch. If the honest answer is "me, once I see it", the gap between the advisory and your login is the exposure, and it is worth closing on purpose rather than discovering it during an incident. The PHP2Shell timeline shows the same pattern at full scale, the realistic WordPress security checklist covers the layer you do control, and the Cloudways review prices the managed layer that handles the rest of the year.

Sources: the Wordfence write-up of CVE-2026-119618, the Apache HTTP Server vulnerability record, and the Cloudways status page incident history for every Cloudways event above.