WooCommerce PHP RCE patch: fix the runtime, keep checkout up

To patch PHP2Shell on a WooCommerce store, update the PHP runtime that serves your site. Updating WooCommerce does not do it. The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor build that names both CVEs, plus a restart of the PHP workers. Ask your host to confirm both for your domain, then test checkout. WooCommerce, plugins and stored keys still need their own care.

Is my WooCommerce store affected?

If it runs on PHP, it is in scope. WooCommerce is a WordPress plugin, and WordPress runs on PHP, so every WooCommerce store is a PHP site, as the WordPress-side explanation spells out. The PHP project says all installations serving web requests are in scope. It rates the risk highest for mod_php, where it describes a demonstrated attack that runs before any application code.

The store being fully up to date does not change this. Cloudflare says the flaws are in the PHP runtime, so updating site code or plugins alone does not fix them. Our PHP2Shell explainer has the full version table.

Does updating WooCommerce patch PHP?

A store owner's routine is to update WordPress, WooCommerce and the payment plugin. Those updates are good practice. They do not touch the PHP binary, so after all of them the store can still run an unpatched PHP.

Two more traps sit on the PHP side:

1. The version label can mislead. A fixed vendor package can keep an older version number. The PHP changelog lists the two fixes by GHSA id, not CVE number, so a package changelog may name either. Ask for the identifier, not just the branch.
2. A new package is not a restarted worker. The PHP notice says to restart every worker after its configuration measures. Long-running PHP processes keep the code they started with, which is why the restart step after a PHP update matters.

How do I patch PHP and keep the store open?

If a host manages PHP for you

WordPress.org says hosts handle PHP versions, usually through their settings or a support request. Send this and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package or build identifier, confirm that every PHP worker serving my store has been restarted or replaced since, tell me whether session.upload_progress.enabled=0 is set for my PHP workers (PHP's 23 October notice asks for it until the next release, for CVE-2026-115560), and tell me whether I need to change a setting or redeploy.

• Find your PHP version: Tools, Site Health, Info, Server section. It shows a version, not a backport or a restart.
• Send the question above to your host. Add the date and time you sent it.
• Back up the site first. WordPress.org recommends a backup before a PHP update.
• If the host will move you to a new PHP branch, test plugin and theme compatibility first, as WordPress.org advises. Ask for a patched build of your current branch if you cannot test this week.
• Ask the host to confirm session.upload_progress.enabled=0 in php.ini or the FPM pool, and a worker restart after it. PHP's 23 October notice recommends this for CVE-2026-115560 until the next release.
• Run the checkout test list below once the host says it is done.

Our page on what to ask a shared host has more on the answers to expect. "Nothing published" from a host means ask, not patched and not unpatched.

If you manage the server yourself

• Install PHP packages from your distribution or vendor. The package changelog should name both fixes.
• Restart PHP-FPM, or Apache if you use mod_php. Check the web runtime, not just php -v, which can be a different binary.
• Rebuild and redeploy any container image that bundles PHP, and check every virtual host separately if several PHP versions run side by side.
• Know the stopgaps and their limits. PHP lists temporary measures, such as session.upload_progress.enabled=0 for CVE-2026-109619, and says they do not make an installation safe. Only an update is a complete solution.
• Separately, PHP's 23 October notice says a third issue, CVE-2026-115560, will get its own advisory with the next release. It suggests setting session.upload_progress.enabled=0 until then. Cloudflare says that issue affects fully patched releases including 8.5.12.

What if my host cannot confirm a patch?

The UK NCSC says to update to the latest version of PHP. It adds that the PHP Foundation provides temporary mitigations if you cannot update, and that if you cannot apply them, or applying them would take too long, you should consider taking the system offline until it can be fully mitigated. For a store, that is a business decision, so make it with the host's answer in hand. A WAF is a stopgap. Cloudflare says customers should still patch.

What should I test after the runtime changes?

This list is our own, not a vendor's. A PHP change can show up first in the parts of a store that move money.

Am I affected? A three-state self-test

Was my store exploited before I patched?

Unknown for most stores, and nobody can answer it from outside. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October, so exploitation in the wild is on record. AWS saw attempts against its honeypots on 17 October, four days before disclosure, and says it is unclear whether any would have worked on real systems. AWS advises investigating from at least 17 October, reviewing web server logs, and checking for unexpected process execution or file changes on web servers.

On a store, add these to the review: new administrator accounts, unexpected PHP files in upload folders, and orders or payment settings you did not change. Our list of exploitation indicators goes deeper. If the checkout page itself was altered, see how to find a card-skimming script. The UK NCSC says to check for signs of compromise and backdoors if you cannot update or disable a system straight away, and to use an assured incident response provider if needed. If the review finds anything, treat secrets stored on that server (payment API keys, webhook secrets, database and admin passwords) as readable and rotate them, as in our steps for replacing exposed keys and passwords. That step is our advice, not NCSC's.

What is the bug?

Both CVEs are memory-handling problems in the PHP engine. PHP describes CVE-2026-109618 as out-of-memory handling that can leave request data partly initialized, and CVE-2026-109619 as request state that survives after its memory was freed. We do not reproduce attack detail here, and you do not need it to fix a store. For the other store guides, see more ecommerce security pages.