How to Update PHP in WordPress After the Critical October 2026 PHP Flaws

To update PHP in WordPress now, confirm your server runs PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor build with the same fixes, then restart every PHP process. These releases, published on 21 October 2026, fix two critical flaws that let attackers run code without logging in. On PHP 8.1 or older, move to 8.3 or newer.

This is not a routine update. The US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its list of vulnerabilities exploited in real attacks on 26 October, and WordPress.org told site owners the same day the fixes came out to check with their host. The flaws are in PHP itself, so the WordPress updater cannot fix them and a security plugin cannot block the worst version of the attack. This guide covers what happened, how to check the exact PHP build your site runs, how to apply the patch or the official stopgaps, and how to change PHP version safely if your branch did not get a fix. It also includes our own count, from WordPress.org data, of how many WordPress sites are on a branch that received one.

What happened, in date order

On 21 October 2026 the PHP project shipped emergency security releases for every supported branch, and within five days the US government listed both flaws as exploited in real attacks. Here is the sequence, with the source for each line.

Two things make this unusual. First, the flaws sit in PHP itself, not in WordPress or a plugin, so the WordPress updater cannot fix them. Second, php.net says that for Apache with mod_php there is "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs". In plain terms, a hardened WordPress install, a security plugin and a firewall plugin do not help on that setup, because the attack lands before WordPress loads.

We will update this page when php.net publishes the full CVE-2026-115560 advisory, when the next regular PHP releases ship, or when CISA or the PHP project changes its guidance.

Who is affected

Every WordPress site whose server runs a PHP build older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35, plus every site on PHP 8.1 or older that has not received a vendor backport. The GitHub advisories list the vulnerable ranges as "< 8.2.35", "< 8.3.36", "< 8.4.27" and "< 8.5.12".

php.net's own wording on scope: "Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php". The OOM advisory adds that for PHP-FPM, "Source analysis therefore supports FPM as a susceptible, though no complete FPM exploit has been demonstrated for this SAPI." Susceptible but not yet demonstrated is still a reason to patch.

On older branches, php.net says: "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes". It also says the PHP security team "provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor." A source backport helps a server administrator who compiles PHP. It does nothing for a shared hosting customer unless the host applies it.

How many WordPress sites are on a branch with a fix

About two thirds of WordPress sites run a PHP branch that received an official fix on 21 October, and about one third run a branch that did not. We calculated this from WordPress.org's public PHP statistics API on 29 October 2026.

How we calculated it. We downloaded https://api.wordpress.org/stats/php/1.0/ on 29 October 2026. It returns the percentage of WordPress sites reporting each PHP branch (for example "8.3":28.066). We summed branches 8.2 to 8.5 for the fixed group (22.536 + 28.066 + 10.297 + 5.875 = 66.774), branches 7.4, 8.0 and 8.1 for the backport group (14.888 + 3.436 + 9.442 = 27.766), and everything below 7.4 for the last group (5.436). The figures in the table are rounded to one decimal place.

What this data cannot tell you. The API reports the branch (8.3), not the patch release (8.3.36). So it cannot say how many sites are actually patched. A site on 8.3 is only fixed once its host installs 8.3.36 or a vendor build that contains the same fix. It also counts only sites that report to WordPress.org, and a WordPress site can run on a different PHP version from the command line on the same server, which matters for one of the checks below.

The practical reading: if you are on 7.4, 8.0 or 8.1, which is roughly one WordPress site in four, you are relying on your host having done something extra. Many will have. You should not assume it. Our WordPress statistics page has the wider version picture.

How to check current PHP version in WordPress

The quickest way is the dashboard: go to Tools, then Site Health, then the Info tab, then Server. WordPress.org's own post points there. It shows the PHP version the website itself is using, which is the one that matters.

The catch is that Site Health may show only the branch and patch number from upstream (for example 8.3.36), or a distribution build string that looks older than it is. That is why there are several checks, and why they do not always agree.

