PHP2Shell for Online Stores: WooCommerce, Magento and PCI DSS

As of 23 October 2026, the PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, attackers are widely reported to be trying them, and no confirmed successful break-in has been publicly documented. If your store runs WooCommerce, Magento Open Source, Adobe Commerce, PrestaShop or OpenCart on a server, the PHP underneath it has to be updated and restarted. Updating the store software or its extensions does not fix it.

If you sell on a fully hosted platform such as Shopify or BigCommerce, the platform runs the servers. Your job is to check anything you run outside it, such as a custom PHP app, a feed tool or a WordPress blog on separate hosting.

Stores hold customer accounts and payment gateway keys, and PCI DSS has rules for the scripts on payment pages. This guide covers what store owners need to do this week.

Which Stores Need to Act

What matters is who runs PHP for your store.

BigCommerce says it "found no evidence of exploitation affecting Commerce systems or customer data," and tells merchants: "If you run your own PHP applications, please review any custom PHP solutions, check your third-party integrations for exposure, and apply the PHP patches as soon as possible." See its trust center. Our Shopify security guide covers the parts of a hosted store that stay with you.

What the Store Platforms Have Said

• WooCommerce (developer blog, 21 October 2026): "These vulnerabilities are not specific to WooCommerce or WordPress and affect any server that hosts a PHP application. No WooCommerce or WordPress update is required or planned for these issues." Read the WooCommerce post, or our WooCommerce and PHP2Shell guide.
• PrestaShop (21 October 2026): "Updating PrestaShop or your modules will not fix this. There is no PrestaShop patch to install." It also says security measures "in PrestaShop or in modules, cannot block it." See the PrestaShop announcement.
• Magento and Adobe Commerce: no Adobe statement could be found as of 23 October 2026. Calif lists Magento 2.4.9 among the apps where it "confirmed pre-auth RCE," meaning remote code execution without logging in. Our Magento and Adobe Commerce guide has the details.
• OpenCart: no statement found as of 23 October 2026. It runs on PHP like the others, so the same fix applies.

Old PHP: The Problem Stores Run Into Most

Stores often stay on old PHP because store upgrades are expensive. PHP 8.1 and older get no official PHP release, only source fixes that some Linux distributions and paid support vendors turn into patched packages.

Adobe's system requirements (last updated 13 October 2026) show where each Magento release stands:

PrestaShop 8.0 to 8.2 support PHP 7.2 to 8.1, and 1.7.8 supports 7.1 to 7.4, so only PrestaShop 9.x runs on a branch with official releases. PrestaShop warns that upgrading "is not an emergency fix ... you should not rush a major upgrade." Get a patched PHP build for the version you run first. WooCommerce recommends PHP 8.3 or newer but still allows 7.4. Our fixed versions guide explains where backported builds come from.

A version number alone proves nothing either way, because Linux distributions add fixes without changing it. Our guide on how to check your PHP version covers how to confirm the actual build. In WooCommerce, the version shows under Tools > Site Health > Info > Server. In PrestaShop, it is under Advanced Parameters > Information.

Payment Gateway Keys and Customer Data

Many stores never see a full card number, because the gateway's hosted fields or redirect page collect it. Your server still holds gateway API keys, webhook secrets, database passwords and customer accounts. Wiz, one of the research teams, describes a memory leak where leaked memory "may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself." Beazley Security advises teams to "treat secrets held by an affected PHP process as potentially exposed" when investigating.

A practical approach:

• If your store was on unpatched PHP and you see any sign of compromise, rotate the gateway API keys and webhook secrets in your gateway dashboard, then update them in the store.
• Change the store's database password and any cloud or email service credentials kept in its configuration.
• Remove admin accounts you don't recognize.

PCI DSS v4.0.1: Why an Unpatched Server Matters

PCI DSS is the card industry's security standard, and v4.0.1 is current. Since 31 March 2025, requirement 6.4.3 covers the scripts on payment pages and 11.6.1 covers detecting tampering. The PCI Security Standards Council says they are about "ensuring that payment page scripts are properly authorized, checked for integrity, and monitored for tampering." This is the e-skimming problem: someone adds a script to your checkout that copies card details as customers type.

