PHP Vulnerability: Critical Security Release on 21 October 2026

A PHP vulnerability is a security flaw that attackers can use against software written in PHP. This time the two flaws are in the PHP runtime itself, the language engine that runs WordPress, WooCommerce, Magento and Adobe Commerce, not in a plugin or theme. On 20 October 2026 the PHP security team gave advance notice of a critical security release for 21 October 2026, fixing two vulnerabilities both rated 9.2 on CVSS v4.0. The fixes are now available, and every self-hosted PHP store should patch today.

What PHP announced about the two critical vulnerabilities

The advance notice gave the date and time, the number of vulnerabilities and their severity, and asked all PHP users to prepare now so they could upgrade as soon as the release was available. It also said the team might release earlier if details became public or if there was evidence of active exploitation.

The advisory itself now names both flaws: CVE-2026-109618 and CVE-2026-109619. Both can lead to unauthenticated remote code execution, which means an attacker does not need an account on the store. For a shop, that puts customer data, orders and payment-adjacent code at risk, so this is a same-day patch rather than a routine update.

PHP supported versions: which branches get the fix?

A PHP security update ships for supported branches. According to the PHP supported versions page, four branches are in support, and each now has a fixed release.

PHP 8.1 and older have reached PHP end of life, so the PHP project does not ship new releases for them. The source backports help teams that compile PHP themselves, and a distribution-packaged 8.1, for example on an older Ubuntu LTS, may get a vendor fix. Check your distribution's advisory, but treat the move to a supported branch as required. The supported versions page warns that users of end-of-life releases may be exposed to unpatched security vulnerabilities.

What does the release mean for WooCommerce and Magento stores?

The work depends on who runs your PHP. On hosted platforms such as Shopify and BigCommerce, the merchant does not manage a PHP runtime for the store. Self-hosted WooCommerce, Magento Open Source and Adobe Commerce stores do. So does any custom PHP service around a hosted store, such as an ERP connector, a Laravel middleware or a custom app backend.

WooCommerce's server requirements recommend PHP 8.3 or newer, tested up to PHP 8.4, and warn that older legacy versions have reached end of life. For Adobe Commerce and Magento the PHP branch is tied to the platform release, according to Adobe's system requirements:

That last row is the uncomfortable one. A Magento store still on 2.4.4 or 2.4.5 cannot move to a supported PHP branch without a platform upgrade first. For those stores, a backport buys time, and the advisory turns the platform upgrade into a project with a deadline. Stores on 2.4.6 with PHP 8.1 should move to PHP 8.2.35 now, because 2.4.6 already supports PHP 8.2. If the upgrade bill is close to a rebuild, our Magento to Shopify migration service is the alternative.

PHP version check: what to do today

Start with a PHP version check on every server, then patch in order of risk.

1. Check the PHP version on every server. Run php -v on the server, or in WordPress open Tools, then Site Health, then the Info tab and the Server section, as WordPress's Update PHP page describes. Check the web PHP and the command-line PHP separately, because they can differ, and include staging, cron and queue workers.
2. Patch the servers that serve web requests first. Start with anything running mod_php, which the PHP team rates as the highest risk, then PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Payment and admin servers come before the rest.
3. Ask your host when the fix lands. If a host manages PHP for you, ask for the time they will install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the patched distribution package, and whether every worker is restarted.
4. Patch today, with a quick test. Apply the fix the same day, test on staging if you can do it within hours, and run a checkout smoke test on the live store afterwards.
5. Plan the upgrade for end-of-life servers. If a server is on PHP 8.1 or older, use a vendor or source backport now if one is available, and book the move to a supported branch. Upgrade the platform first if the current Magento or WooCommerce version does not support a newer PHP.

PHP security update: how to patch

Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35 for your branch from your host or package manager, then restart PHP-FPM or the web server so every worker runs the new binary. On Debian, Ubuntu or Red Hat packages, check the distribution's security advisory or the package changelog. Distributions often backport fixes without changing the upstream version number. On Docker, rebuild the image from the patched base and redeploy every container that uses it.

To confirm the web side, a temporary phpinfo page shows the running version; delete it straight after. Then place a test order through checkout and watch the error logs. Updating within the same branch is the right call today; a jump to a new branch belongs in a planned upgrade instead of an emergency window.

If you cannot update PHP today

The advisory is clear that only an update is a complete solution. It lists measures that reduce exposure to specific attack paths without making an installation safe, so use them only to bridge the hours before the patch. The full details are in the advisories for CVE-2026-109618 and CVE-2026-109619.

• For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and lower post_max_size (the advisory suggests 8M without uploads, 32M with them, with upload_max_filesize below it). Use a container or cgroup memory limit as the boundary; the advisory says not to substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, not with ini_set() or .user.ini, and restart every worker. Disabling upload progress blocks the confirmed session paths only, not other variants. On PHP 8.5, also set fatal_error_backtraces=0, which blocks the confirmed fatal backtrace path only.

On a WooCommerce or Magento store, check uploads and imports before you lower post_max_size, because product imports and media uploads may need more than 32M. That is one more reason to patch instead of relying on configuration.

How to update PHP in WordPress and WooCommerce

WordPress does not update PHP itself, because the server sets the PHP version. You update PHP in WordPress through your hosting control panel or your server's package manager. Before you change branch, take a full backup, update WordPress, WooCommerce and every plugin, and test on a staging copy. After the switch, Tools, then Site Health, then Info, then Server shows the PHP version WordPress is actually using. WordPress itself recommends PHP 8.3 or newer on its Update PHP page.

Moving to the fixed release of the same branch is a small change. Moving to a new branch, for example from 8.2 to 8.3, needs a plugin and extension compatibility check first; our WooCommerce PHP compatibility guide walks through that test. If the host does not offer a supported branch, that is a reason to change host rather than wait.

What to do next

Run the version check now and patch every server on a supported branch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today, so this PHP vulnerability is closed. Put any PHP 8.1 or older server on a backport and an upgrade ticket with a date. For older Magento stores, our Magento upgrade cost versus replatforming comparison helps decide whether to upgrade or move. If you want the PHP upgrade done for you, our WooCommerce development team can scope it.