WooCommerce Security: The Risk Is in PHP and Plugins

If you run a WooCommerce store, you probably watch for WooCommerce updates. Good. This month's serious security news for WooCommerce stores did not come from WooCommerce, though. It came from PHP, the layer underneath. The layer on top, add-on plugins, carries its own risk, as an exploited flaw from earlier this year shows.

PHP is the language WordPress and WooCommerce run on. It is a hosting setting, and you cannot update it from the WordPress dashboard. Plugins are the opposite. They live in your admin area, and keeping them current is your job or your developer's. Updating WooCommerce alone covers neither layer.

On October 21, the PHP project released emergency fixes for two critical flaws that let an attacker run code on a server without logging in. Two days later it flagged a separate, much less likely issue that those fixes do not cover.

What happened with PHP this month?

The PHP project gave advance notice on October 20 of a security release set for the next day at 14:00 UTC, covering two critical flaws both rated CVSS v4.0 9.2. On October 21, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 shipped with fixes for both, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP project told every user to update immediately.

Researchers at Wiz named the vulnerabilities PHP2Shell. Remote code execution means an outsider can make your server run their commands, and these two flaws need no login.

The scale is why this matters. W3Techs puts PHP at about 70% of sites whose server-side language is known. Palo Alto Networks Unit 42 counted more than 22.6 million exposed PHP servers potentially at risk from these flaws.

Every PHP setup that serves web pages is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP 8.1 and older no longer get updates from the PHP project, though some Linux distributions and long-term-support vendors ship their own backported fixes, and the PHP project itself published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP from source. On the workarounds question, php.net was blunt: "There are no complete mitigations, updating is the only safe choice."

Attackers noticed. According to The Hacker News, Cloudflare saw attempts against the two flaws climb from tens of thousands within 45 minutes of disclosure to millions by early October 22. As of that report, researchers saw scanning and probing but no confirmed code execution.

What is the October 23 PHP advisory about?

On October 23 the PHP project posted an informational advisory about a new issue, CVE-2026-115560, which it called "an unlikely RCE vector." It can only happen when a site's configuration sets session.serialize_handler to php_binary or php_serialize, its code then switches that setting to php before starting a session, and session upload progress is still turned on.

PHP expects few sites to match all three conditions and is handling it in its regular release cycle. The Hacker News reported no attacks on it as of October 23. Until then, the PHP project recommends session.upload_progress.enabled=0. That same setting was already on the October 21 mitigation list, so a host that applied it then has nothing more to do.

Which PHP version is my store on?

You need the full version number. "PHP 8.3" tells you the branch but not whether the October 21 fix is in. Fixed means 8.5.12, 8.4.27, 8.3.36, 8.2.35, or anything newer on the same branch. If your host uses a Linux distribution's PHP packages, the number can be older and still patched, so ask the host to confirm the October 21 fixes are in. On 8.1 or older, plan an upgrade, since backported fixes exist only from some vendors.

WordPress shows the number under Tools, then Site Health, then Info, then Server. Your hosting control panel usually shows it too, or your host can tell you in one reply.

On October 23 we checked the six WooCommerce stores J.M. Field manages, using only what any visitor's browser receives. Two reported PHP 8.1 in their response headers, one of them 8.1.34. Whatever patches their hosts may carry, 8.1 no longer gets regular releases, so we are upgrading both. The other four keep their PHP version private, which is good practice because it gives an attacker less to go on. It also means nobody can confirm those four are patched from the outside, so we are confirming each one with its host.

Plan ahead if you are on 8.2. It reaches end of life on December 31, 2026, and gets no security fixes after that date.

Why a store is a bigger target than a brochure site

A plain brochure website is mostly text and images. A WooCommerce store is different. It holds your customer database, the login it uses to send email, and the secret keys that connect it to payment processing, accounting, shipping, and any CRM it syncs with. Because these flaws allow remote code execution, an attacker who exploits one runs their own commands on the server with the store's own access, so the exposure is not limited to the website. It can reach the files that hold those keys, and through them the other systems the store is wired to. That is why an unsupported PHP version matters more on a store than on a simple site: the store is one hinge on everything it connects to. As of late October 2026, The Hacker News reported that activity on the two flaws (CVE-2026-109618 and CVE-2026-109619) was scanning and probing with no confirmed code execution, and no public report shows the exposure chained into connected systems, but the safe assumption is that a store is only as protected as the software underneath it.

Can a single plugin put my store at risk?

Yes. Plugins sit on top of WooCommerce, each written by a different developer, and some get far more attention from attackers than others.

A clear example from this year is Woocommerce Wholesale Lead Capture by Rymera Web Co. Versions 2.0.3.1 and older have an unauthenticated file upload flaw, CVE-2026-27540, rated CVSS 9.0. Patchstack lists it as known to be exploited and puts the risk plainly: "Attackers can upload malicious files to the server, which can be used to take it over." The fix is version 2.0.3.2.

The dates matter here. The flaw was reported on February 20, 2026, and its CVE was published on March 19. If Lead Capture is installed, check that it is version 2.0.3.2 or newer. A store whose plugins have not been updated since the flaw became public in March may still be on a vulnerable version, and WooCommerce itself being current changes nothing about that.

Our check turned up one managed store running a wholesale pricing plugin from the same maker. Lead Capture did not show up from the outside, and we are confirming that from the admin side.

How do I check my plugins?

Start with the full list in Plugins, active and inactive. Deactivating a plugin does not remove its files from the server, so anything nobody uses should be deleted, not just switched off.

Look first at plugins that take files or sign-ups from strangers: wholesale applications, upload fields, registration and forms. Those are where an unauthenticated flaw does the most damage. Update everything you keep, and check whether each plugin's developer still ships updates.

The same pattern drove the WordPress attack wave we wrote about in July: a flaw that was already patched, with attackers scanning for the sites that had not updated.

What should I ask my host?

Send one message that covers both PHP items:

1. What is the full PHP version number running for my site, and does it include the October 21, 2026 fixes for CVE-2026-109618 and CVE-2026-109619?
2. Can you set session.upload_progress.enabled=0 in php.ini or the PHP-FPM pool until the next regular PHP release?
3. After that change, was every PHP worker restarted?

The wording in the second and third questions comes from php.net's own instructions for that setting: put it in php.ini, an FPM pool or the server configuration, not in a .user.ini file or with ini_set(), and restart every worker afterward.

If you are on 8.1 or older, ask for an upgrade plan with a date. Our September store checklist covers the other updates WooCommerce owners should be on this year.

What does J.M. Field do for the stores it manages?

We run PHP and plugins as two separate checklists. The PHP side is a hosting conversation: confirm the version, request the update, verify the restart. The plugin side is admin work: audit the list, update what stays, delete what does not.

If you would rather hand both layers to someone else, that is what our ecommerce web services are for.