From SSH, these commands give you the full picture. Run them from the WordPress folder.

# the command-line PHP (may not be what the website uses)
php -v

# the PHP that WP-CLI runs under
wp eval 'echo PHP_VERSION, PHP_EOL;' --skip-plugins --skip-themes

# which PHP-FPM services are running, and their versions
systemctl list-units --type=service | grep -i php
php-fpm8.3 -v

# Debian or Ubuntu: what is installed, and is the fix in the changelog?
dpkg -l | grep -E '^ii\s+php[0-9.]+-(fpm|cli|common)'
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'

# RHEL, Alma or Rocky
rpm -qa | grep -i php

Swap 8.3 for your branch. On distribution builds, the version number may stay on an older upstream release while the security fix is backported inside it, so the changelog is the reliable check. If the CVE numbers appear there, the fix is in.

If you have no SSH access, a temporary info file shows the version the website uses. Create a file with a long random name, load it once, then delete it:

<?php phpinfo();

Look for the version at the top and the "Server API" line, which tells you whether the site runs under FPM, Apache 2.0 Handler (mod_php) or LiteSpeed. Delete the file straight after. It reveals paths, modules and settings that help an attacker.

A patch release and a version change are different jobs

A patch release (8.3.30 to 8.3.36) is a security and bug fix inside the same branch, and it is what this week's alert asks for. A version change (8.2 to 8.3) is a bigger move that can break old plugin code and needs testing. Confusing the two is an easy mistake, and it leads people either to ignore the alert or to make a risky change in a hurry.

So there are two clear paths. If your site is on 8.2, 8.3, 8.4 or 8.5, you need the patch release, which means asking your host or updating your own packages. If your site is on 8.1 or older, the realistic fix is a version change to 8.3 or newer, done carefully, because staying put leaves you depending on a backport you cannot easily verify.

How to apply the patch this week

The fix is to get the PHP build that contains it onto the server and restart every PHP process. How you do that depends on who runs the server.

Shared or managed hosting

You cannot update PHP packages yourself; the host does it. Send the host a short, specific message so you get a specific answer:

Subject: PHP security release of 21 October (CVE-2026-109618, CVE-2026-109619)

Please confirm, for the site at example.com:
1. Which PHP version and build the site runs, and the handler (FPM, LSAPI or mod_php).
2. Whether that build contains the fixes for CVE-2026-109618 and CVE-2026-109619.
3. The date the patched build was deployed and the PHP workers restarted.

A good host will answer all three. A vague "we keep our servers updated" is not an answer to question 2.

Your own VPS or dedicated server

Linux distributions received the patches in advance, according to php.net, so the update is usually a normal package upgrade followed by a restart. On Debian or Ubuntu:

# back up first
wp db export before-php-patch.sql

# refresh package lists and upgrade the PHP packages
sudo apt update
sudo apt install --only-upgrade 'php8.3*'

# restart every PHP-FPM pool, then the web server
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx     # or: sudo systemctl restart apache2

# confirm the fix is in the installed package
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'

On RHEL-family systems the equivalent is sudo dnf upgrade 'php*' followed by restarting php-fpm and the web server. If you use a third-party PHP repository, the patched build comes from that repository's maintainer, so check their notice too.

The restart is not optional. The second flaw is about state that a long-running PHP worker keeps between requests. Updating the files on disk without restarting leaves the old code running in memory.

Then check WordPress

A patch release rarely breaks anything, but confirm the site loads, the dashboard works, and forms and checkout still submit. If you see "There has been a critical error on this website", our guide to the WordPress critical error shows how to read the log and find the cause.

If you cannot update yet: the official mitigations

php.net lists stopgap settings, and is blunt that they are not a fix: "while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe." Here they are, quoted from the 21 October advisory.

For CVE-2026-109618 (OOM corruption)