The link is direct: an attacker running code on your server can change the files your store serves, including checkout templates. A store left on unpatched PHP will struggle to show that its payment-page scripts are authorized and untampered. Ask your assessor how PCI DSS's general patching requirements apply to your environment.

If you file SAQ A, the shortest self-assessment for stores that outsource payment pages, 6.4.3 and 11.6.1 were removed from it in January 2025. In their place, merchants must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." The Council says this does "not remove or diminish the underlying re[quirements]." See the PCI SSC's SAQ A update.

The Council also says it "does not enforce compliance or determine whether specific implementations are compliant." Your acquiring bank or a Qualified Security Assessor makes that call. This is general information, not legal or compliance advice. Our PCI DSS 4.0 website guide covers the script requirements in full.

Interim Steps That Won't Break Your Store

If PHP can't be updated today, PHP's advisory lists settings that make the known attacks harder. Our interim mitigations guide covers each one. For stores, three cautions:

1. Upload limits affect store features. PHP suggests a low post_max_size (8M without uploads, 32M with). PrestaShop warns this can break "product images, catalog imports, module and theme installation, and any third-party module that accepts uploads."
2. Blocking multipart requests can break checkout. Sansec says a rule that blocks multipart form data "breaks file uploads, such as product images in the Magento admin. Some stores submit cart or checkout forms as multipart, so place a test order after you add it."
3. Don't rely on .htaccess. WooCommerce's requirements page suggests adjusting PHP settings in .htaccess. For PHP2Shell, settings applied per request are part of the problem. PHP's advisory says to remove invalid or deprecated settings that emit warnings before initialization. Put mitigations in php.ini or the PHP-FPM pool, where they apply to the whole server.

The safest single setting for most stores is session.upload_progress.enabled=0, which only switches off PHP's built-in upload progress bars. PHP advised on 23 October 2026 to keep it off until the next regular release because of a related issue, CVE-2026-115560, that affects even patched builds. Restart every PHP worker after any change. A web application firewall (WAF) helps, but PrestaShop warns that if your server can be reached directly by IP address, "an attacker can bypass the WAF entirely."

Should You Take the Store Offline?

Downtime costs sales, but official advice is clear for one case. CISA said on 21 October 2026 that organizations "that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." WooCommerce gives similar advice to self-managed stores on old PHP.

Sansec takes a different view: "You do not need to take your store offline." That is one vendor's risk assessment. The government advice is CISA's. If you do go offline, Beazley's advice is to use a maintenance page or network restriction "rather than disabling the PHP handler, which can expose application source code and credentials." For a store, that could mean your gateway keys.

A Store Owner's Checklist for This Week

1. List every place your store runs PHP: the store, staging copies, a blog, feed tools and any old store never shut down.
2. Find out who patches PHP for each. If it's your host, ask in writing: "Has the fix for CVE-2026-109618 and CVE-2026-109619 been applied to the PHP running my store, and were PHP workers restarted?"
3. If you manage the server, update PHP from your distribution or vendor, restart PHP-FPM or Apache, and rebuild any container images.
4. If you are on PHP 8.1 or older, get a patched vendor build now and plan the store upgrade as a separate project.
5. Turn off session upload progress and place a test order.
6. Check for signs of compromise going back to at least 17 October 2026, the earliest reported exploitation attempt: new admin users, changed checkout or template files, unfamiliar PHP files. Our "was my site hacked?" guide walks through it.
7. If anything looks wrong, rotate gateway keys and call your payment provider.

Conclusion

For an online store, PHP2Shell is a server problem with checkout consequences. The store software doesn't need a patch; the PHP under it does. Self-hosted stores need the PHP update confirmed, old branches dealt with and gateway keys protected. If you need help patching PHP on a store server without breaking checkout, our emergency PHP patching team can work with your host or developer. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions