PHP2Shell Leaves Old-PHP WooCommerce Stores Without a Fix

The PHP project shipped fixes on October 21 for two remote code execution flaws known as PHP2Shell, but only for its four supported branches, PHP 8.2 through 8.5. A WooCommerce store still running PHP 8.1 or older gets no official PHP release, and WooCommerce has said it will not ship a plugin update because the bugs sit in PHP itself. Whether those stores are protected now depends on whether their hosting company has backported the fix, and WooCommerce’s next release is set to put that question in front of store owners.

The pressure grew on October 26, when the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its Known Exploited Vulnerabilities (KEV) catalog.

What the PHP project fixed on October 21

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix CVE-2026-109618 and CVE-2026-109619. The PHP Foundation rates both at 9.2 and credits researchers at Calif, Wiz and OpenAI with reporting them.

CVE-2026-109618 is memory corruption that occurs when a script hits its memory_limit at the wrong moment. On Apache with mod_php, the foundation says an unauthenticated request can trigger it before any application code runs, and full remote code execution was demonstrated with default settings. On PHP-FPM, code execution was confirmed through paths in application code.
CVE-2026-109619 involves stale global state that leads to a use-after-free bug. The foundation says code execution was demonstrated against a real application running on Apache mod_php.

The php.net security advisory says every PHP installation that serves web requests is at risk, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php carrying the highest risk.

Why the release came a day early

The fixes were scheduled for October 22 at 14:00 UTC. According to the PHP Foundation, the CVE identifiers began circulating publicly around 15:00 UTC on October 20, although no technical details leaked with them, and the release was moved up 24 hours. The embargo frayed further on the morning of October 21. The foundation says Calif mistakenly published a proof-of-concept video and that Chainguard broke the embargo at 07:41 UTC.

Ecommerce security firm Sansec wrote that Cloudflare reported early attacks two minutes later, at 07:43 UTC, several hours before the official packages were out.

Where PHP 8.1 and older stand

PHP 8.1 and every older branch no longer receive updates from the PHP project, and the advisory tells users on those versions to contact their vendor or upgrade. Some Linux distributions and long-term support vendors do provide backported fixes, and given the severity, the PHP security team published minimal source patches for PHP 7.4, 8.0 and 8.1 that packagers can apply.

Sansec says the flaws reach back to PHP 5.4. Its research page lists where backports can come from, including Ondřej Surý’s packages for Debian and Ubuntu, Ubuntu itself, Remi’s repository, CloudLinux, TuxCare and ZendPHP. It also notes that the official Docker php image has no fix for 8.1 or older.

That creates a practical problem for anyone trying to check a store. Sansec says patched distribution packages usually keep their original version number, so a server reporting PHP 8.1.34 may or may not include the fix. The firm suggests searching the package changelog for the two CVE numbers instead.

What WooCommerce has told store owners

In an October 21 advisory, WooCommerce’s Beau Lebens wrote that PHP2Shell is not a WooCommerce or WordPress vulnerability and that no WooCommerce or WordPress update is planned for it. Stores hosted by Automattic on WordPress.com, WordPress VIP, Pressable and WP Cloud were already protected, he said. Everyone else was pointed to Tools > Site Health > Info > Server to find their PHP version. The advisory notes that versions before 8.2 no longer get security updates from the PHP project, and WooCommerce recommends PHP 8.3 or newer.

WooCommerce is also changing what the plugin says on old servers. Pull request 70196, merged on October 23, brings an earlier change into the 11.3 release branch. It extends the admin notice already shown to stores on PHP versions below 8.1 with a line that reads “Your PHP version may also be affected by critical security vulnerabilities,” names the PHP version the store is running, asks the owner to confirm with their host, and recommends the latest PHP 8.3. The new copy also says hosts can backport fixes without changing the version string. WooCommerce 11.3 is still in beta, with Beta 2 published November 2 and the final release scheduled for the week of November 9.

The warning lands on a minimum that was already moving. WooCommerce’s minimum is PHP 7.4 today, and a September 29 advisory said WooCommerce 11.6, planned for February 2027, will require PHP 8.1 or newer, with 11.5 the last version to support older branches. WooCommerce counted about 7% of the stores it tracks on PHP 7.4 and 2% on PHP 8.0, from an opt-in sample. PHP2Shell means even the future minimum of 8.1 is now a branch with no official fix from the PHP project.

How much exploitation is happening

Agencies and researchers disagree on how urgent the threat is for a typical store. CISA’s alert, updated after the October 26 KEV listing, says organizations that cannot update right away, or that still run PHP 8.1 or earlier, should take PHP-based systems offline until they can be patched. It adds that a web application firewall may provide some protection in the meantime. WooCommerce’s advisory cites similar advice from the UK’s National Cyber Security Centre for self-managed servers.

The Hacker News has reported widespread exploitation attempts. It also reported that Perplexity researcher Adel Karimi recorded what appears to be the first successful exploitation in the wild, with commands on honeypot servers using wget, curl or the PHP command line to fetch more payloads. No second-stage files had been observed.

Sansec takes a calmer view. It says mass exploitation is less likely because the attack depends on specific conditions and knowledge of the target, and that one researcher found the public proof-of-concept code does not work against a default installation. Most of it needs a separate local file inclusion bug, according to Sansec, which tells merchants they do not need to take their stores offline. Sansec’s own page still relays Calif’s report that an attacker without a login could run code on WordPress 7.1.2 and Magento 2.4.9, so the threat to a store running vulnerable PHP is real even if mass attacks have not followed.

Stopgaps listed by PHP and Sansec

The php.net advisory describes three settings as partial mitigation only: memory_limit = -1, a low post_max_size, and session.upload_progress.enabled = 0. Sansec suggests blocking multipart/form-data requests at the web server as a temporary measure. It warns that the rule breaks file uploads, notes that some stores submit cart or checkout forms that way, and tells merchants to place a test order after adding it.

None of these replace a patched PHP build. For a high-risk merchant, a server takeover can expose customer records and checkout code, and EC4IM’s guide to WordPress hardening for high-risk WooCommerce checkouts covers the settings worth checking once PHP itself is fixed.

Questions for the hosting company

Store owners on shared or managed hosting usually cannot answer the backport question themselves. Useful questions to put to the host include:

Which PHP version and handler does the site use, mod_php, PHP-FPM or LiteSpeed?
Does the installed PHP package include fixes for CVE-2026-109618 and CVE-2026-109619, and where is that shown in the changelog?
If the site runs in a container, is it built on the official Docker php image for 8.1 or older?
When can the site move to PHP 8.3, ahead of WooCommerce 11.6’s PHP 8.1 minimum?

Old PHP versions after PHP2Shell

PHP2Shell was fixed upstream only for PHP 8.2 through 8.5. Stores on 8.1 or older are protected only if a host or vendor has backported the patches, and the version number on the server will not reveal whether that happened. CISA wants unpatched systems offline, while Sansec argues most stores face a narrower risk. WooCommerce is shipping no code fix of its own, but its 11.3 release is set to warn owners of stores on PHP below 8.1 and tell them to check with their host. For most merchants, getting a written confirmation of the fix and a date for the move to PHP 8.3 settles both the immediate exposure and the February 2027 deadline.

PHP2Shell Leaves WooCommerce Stores on PHP 8.1 and Older Without an Official Fix