WordPress, PHP or the web server: which layer needs the patch?

On November 11, 2026, the Apache HTTP Server project released httpd 2.4.71. It fixes CVE-2026-119618, which Apache rates critical: a flaw “in Apache HTTP Server’s mod_http2 in assign_headers() can lead to RCE”, affecting httpd 2.4.55 through 2.4.70. Apache credits Anthropic’s OSS Scanner and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research with finding it.

It is the fourth critical bug under WordPress sites we have written about this year, and the four sat in three different layers:

Only the first of those shows up in the WordPress dashboard. For each layer, here is who ships the fix, how to check it yourself, and where serving a static copy from someone else’s patched edge helps and where it doesn’t.

Layer 1: WordPress core

Who ships the fix: the WordPress security team. Both core bugs this year came with fixed releases for older branches too, and wp2shell was serious enough that WordPress.org “enabled forced updates via the auto-update system”.

How to check: Dashboard → Updates on each install, or wp core version from the command line, compared against the fixed release for your branch. Do it for staging and the installs nobody logs into.

Where a static copy helps: this is where static delivery does the most. Both bugs were reached through ordinary HTTP requests that WordPress itself answered: a REST API batch route for wp2shell and a front-end page lookup for the traversal. When the public site is pre-rendered HTML on a host that runs no WordPress, those requests have nothing to answer them.

Where it does not: the WordPress origin, where editors work and builds are generated, still runs the vulnerable code until you update it.

Layer 2: the PHP interpreter

Who ships the fix: whoever supplied your PHP. That is the PHP project for source builds, your distribution for OS packages, a repository maintainer such as Ondřej Surý or Remi, the image maintainer for containers, or your host. The PHP2Shell article has the full table.

How to check: Tools → Site Health → Info → Server shows the PHP version the web server actually uses. When a distribution backports the fix, the version number does not change, so look the CVE up in your distribution’s tracker and compare package versions instead.

Where a static copy helps: a host that serves files and runs no PHP has no interpreter for a crafted request to reach.

Where it does not: PHP still runs on the origin, behind every form or search path you forward to WordPress, and in every other PHP application on the same servers. The PHP advisory rated the risk highest for mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs”, so a WordPress login screen or security plugin did nothing against it.

Layer 3: the web server

CVE-2026-119618 sits one layer lower again, in the module that lets Apache speak HTTP/2. It needs no PHP and no WordPress, which changes what protects you and how you find out whether you are affected.

Nothing in WordPress stands in front of it

A WordPress login, two-factor authentication and security plugins all run inside PHP, after Apache has parsed the request. HTTP basic authentication configured in Apache is enforced by the same Apache that has to read the HTTP/2 request first. Red Hat describes the risk as “a remote attacker who can reach the web server” running commands “without any authentication”. What helps is making sure strangers cannot open an HTTP/2 connection to that Apache at all.

The version number does not tell you whether you are affected

Apache’s range of 2.4.55 to 2.4.70 describes Apache’s own releases. Most WordPress servers run Apache from a distribution package, and distributions often backport fixes under the version they originally shipped (Debian went the other way this time and moved to 2.4.71). Ubuntu 22.04 ships Apache 2.4.52, below the upstream range, and USN-9090-1 lists it as affected and fixed in package 2.4.52-1ubuntu4.27. Ubuntu 20.04’s 2.4.41 got a fix too, through Ubuntu Pro. Red Hat, on the other hand, says RHEL 8 and earlier are not affected, and that mod_http2 versions before 2.0.8 do not contain the affected code. Each answer came from the vendor’s advisory, not from the number.

So check the advisory for what you run:

Red Hat scores the bug CVSS 9.8 and rates it Critical in general, but Important for RHEL 9 and 10, whose mod_http2 builds it says make exploitation substantially harder. NVD had no score of its own yet when we checked.

If you build the module from the standalone mod_h2 project on GitHub: Apache lists its releases 2.0.8 through 2.0.42 as affected, and that repository is archived, with 2.0.42 from May 29, 2026 as its last release and no commits since June 9. There is no fixed standalone release; the module is maintained in httpd, so the fix comes with 2.4.71 or your distribution’s package.

Checking whether HTTP/2 is on

Red Hat’s assessment is that “only servers that have HTTP/2 enabled are affected”; servers serving only HTTP/1.1 are not. Apache enables HTTP/2 through the Protocols directive, whose default is http/1.1. On the server, check both whether the module is loaded and whether a Protocols line offers h2 or h2c:

# Is mod_http2 loaded? (on RHEL-based systems: httpd -M)
apachectl -M | grep http2

# Does any active configuration offer h2 or h2c?
grep -Rn "Protocols" /etc/apache2/ /etc/httpd/ 2>/dev/null

