Is My Online Store Safe? PHP2Shell and Customer Data (October 2026)

Your online store is probably safe if your host has installed the 21 October PHP fixes and your shop software is up to date. Don't assume it if the shop runs PHP 8.1 or older, sits on a server nobody manages, or you don't know who hosts it. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all out on 21 October 2026.

The big shared hosts moved fast. SiteGround applied the fixes on all its servers on 21 October, and Vodien says its shared Linux hosting is done.

The shops I'd check first:

• A shop on a VPS or cloud server that nobody has logged in to for years.
• A shop pinned to PHP 7.4, 8.0 or 8.1 because a plugin broke on anything newer.
• A Magento shop where the developer applies patches "when asked", and nobody asks.

If you don't know your version, my guide to checking your PHP version shows where to find the full number and how to read it.

With a hosted or embedded payment field from Stripe, PayPal or a similar provider, the card number travels from the customer's browser straight to the provider, and your shop gets back a token and the last four digits. Stripe's security guide says its low-risk integrations send payment details "directly to Stripe without it passing through your servers".

How your checkout is wired decides how much your server ever sees:

So a hacker in a typical WooCommerce shop on Stripe won't find card numbers in the database. The catch is the next section.

Credit card skimming on a website happens in the customer's browser: someone who gets into your site adds a script to the checkout page that copies what the customer types or shows a fake card form, then sends the details to the attacker. The industry calls these attacks Magecart.

A provider's iframe stops a script on your page from reading the real card fields. So the better skimmers don't try. They show their own form first. On 7 April 2026, Sansec reported that "nearly 100 Magento stores got mass-infected" with a skimmer that, when a shopper clicked the checkout button, "displays a full-screen modal overlay instead". The fake overlay took card details and a full billing form, then passed the shopper on to the real checkout. In Sansec's words: "Most victims never notice."

Singapore has its own case. The PDPC's decision on Fortytwo, an online furniture store on an unpatched Magento 1.9, found injected code had captured 6,241 customer logins and the card details of 98 people.

That's why PHP2Shell matters to shops whose cards sit with Stripe: an attacker who can run code on your server can edit your checkout page.

An attacker with access to your shop's server can take whatever its database and files hold: customer names, billing and delivery addresses, phone numbers, emails, order history and password hashes, plus the API keys your payment and email plugins save. On WooCommerce it all sits in the WordPress database.

• Customer and order records. Five years of trading can mean thousands of addresses and phone numbers.
• Password hashes. Scrambled, not plain text, but weak passwords can still be cracked.
• Payment gateway keys. To connect, the HitPay plugin for WooCommerce asks you to copy API keys and Salt values from your HitPay dashboard into WordPress, and Stripe's plugin stores its keys the same way. A stolen secret key lets someone act on your payment account through its API.
• Email and SMS keys, for messages that look like they came from your shop.

PHP2Shell adds one more route. One of the two bugs, CVE-2026-109618, can leak pieces of server memory back to whoever sent the request. Sansec says that memory "can contain passwords, session tokens, API keys and TLS private keys from other requests". So a shop that ran unpatched could have leaked a key without anyone ever logging in.

Sansec says every PHP shop is affected because the bugs sit in PHP itself, that mass exploitation now looks less likely than it first feared, and that the only real fix is updating PHP. Its PHP2Shell write-up says:

• "The flaws are in the PHP engine, so Magento, Shopware and WooCommerce stores are affected", even when the shop's own code is clean.
• It cites the researchers at Calif showing that an attacker without a login can run code on Magento 2.4.9.
• In an update on 22 October: "Mass exploitation of PHP2Shell is less likely than we expected on release day", and "The public exploits do not work against a default PHP installation."
• "You do not need to take your store offline."
• Its own store firewall, Shield, can't help, because the attack paths "run inside PHP, before your store code and before Sansec Shield". Its advice: "Do not wait for a Shield rule to protect you. Update PHP."

One thing Sansec doesn't say is "rotate your keys". That part is my advice, because of what it says the memory leak can contain.

On Shopify, Shopify patches everything underneath your shop. On WooCommerce and Magento, your host or developer patches PHP, and someone on your side has to update the shop software and plugins. That split is most of what WooCommerce security comes down to.

Shopify says it is "certified Level 1 PCI DSS compliant", the highest level. It has also locked down its checkout: per Shopify's help centre, the "additional scripts" box in checkout settings, where store owners used to paste code, has been view-only since 28 August 2025. WooCommerce has no such lock: anyone with an admin login can add a script to the checkout.

