Critical PHP Security Update: What WordPress Site Owners Need to Do Now

On October 21, 2026 the PHP project released security updates for every supported version of PHP. They fix two critical bugs that can let an attacker run code on a server without logging in. WordPress runs on PHP, so if your site is on one of the affected versions, this update is for you. The details of both bugs leaked on October 20, before any patch existed, so this is not one to leave for the next maintenance window. The official notice is the PHP security advisory on php.net.

What was fixed in PHP on October 21, 2026

The PHP project published a security advisory with two vulnerabilities, both rated 9.2 out of 10 (CVSS v4.0):

• CVE-2026-109618: when PHP runs out of memory at the wrong moment, request data can be left half set up, and PHP’s cleanup then treats it as valid.
• CVE-2026-109619: internal request state can outlive the memory behind it, and a later request on the same worker may use that stale state.

Both can lead to remote code execution, which means an attacker takes control of what the server runs. The advisory rates the risk highest for Apache with mod_php, where an exploit exists and an unauthenticated request can trigger the attack before any application code, such as WordPress or a plugin, even runs. That is why it does not matter how well your plugins are maintained. The advisory says all PHP installations serving web requests are at risk, including PHP-FPM (which most WordPress hosts use), mod_php, php-cgi, FrankenPHP and LiteSpeed.

The two bugs were meant to be disclosed together with the fix. Their details leaked on October 20 instead, according to security vendors such as Huntress, and the PHP team had already announced a critical release for the next day. That is why hosts moved quickly, and why waiting is a bad idea.

Which PHP version is safe

Linux distributions and long-term-support vendors received the patches in advance, so on a normal Ubuntu or Debian server the fix arrives as a package update. Check with your host or vendor instead of assuming it happened. For PHP 8.1 and older, the PHP security team published minimal source backports, but those are for vendors and developers who build PHP themselves, not a fix you can simply install.

What to do as a site owner

1. Find your PHP version. In WordPress, open Tools, then Site Health, then Info, then Server. It shows the PHP version, though not always the patch number on managed hosting.
2. Ask your host. Ask whether the October 21 PHP security release is installed, and on which patch number. A host that cannot answer is a warning sign.
3. If you are on PHP 8.1 or older, plan an upgrade now. You will not get this fix from PHP itself. Test your plugins and theme on a copy first, then move to 8.3 or newer.
4. If you are on PHP 8.2, patch now and plan the move. 8.2.35 fixes these bugs, but PHP 8.2 reaches end of life on December 31, 2026 and gets no security fixes after that. Use the next few weeks to test your site on 8.3 or newer.
5. If you run your own server, update the packages and restart PHP-FPM. A package that is installed but not restarted keeps running the old code.

The advisory also lists partial mitigations for servers that cannot update at once, such as turning off session.upload_progress.enabled and limiting request sizes. It states plainly that these reduce exposure but do not make an installation safe. Treat them as a stopgap for a day or two.

How we updated our own servers

Imagewize runs on a Trellis server on Hetzner, with PHP 8.4. Our production server was on 8.4.26 and is now on 8.4.27, and the local development VM matches it. One thing nearly caught us: our Trellis configuration sets apt_package_state to present, which installs a package if it is missing but never upgrades one that is already there. Provisioning with the PHP tag alone would have reported success and changed nothing. Passing apt_package_state=latest for that one run did the upgrade, and we then checked the version on the server instead of trusting the output.

# upgrade installed PHP packages on production
trellis provision --tags php --extra-vars apt_package_state=latest production

# same for the local VM
trellis provision --tags php --extra-vars apt_package_state=latest development

# verify on the server (CLI and FPM builds)
ssh web@example.com "php -v | head -1; php-fpm8.4 -v | head -1; systemctl is-active php8.4-fpm"

Running your own server and worried about PHP-FPM workers being hammered while you patch? Our write-up on hardening PHP-FPM pools on Trellis covers that side. If you would rather not do any of this yourself, that is what managed WordPress hosting is for.

Sources: PHP security advisory, October 21, 2026 (php.net); advance notice, October 20, 2026 (php.net).

Frequently asked questions

• Is my WordPress site affected by the October 2026 PHP vulnerabilities? Yes, if it runs a PHP version older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on those branches, or any PHP 8.1 or older. The bugs are in PHP itself, so WordPress and its plugins do not need to have a flaw.
• Do I need to update WordPress or my plugins? No. The fix is in PHP. Updating WordPress or plugins does not close these two vulnerabilities.
• How do I check my PHP version? In WordPress, go to Tools, then Site Health, then Info, then Server. On managed hosting the patch number may be hidden, so ask your host or check the control panel.
• What if I run PHP 8.1 or older? The PHP project no longer fixes those versions. Move to a supported version, preferably 8.3 or newer, after testing your site on a copy.
• Can I work around it without updating? Only partly. The advisory lists settings that lower the risk, but says only updating is a complete fix.