# Which package version is installed?
dpkg -l apache2-bin      # Debian, Ubuntu
rpm -q httpd mod_http2   # RHEL and derivatives

On Debian and Ubuntu, enabling the module also enables its http2.conf, which sets Protocols h2 h2c http/1.1 for the whole server. So a match in mods-enabled/http2.conf means HTTP/2 is on; a match only in mods-available/ does not.

If you cannot install the fix straight away, Red Hat’s bulletin and Wiz’s write-up give the same mitigation: remove h2 and h2c so that only HTTP/1.1 is offered. Restart Apache for the change to take effect.

Protocols http/1.1

Check every virtual host, because Protocols can be set per server and per virtual host. Then update anyway: Red Hat says the change “reduces the attack surface until a patched version is deployed”; it does not remove the bug.

From outside, curl -so /dev/null -w '%{http_version}\n' --http2 https://example.com/ prints 2 when whatever answers that hostname negotiates HTTP/2. That tells you about your CDN or proxy if you have one, not about the Apache behind it.

What is known about exploitation

The sources do not agree on how far exploit work has got. When Wiz published on November 11, it wrote that “no exploit is available and there are no reports of exploitation in the wild”. Red Hat says “public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled”, without saying which research. A third-party proof of concept published on November 12 reproduces the heap corruption but does not show code execution. As of November 13, 2026, the CVE is not in CISA’s Known Exploited Vulnerabilities catalog, and we found no confirmed exploitation in the wild. Treat it as exploitable and patch.

The two other fixes in 2.4.71

The same release fixes CVE-2026-106023, rated important, a NULL pointer dereference in mod_md that crashes a child process (2.4.30 through 2.4.70), and CVE-2026-109163, rated low, a one-byte stack buffer overwrite in mod_vhost_alias (2.4.69 and 2.4.70). The Debian and Ubuntu advisories above cover all three; Red Hat lists its products as not affected by the mod_vhost_alias bug.

Where a static copy helps, and where it does not

Static delivery only helps here when a different, patched edge serves your files. If visitors reach a CDN that terminates HTTP/2, the CDN’s web server is the one parsing their HTTP/2 frames, and its operator patches it.

A static export served from your own Apache with HTTP/2 enabled is still exposed. The bug sits in the web server, not in WordPress or PHP, so it does not matter that the files are plain HTML. That includes the Local Directory deployment method and any setup where the same Apache serves both the static site and the WordPress origin.

What this does not solve

• The origin. WordPress, PHP and the web server on your origin each still need their fixes. A static public site changes who can send requests to them, not whether they are patched.
• Access control has to sit in front of the web server. For a web server bug, the useful barrier is one that refuses the connection before your Apache handles it: a firewall rule, a VPN, or a proxy that only lets your team through. A WordPress login does not count, and neither does basic auth checked by the same Apache.
• Other software on the same machine. A static marketing site does not patch the shop, the client portal or the old Joomla install on the same server.
• Clean publishing. If an origin was compromised before you patched, the next build carries whatever the attacker changed. Restore from a clean point and check it before you publish again; the Reviewing guide covers checking a publication and its logs.
• Your CDN’s own patching. Moving the public edge to a provider moves the patching duty to them; it does not remove it.

What to do now

1. Patch Apache, or turn HTTP/2 off until you can. Install your distribution’s update or 2.4.71 and check the installed package version against the advisory, or set Protocols http/1.1 and restart. apachectl -M tells you whether mod_http2 is loaded at all.
2. Write down where each layer comes from. For every site: who supplies WordPress, PHP and the web server, and where their advisories appear. The next critical bug will be in one of them, and you will want to know whose release to wait for.

Our exposure check shows which WordPress addresses on your site answer anyone, the PHP version your server reveals, and which web server answers: whether HTTP/2 is negotiated, and whether a CDN or proxy sits in front. It sees only what your hostname answers, not whether the origin behind a CDN also accepts direct connections, and it cannot tell whether Apache has the fix; use the commands above on the server for that.

How this looks on Staatic Cloud

On Staatic Cloud, visitors reach the static pages through Amazon CloudFront. HTTP/2 connections from visitors end at CloudFront or at our Traefik proxy, and the WordPress origin images we build do not load mod_http2; the image build now fails if it ever would. Since November 13, the origins on PHP 8.1 and newer run Apache 2.4.71. The PHP 7.4 and 8.0 images are based on an older Debian release without a fixed package and stay on 2.4.67, with mod_http2 not loaded.

That does not take the origin out of the patching cycle: WordPress, PHP and Apache on it still get updated, which is why we ship the runtime as part of the image. How Staatic secures WordPress explains what stays exposed and what you still look after.

If you use the Staatic plugin on your own hosting, the origin and the server that serves your files are yours to patch and lock down. The Preparation guide covers restricting access to the WordPress host.