PHP critical security release on 21 October, check your site

On 21 October 2026 at 14:00 UTC (17:00 in Bulgaria) the PHP team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated remote code execution. In plain terms, an attacker could make the server run their own code without having an account on the site. Both are rated 9.2 on CVSS v4.0, the 0 to 10 scale used to express how dangerous a vulnerability is. The PHP team urges everyone to update immediately.

We published this on 21 October before the release and updated it the next day with the fixed versions and which servers are at risk. How to check your own site and what to ask your host is covered in a separate post on PHP2Shell and checking your WordPress site.

What the release fixes

The first flaw, CVE-2026-109618, is in the way PHP handles running out of memory. If memory runs out in the middle of a request, PHP can stop while some internal data is only partly set up, and the cleanup after the request then treats that data as valid. The second, CVE-2026-109619, involves data from one request that stays behind in the process after its memory has been freed. A later request handled by the same process can use it before PHP resets it.

According to php.net, every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where there is a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

There is no complete mitigation short of updating. The PHP team lists a few server settings that narrow specific attack paths, and says plainly that they do not make an installation safe. As of 22 October, php.net, NVD and CISA report no confirmed attacks using these flaws.

Why this matters for your WordPress site

WordPress is written in PHP. Every page view, every admin login and every WooCommerce order runs through PHP on the server. A flaw in PHP itself sits underneath WordPress, the theme and the plugins, so updates in the admin will not close it. A security plugin will not help either, because the demonstrated mod_php attack starts before WordPress has even loaded. If you want to know what the score means, see what a CVSS score means for a WordPress site.

Who updates PHP on shared hosting

If your site is on shared hosting with cPanel, as many WordPress sites are, you choose the PHP branch (8.3, 8.4 and so on), but you do not install PHP itself. Your host does. On cPanel servers PHP versions come as EasyApache 4 packages with names such as ea-php83 and ea-php84. Servers running CloudLinux also have alt-php packages, which are what you choose between in Select PHP Version.

The fix reaches your site when your host installs the updated packages, on its own schedule. Linux distributions and long-term support vendors received the patches in advance, so updated packages may already be available. Write to your host and ask whether the fixed PHP versions are installed on the server your site is on, and if not, when they will be.

If the site is on its own server or a VPS, PHP is updated by whoever looks after that server. Ask them to install the updated packages and restart PHP today.

Is your site affected?

Every version before the fixed ones is affected. Compare your site's version with the table.

In the WordPress admin, open Tools > Site Health, then the Info tab and the Server section. The PHP version row shows the full version number, for example 8.3.36.

In cPanel, the selected branch is shown in the Software section, in MultiPHP Manager or Select PHP Version depending on the server. The full number, though, is in Site Health.

If you have Terminal in cPanel, the command below shows the PHP version and changes nothing.

# cPanel > Terminal, in the site's folder
# Read-only. Shows the command-line PHP version.
php -v

On cPanel servers the command picks the version set for the folder you are in, but on some servers it can differ from the version the site actually runs on. If the two disagree, trust Site Health. The PHP version guide covers versions and how to change them in more detail.

If your site shows 8.5.11, 8.4.26, 8.3.35 or 8.2.34, it is on the 24 September release and, going by the number, does not have the fix yet. Linux distributions, however, often build fixes into their packages without changing the version number. So if the number is older, ask your host whether the package already includes the fix for both flaws.

If your site runs PHP 8.1 or older

The PHP team supports only the branches from 8.2 to 8.5, so there was no 21 October release for 8.1 and older. Some distributions and long-term support vendors backport the fixes to them. The team also published minimal source backports for 7.4, 8.0 and 8.1, but those are for people who compile PHP themselves. On shared hosting neither is in your hands, so assume a site on 8.1 or older is vulnerable until your host confirms otherwise.

If you are switching now, pick 8.3 or 8.4. Do not move to 8.2, which stops getting security fixes on 31 December, so you would be switching again within weeks. The PHP team repeats that reminder in the 8.2.35 announcement. The dates are covered in our news on the end of PHP 8.2 security support. Shops have one more reason, since WooCommerce will require PHP 8.1 or newer from version 11.6.

What to do now

1. Check in Site Health which PHP version your site runs and compare it with the table.
2. If the number is older than the fixed one, write to your host and ask whether the fix is installed.
3. If the site is on 8.1 or older, take a backup and plan the move to 8.3 or 8.4.
4. Once your host confirms, open Site Health again and check that the number has changed.

Since the release, the changes to the PHP source code and the detailed write-ups of both flaws are public. That makes it easier to look for servers that have not been updated yet, so do not put off the question to your host.

What we do

With WordPress maintenance we update PHP on the server when we look after the server too, and we change the site's PHP version with a backup, trying it in staging first. On shared hosting the PHP packages themselves are updated by the host. If you are not sure which PHP version your site runs or how to change it, describe it in the inquiry form.

Sources

• PHP, Security advisory. Critical remote code execution vulnerabilities, update now
• PHP, Upcoming Critical PHP Security Release
• GitHub, php-src, GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub, php-src, GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NVD, CVE-2026-109618
• NVD, CVE-2026-109619
• CISA, Known Exploited Vulnerabilities Catalog
• PHP, Supported Versions
• PHP, Unsupported Branches
• PHP, ChangeLog for version 8
• Red Hat, Backporting Security Fixes
• WordPress.org, Site Health screen
• cPanel, MultiPHP Manager for cPanel
• cPanel, How to Locate and Install a PHP Version or Extension
• cPanel, EasyApache 4 and the ea-php-cli Package
• CloudLinux, PHP Selector