• "Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration". php.net adds that this "removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path."
• "Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size."
• "Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth."
• "Use a container or cgroup limit as an availability boundary". php.net warns: "Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure."

For CVE-2026-109619 (stale global state)

• "Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini."
• "On PHP 8.5, set fatal_error_backtraces=0 and restart every worker."
• "Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help."

For a WordPress site, two notes on these. First, setting memory_limit=-1 removes a safety net against runaway plugins, so a single bad request can use a lot of server memory; that is why php.net pairs it with a container or cgroup limit. Second, WordPress core does not need PHP session upload progress, so session.upload_progress.enabled=0 is unlikely to break core. Test forms and uploads anyway, because a plugin might use it. The 23 October advisory says to keep that setting in place "until the next regular bugfix release".

Here is what the FPM pool version looks like on a Debian-style server. Adjust the path for your branch and pool name:

# /etc/php/8.3/fpm/pool.d/www.conf  (add at the end of the pool)
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M

# then restart every worker
sudo systemctl restart php8.3-fpm

If none of this is possible, the agencies are clear. WordPress.org quotes the UK NCSC: "Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated." CISA says organisations that cannot update should "take PHP-based systems offline until they can be patched or updated."

How to upgrade PHP on a WordPress site safely

To move to a new PHP version, test the site on a copy running the new version, fix what breaks, then switch the live site in the control panel and keep the old version ready as a fallback. If you are on 8.1 or older, this is now the real fix, not a someday job.

1. Pick the target. WordPress.org's requirements page recommends "PHP version 8.3 or greater". 8.3 is a sensible floor for most sites; 8.4 if your plugins support it.
2. Update WordPress, plugins and themes first, on the current PHP. Old plugin versions are the usual cause of breakage, and the newer versions often already support the newer PHP.
3. Take a full backup of files and database, stored off the server. Our guide to backing up WordPress covers what to keep.
4. Make a staging copy and set it to the new PHP version. See how to create a WordPress staging site.
5. Scan the code for compatibility problems (commands below) and turn on the debug log on staging.
6. Click through the important journeys on staging: home page, contact form, login, checkout, booking, search, and the dashboard screens your staff use.
7. Read the debug log. Fatal errors must be fixed. Deprecation notices are warnings for the next upgrade, not blockers.
8. Switch the live site in the control panel at a quiet time, then repeat the key checks straight away.
9. Keep the fallback for a week. If something breaks, switch back in the panel while you fix it, but treat that as days, not months.

Scan the code before you switch

The PHPCompatibilityWP ruleset for PHP_CodeSniffer flags code that will not run on a given PHP version. Its README gives the install and run commands. Run it on staging or a local copy, not on the live server:

# one-off setup in an empty folder
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/phpcompatibility-wp:"^3.0@dev"

# scan plugins and themes against PHP 8.3 and newer
vendor/bin/phpcs -p /path/to/wp-content/plugins /path/to/wp-content/themes \
  --standard=PHPCompatibilityWP --extensions=php --runtime-set testVersion 8.3-

Static scanning misses some problems and reports some false alarms, so treat it as a list of places to look, not a verdict. The debug log on staging is the real test:

# in wp-config.php on STAGING only
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

# after clicking through the site
grep -E 'PHP (Fatal|Warning|Deprecated)' wp-content/debug.log | sort | uniq -c | sort -rn | head -30

Switching in the control panel

In cPanel, the screen is MultiPHP Manager. cPanel's documentation describes it as: select the checkbox for the domain, choose the version from the PHP Version menu, and click Apply. It also notes that if the version you need is missing, it is either not installed on the server or not available to your account, and the administrator has to add it. Other panels and managed hosts have an equivalent screen; follow your host's own guide for it.

What is the best PHP version for WordPress in 2026?

PHP 8.3 or newer, fully patched. WordPress.org recommends 8.3 or greater, and 8.3 has security support until 31 December 2027 according to php.net. WordPress still runs on PHP 7.4, but its requirements page says older versions "have reached their official End Of Life and may expose your site to security vulnerabilities".

