Why updating WordPress won’t fix the PHP and Brotli flaws
Two critical October 2026 flaws in PHP and the Brotli library are fixed on the server, not in WordPress. What is known so far, and what to ask your host.
In late October 2026, critical security flaws were found in two pieces of server software that sit underneath WordPress. One is in PHP, the programming language WordPress runs on. The other is in Brotli, a compression library. Neither is fixed by clicking “Update” in your WordPress dashboard. If your host has not patched and restarted the server, your site can still be exposed even when WordPress and every plugin are fully up to date.
The PHP flaws
On 21 October 2026 the PHP project released fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, known together as “PHP2Shell”. The PHP security team rates both Critical, with a severity score of 9.2 out of 10. Details had leaked the day before, and several services went offline as a precaution, including the Dutch government’s DigiD and MijnOverheid and The SEO Framework, a WordPress SEO plugin maker.
The UK’s National Cyber Security Centre (NCSC) describes the problem plainly. An attacker can make PHP run out of memory, which corrupts that memory, and under certain conditions this lets them run their own code on the server without logging in. Wiz Research, which reported the flaws, demonstrated this against the latest WordPress, Drupal and Joomla container images. It also showed the flaws can leak server memory, which may contain passwords and API keys.
Every common way of running PHP is affected. Patchstack says the risk is highest on servers using Apache with mod_php, where the attack can start before any WordPress code runs.
WordPress.org and WooCommerce both say the flaws are not specific to WordPress, and that no WordPress or WooCommerce update is required or planned. The fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP project no longer fixes versions older than 8.2, although some providers, including CloudLinux for cPanel servers, AlmaLinux, TuxCare, Zend and the widely used Debian/Ubuntu packages by Ondřej Surý, have released their own fixes for older versions.
The Brotli flaw
The second flaw, CVE-2026-111497, is in Brotli. A specially crafted compressed file can make it write data outside the memory set aside for it. Google published the CVE on 22 October and scored it 9.2. It affects Brotli 1.0.3 to 1.2.0 and is fixed in 1.0.10, 1.1.1 and 1.2.1. It has picked up several unofficial names, including HTTP2Shell, Node2Shell, Brotli2Shell and Broccoli2Shell. Despite the first of these, Wordfence notes it has nothing to do with HTTP/2.
WordPress does not include Brotli. It uses the copy supplied by the server whenever it fetches content from another website. As Patchstack puts it, “there is nothing to update in WordPress, no plugin to upgrade.”
The route that matters most for WordPress is xmlrpc.php, an older file used for remote connections and “pingbacks” (automatic notifications when another site links to yours). An attacker sends a pingback, without logging in, pointing at a server they control. WordPress fetches that address and the attacker replies with malicious compressed data. A default WordPress install has this route open. Other routes include plugins that fetch a web address supplied by a visitor, such as link previews, importers and webhooks, plus embedded content and RSS feeds.
Updating PHP does not update Brotli. They are separate fixes, and a server needs both.
How worried should you be
There is a difference between attack attempts and confirmed break-ins, and so far the evidence is mostly the former.
For PHP, Wordfence’s firewall blocked over 74,000 exploit or probing attempts by 22 October. Patchstack’s timeline for 21 October records hosting partners reporting “multiple active exploitation incidents” in the morning, but its own data later that day showed “only probing attacks, with no hard evidence of breaches yet”. As of 28 October, Wordfence was not aware of any WordPress site compromised through PHP2Shell.
For Brotli, the US cyber agency CISA added the flaw to its list of known exploited vulnerabilities on 27 October, but its entry does not say what software was involved or whether WordPress was. On 30 October Patchstack said crashing a PHP worker this way is easy, and a few hundred requests can keep a site down, but public attack tools for WordPress stopped at the crash. On 2 November Wordfence reported reproducing code execution in its lab, but only on one exact server setup matching a public proof of concept. The same attack failed once Brotli alone was updated. Wordfence calls the exploit “not universal” and had found no public, checkable report of a real-world compromise.
Both companies are clear that seeing no compromises does not make an unpatched server safe. The 2 November reports are the latest we have seen, and details may change. For most sites, the most realistic near-term risk from Brotli is downtime rather than a takeover, but the fix is the same either way.
Why “disable XML-RPC” may not be enough
Many sites use a plugin setting to turn off XML-RPC. The usual setting does not stop pingbacks, and nor does Wordfence’s “Disable XML-RPC authentication” option. Blocking xmlrpc.php at the web server, or removing the pingback feature in code, does close that route, but it closes only that one. It can also break legitimate tools that connect to your site remotely. Updating Brotli is the real fix.
What you should do
You can check your PHP version in WordPress under Tools > Site Health > Info > Server. Site Health cannot tell you whether Brotli is patched.
If we look after your website
There is nothing you need to do inside WordPress. If you would like to know where your server stands on both fixes, contact us and we will tell you.
If your host manages your server
WordPress.org notes your host may already be patching and adding firewall rules, but you should still check. Ask them:
- Has PHP been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a backported fix for older versions), and have all PHP workers been restarted?
- Is the Brotli library used by my site patched, and were affected services restarted? On Debian and Ubuntu a patched server can still show Brotli 1.1.0, so ask for a clear yes or no.
- On CloudLinux or similar platforms, have all copies of Brotli been updated? There can be several.
- When can my site move to PHP 8.4 or 8.5? PHP 8.2 stops getting security fixes on 31 December 2026.
Sites on Automattic’s platforms (WordPress.com, WordPress VIP, Pressable, WP Cloud) are already protected against the PHP flaws.
If you manage your own server
- Install a fixed PHP version and restart every PHP worker. If you run PHP older than 8.2 with no backported fix, WordPress.org advises considering taking the server offline until it is updated.
- Update your system’s Brotli package and restart affected services.
- If you use containers, rebuild from an updated base image. Restarting an existing container does not replace vulnerable files, and Patchstack found the official wordpress:latest image still had a vulnerable Brotli as of 30 October.
- If you do not need XML-RPC, block xmlrpc.php at the web server, after checking nothing relies on it.
- Avoid unofficial “fix” plugins and copied code snippets. Cloudflare’s free firewall rules help only if all traffic reaches your server through Cloudflare.
Patchstack’s possible warning signs include unusual uploads followed by memory errors, very large or malformed session cookies, and PHP workers restarting for no clear reason. These are not proof either way.
Keeping WordPress itself current still matters, as our post on the WordPress 7.1.4 upgrade flaw showed. But this month is a reminder that the server underneath needs the same attention. If you would rather someone else kept an eye on both, our care plans cover it.