A critical flaw in PHP put most online stores on alert this week. Here’s how hosts, platforms and security firms have responded, and what they’re advising retailers to do.
On Wednesday 21st October, PHP released emergency fixes for two serious security flaws. PHP is the software that runs underneath most online stores and builds each page when a shopper visits. It powers roughly 70% of the world’s websites, according to the BBC. WooCommerce, Magento, PrestaShop and Shopware all run on it.
The flaws, nicknamed php2shell, let an attacker take control of a web server without logging in. Governments from the UK to Japan urged website owners to update immediately, and some took their own sites offline as a precaution.
We’re an SEO and digital marketing agency, not a security firm. So rather than add another opinion, we’ve rounded up what the hosts, platforms and security specialists have actually said and done, with links so you can read it from them directly.
Hosts and firewalls moved first
The fastest response came from the companies that sit between stores and the internet.
Cloudflare switched on protection for every customer, including free plans, about nine hours before the flaws were made public. It says it watched attackers change their methods to try to get past its rules, and it’s clear the protection is a backstop, not a fix. It still tells customers to update PHP.
Hosting companies followed within hours. According to a tracker from Top Site Hosters, SiteGround and Automattic (which runs WordPress.com) had protection in place before the fix was even released. Hostinger, Kinsta and WP Engine blocked known attacks first, then rolled out the updated PHP over the following hours.
The slower end was budget shared hosting, where some providers relied on temporary protections while waiting for their own suppliers. For many retailers on managed hosting, the problem was handled before they’d heard of it.
Platforms: some spoke up, some stayed quiet
The e-commerce platforms themselves were more mixed.
WooCommerce owner Automattic was quickest, telling customers on its own hosting that they were already protected. It also made the point many retailers missed: updating WordPress or your plugins doesn’t fix this, because the flaw is in PHP underneath.
PrestaShop published guidance for merchants, advising them to get written confirmation from their host and to plan an upgrade if they’re on an older version.
Adobe, which owns Magento, had published nothing specific as of 22 October, according to several Magento agencies. That matters, because on Adobe Commerce Cloud it’s Adobe that controls the PHP version, not the merchant.
BigCommerce, now trading as Commerce, doesn’t run stores on PHP that merchants manage. It still posted a notice on its Trust Center confirming it was patching its own systems, and told merchants that only those running their own custom PHP integrations need to act.
Shopify had not said anything publicly as of 22 October. Its core platform doesn’t run on PHP, so there’s nothing for merchants to patch on the store itself. The risk sits with the third-party apps many stores rely on, which run on their developers’ own servers, and some of those use PHP.
Shopify’s app developers filled the gap. Avada told customers its apps don’t use PHP, Qikify, whose apps do run on PHP, said every one was patched by the morning of 22 October, and Cleverific said it had checked that its own suppliers were either free of PHP or protected.
Security firms disagree on how bad it will get
Attackers were clearly trying. Cloudflare and Amazon both saw attempts before the fixes were released, and The Register reports Amazon spotted one as early as 17 October. Amazon now says the flaws are being broadly exploited.
Others are more measured. Sansec, which specialises in online store security, said on 22 October that mass attacks look less likely than it first feared, because the public attack tools don’t work against a standard PHP setup. Security firm Huntress said it hadn’t confirmed a single successful attack on a live customer system.
Both views can be true at once. There’s a huge volume of attempts, and whether any succeed depends on how each server is set up. That’s why every expert source we read lands in the same place: confirm your store has been updated, rather than assume it has.
What the experts are telling retailers to do
Across the sources above, the advice is consistent. We’ve summarised it here, but please follow your host’s and platform’s own guidance first.
Confirm the update, in writing
Ask whoever runs your server: which PHP version is our store running, and has it been updated and restarted since 21 October? A clear answer names a fixed version, such as 8.3.36, and a date. Some hosts install patched builds that keep an older version number, so if the number looks lower, ask them to confirm it’s a patched build. Updating your store software or plugins doesn’t count.
Don’t rely on maintenance mode
Sansec warns that Magento’s and WordPress’s built-in maintenance modes don’t stop the attack.
Check what’s connected to your store
On Shopify, Qikify suggests asking each app developer whether they use PHP and have patched, rather than uninstalling apps in a hurry.
Look for forgotten sites
An old blog, landing page or pre-migration store under your domain can still be running unpatched PHP.
Plan ahead if you’re on an old version
Rigby notes that some older platform versions, such as Magento 2.4.5 and earlier, can’t run any PHP version with an official fix. Those stores depend on patched builds from their host until they upgrade.
The UK’s National Cyber Security Centre also advises considering taking a site offline if it can’t be updated quickly. That’s the one part of this where we can add something from our own experience, which is how to do it without damaging your search rankings.
What it means for your visibility
If your store does need to go offline, how it goes offline matters for search.
- A maintenance page that returns a 503 status code tells Google the outage is temporary. A day or two offline this way is unlikely to do lasting damage.
- A blank page, an error or a homepage redirect can look like your product pages have disappeared. Leave it long enough and they can start dropping out of the index.
The bigger risk to your visibility is being compromised. A hacked store can end up serving spam pages or redirects, and Google may warn shoppers away from it in search results. Recovering from that takes far longer than a planned 503.
Expect one more argument in the coming weeks. Some agencies are already using this to make the case for moving off PHP. That’s a fair conversation, but not one to have in a panic. No technology is free of security updates. Node.js, one of the alternatives being suggested, released its own high-severity fix the same day.
First, make sure your store is updated, your apps are accounted for, and any downtime is handled in a way that protects your search rankings.
