In short: After PHP2Shell, WooCommerce security depends first on the server's PHP, not on the shop plugin. A shop holds customer data, orders and access to payment providers, so the PHP patch alone is not enough. Also check the checkout code, REST API keys and webhooks.
What PHP2Shell means for a WooCommerce shop
WooCommerce is a plugin for WordPress and therefore runs on the same PHP. According to the PHP team, the flaws CVE-2026-109618 and CVE-2026-109619 allow remote code execution without authentication. For a shop this is more serious than for a brochure website, because more is at stake:
- Names, delivery and billing addresses, phone numbers and email addresses
- Order history and customer accounts with password hashes
- API keys and secrets for the payment, shipping and accounting integrations, stored in the database
- Downloads of digital products in the folder
wp-content/uploads/woocommerce_uploads/
With embedded payment forms from the providers, card data is usually not stored in the shop. An attacker with server access can, however, modify the checkout JavaScript so that entries are read before they are submitted. General advice for merchants can be found under IT security for online shops.
WooCommerce security starts with the PHP version
Under WooCommerce > Status, the system status shows, in the section on the server environment, the PHP version the shop is actually running on. Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Hosts often apply fixes as a backport, though, in which case the displayed number stays old. Rely on the host's written confirmation and on the restart of all PHP processes instead.
Which PHP versions your WooCommerce version supports can be found in the manufacturer's system requirements on woocommerce.com. A switch to a newer major PHP version should be made in a test environment, because payment plugins may otherwise fail unnoticed.
Where attackers target WooCommerce shops
Besides the well-known WordPress hiding places, there are shop-specific spots:
- Template overrides in the theme: the folder
woocommerce/checkout/in the active theme. Files changed here act directly on the checkout and the order confirmation. - Payment plugins: modified files in the payment provider's folder under
wp-content/plugins/. - REST API keys: under WooCommerce > Settings > Advanced > REST API. A foreign key with read or write permissions is a backdoor without a file.
- Webhooks: under Advanced > Webhooks. An unknown webhook can send every new order to a foreign address.
- Roles: new accounts with the role "Shop manager" or "Administrator".
- Logs:
wp-content/uploads/wc-logs/can contain personal data and should not be publicly accessible.
Harmless checks on the command line:
# List administrators and shop managers
wp user list --role=administrator
wp user list --role=shop_manager
# Show PHP files in the theme changed since 17 October 2026
find wp-content/themes -name "*.php" -newermt "2026-10-17"
A PHP patch deletes neither a foreign REST API key nor an injected webhook. Both keep working after the update. Check the lists actively and, if in doubt, renew the API keys with your payment providers.
Extensions and shop updates: what they do and what they do not
A typical WooCommerce shop uses many extensions: payment methods, shipping labels, invoicing, marketplace connections, review and marketing plugins. Each of them is additional code with its own flaws and often with its own access to external services. Keep the list short and remove test installations of old payment methods.
An update of WooCommerce or WordPress closes known bugs in these components. It does not repair PHP, does not remove foreign files outside the plugin folder and does not delete database entries such as API keys or webhooks. How to tell whether something has already happened is described in Have I already been compromised?.
If the PHP update from your host is still pending, a filter placed in front of the shop can buy time. It does not replace the patch; more on this under WAF and virtual patching.
Obligations after an incident in the shop
If customers' personal data is lost, a report to the data protection authority within 72 hours may be necessary. This is general information, not legal advice. Involve your data protection officer early and read our overview of the GDPR reporting obligation. Also observe your payment providers' requirements for security incidents.
After every intervention, test a complete order process with all payment methods you offer. Watch for unusual intermediate steps, additional input fields or redirects to foreign domains. The browser's developer tools show which scripts are loaded from which addresses; unknown sources on the checkout page are a warning sign. Document the test with date and result.
How does PHP SOS help?
- Together with your host, we clarify the PHP patch level and have the restart of all PHP processes confirmed.
- We secure logs, database and files before we change anything.
- We check checkout templates, payment plugins, REST API keys, webhooks and user roles.
- If we find something, we clean up the shop, renew access credentials together with you and document the process for data protection and insurance.
Frequently asked questions
Are credit card details in WooCommerce at risk because of PHP2Shell?
That depends on how the payment provider is integrated. If cards are captured in a form hosted by the provider, they are usually not stored in the shop. However, an attacker with access to the server can modify the checkout so that entries are captured beforehand.
Where do I see the PHP version in WooCommerce?
Under WooCommerce > Status, in the section on the server environment. The number shows the version the shop is running on. It does not tell you whether a backport has been applied; your host has to confirm that.
Why should I check the WooCommerce webhooks?
Webhooks send data to a registered address when events such as new orders occur. A secretly created webhook can send order data to third parties permanently, even after PHP has been patched.
Do I have to inform the payment providers if I suspect an incident?
If your suspicion is well founded, you should renew API keys with the provider and follow its requirements for security incidents. Whether reporting obligations apply is something to clarify with your data protection officer or lawyer.