The clearest sign is a customer or their bank telling you their card was misused after buying from you. Before that happens, look for a card form that looks or behaves differently, admin accounts you don't recognise, and scripts in the checkout that nobody added. These are the checks I run on a shop:

• Place a test order on your phone. Watch for a card form that pops up over the page, asks for your card twice, or errors and then shows a second form. That's how the fake overlays behave.
• Check the admin list. In WooCommerce, go to Users and filter by Administrator. In Magento, go to System, then Permissions, then All Users. Anyone you can't name should go.
• Check where scripts get added. In WordPress, any "header and footer code" plugin. In Magento, Content, then Design, then Configuration, where the HTML Head and Footer fields accept code. Code you didn't put there is a red flag.
• Look at your payment dashboard. Small failed charges in a run, refunds you didn't make, or API keys you don't recognise all need explaining.

Free scanners catch known malware and blocklist warnings, but often miss a checkout page that only loads once something is in the cart. My roundup of free website security check tools covers what each one sees.

If you find something, stop and read my first-24-hours plan for a hacked site before you delete anything, because a skimmer removed without finding the way in usually comes back.

This week, confirm PHP is patched, update the shop software, clear out unknown admin accounts, test the checkout, and rotate your payment gateway API keys if the shop ran unpatched after 17 October. In this order:

1. Get the PHP version in writing from your host or developer: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or a vendor build that carries the fix.
2. Take a backup, then update WooCommerce or Magento, the theme and every plugin. Place a test order afterwards.
3. Remove admin users you don't recognise, and ex-staff. Turn on two-factor login for everyone left.
4. Test the checkout on your phone, as described above.
5. Rotate your payment gateway API keys. In Stripe, you roll the secret key in the Dashboard (Stripe's key best practices explain how). In HitPay, the keys sit under Settings, then Payment Gateway, then API Keys. Paste the new keys into the shop plugin and test again. Amazon logged a PHP2Shell attempt on 17 October, Tenable reports, so that's the date I count from.
6. Switch on payment alerts, sent to an inbox someone reads daily.
7. Change the other passwords: shop admin, hosting account and database, starting with any shared with a past developer.

If nobody on your side knows where these settings are, that's the work I do as part of my website maintenance service: the fix at a fixed price in writing, from SGD 850, covering the updates and anything they break.

PCI DSS is the card industry's security standard, and any shop that accepts cards has to follow it and confirm it once a year, usually by filling in a self-assessment questionnaire (SAQ) that matches how your checkout takes cards. If your checkout redirects to the provider's page or uses its iframe, you're usually on SAQ A, the shortest form. Since a 2025 revision, a shop with an embedded payment iframe must also confirm that page is "not susceptible to attacks from scripts", either with its own script controls or with written confirmation from its payment provider, as the PCI Security Standards Council explained in February 2025. If your site doesn't receive card data but controls how it reaches the provider, for example a form that sends the card straight from your page to the processor, that's SAQ A-EP, which is far longer. Card numbers on your own server put you in full scope, which no small shop needs. Your payment provider can tell you which form applies.

If you have credible grounds to believe customer data was taken, the PDPA gives you up to 30 days to assess whether the breach is notifiable and then 3 calendar days to tell the PDPC, and card numbers or logins with passwords count as significant harm however few people are affected. Two shop cases show where it ends up:

• Fortytwo: an unpatched Magento 1.9 shop, injected code, 6,241 logins and 98 people's card details captured. Fined S$8,000 and directed to upgrade.
• Goldheart Jewelry: a Magento patch released in February 2022 went on 11 months later. The data of 41,379 customers ended up on a forum. Fined S$58,000.

Hiring a vendor doesn't move the duty off the business. My guide to your PDPA data breach duties after a hack walks through the assessment, the deadlines and what to tell customers.

No, not if PHP is patched. Sansec says stores don't need to go offline, though the US agency CISA advises taking PHP systems that can't be patched offline until they are. CISA's alert is aimed at systems on PHP 8.1 or older with no fix in sight. For a shop in that position, with customer data on it, I'd follow CISA: a holding page with your WhatsApp number for a few days costs less than a breach.

WooCommerce is safe enough for a small shop when someone updates PHP, WordPress and the plugins every month. If nobody will, a hosted platform like Shopify takes the patching off your plate, in exchange for monthly fees and less control. The shops in trouble this week are the ones nobody has touched since launch.