Dates are from php.net's supported versions and end-of-life pages; compatibility is from the WordPress core handbook's PHP compatibility table, last updated 19 August 2026. One trap in that table: WordPress 6.8 and older are not listed as compatible with PHP 8.5, and WordPress 6.6 and older are not listed for 8.4. If your WordPress is old, update WordPress before you raise PHP.

Is PHP 8.4 stable for WordPress?

Yes, for WordPress core. The handbook lists 8.4 as compatible with WordPress 6.7 and later, including 7.0 and 7.1. Stability on your site depends on your plugins and theme, so test on staging. 8.4 is in active support until 31 December 2026 and gets security fixes until 31 December 2028.

How long will PHP 8.4 be supported?

Security fixes until 31 December 2028, per php.net. Bug-fix (active) support ends on 31 December 2026, after which 8.4 receives security releases only, the same stage 8.3 is in today.

For the full end-of-life story, including what happens to 8.2 sites on 1 January, see our guide to PHP 8.2 end of life for WordPress.

How to update a WordPress website manually

Updating PHP and updating WordPress are separate jobs, and this alert is about PHP. But many owners searching this week also need to update WordPress itself, because 7.1.4 shipped on 28 October with 22 security fixes. The manual route, for when the dashboard button does not work:

# with WP-CLI (recommended)
wp db export before-core-update.sql
wp core update
wp core update-db
wp core verify-checksums

# plugins and themes
wp plugin update --all
wp theme update --all

Without WP-CLI, download the release zip from WordPress.org, replace the wp-admin and wp-includes folders and the root files except wp-config.php, and leave wp-content alone. Then visit the dashboard so WordPress can run any database update. Our WordPress core vulnerability tracker lists the latest safe release for each branch.

Check whether anyone got in first

Patching closes the hole but does not remove anyone already inside. The NCSC advises organisations to "assess the system for any evidence of compromise prior to your upgrade or mitigation", and CISA says to watch for "PHP worker processes launching shells or downloading tools". CISA also flagged both CVEs for its forensic triage requirements. For a WordPress site, these checks cover the common signs:

# PHP worker processes with unexpected children (look for sh, bash, curl, wget)
ps -ef --forest | grep -A3 -E 'php-fpm|apache2|httpd|lsphp' | grep -E 'sh |bash|curl|wget'

# PHP files changed in the last 10 days across the site
find . -name '*.php' -mtime -10 -not -path './wp-content/cache/*' | head -50

# PHP files in uploads, which should hold none
find wp-content/uploads -name '*.php'

# core files that do not match the official release
wp core verify-checksums

# administrators you do not recognise
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

If any of these turn something up, treat it as a compromise of the whole server, not just one file. Our guide to fixing a hacked WordPress site walks through the full cleanup.

What this does not mean

Deadline checklist

• Today: check your PHP version in Site Health, and ask your host the three questions above.
• Today: if you run your own server, install the patched packages, restart every PHP worker, and confirm the CVEs appear in the package changelog.
• Today, if you cannot patch: apply the php.net mitigations or take the site offline, as the NCSC and CISA advise.
• Today: update WordPress to 7.1.4 or the latest release of your branch.
• This week: run the compromise checks, or have your host or developer run them.
• This week: if you are on PHP 8.1 or older, book the move to 8.3 or newer, starting with a staging test.
• When php.net releases the next regular bug-fix builds: install them, and only then consider removing the session.upload_progress.enabled=0 setting.
• Before 31 December 2026: move any site still on PHP 8.2 to 8.3 or newer.
• Before 8 December 2026: plan for WordPress 7.2, scheduled for that date. See the 7.2 release guide.

US federal civilian agencies had a CISA deadline of 29 October 2026 for both CVEs. That deadline binds only those agencies, but it shows how urgent the patch is for everyone else.