Shopify Security: The Risk Lies Elsewhere

On the Shopify security front, the October 2026 PHP2Shell vulnerability does not affect your store: Shopify does not run on PHP, and there is nothing you need to update on your end. The real risk of the month lies elsewhere. Between October 10 and 20, attackers hijacked at least three third-party apps to redirect shoppers to fake checkouts and steal their credit card details, without ever touching the platform. A Shopify store's security is therefore no longer about the server; it's about your app list. Article updated on October 28, 2026.

In short

• PHP2Shell vulnerability: two critical vulnerabilities (rated 9.2 out of 10) in PHP itself, patched on October 21 and now being exploited by attackers. They threaten any unpatched PHP server, including WordPress, WooCommerce, PrestaShop, or Magento sites that have not been updated.
• Your Shopify store: unaffected. The core of Shopify is based on Ruby on Rails, Liquid handles rendering, and Shopify manages its own servers.
• What still needs checking: your third-party apps, custom connectors, and any auxiliary sites (WordPress blog, booking tool) that may run on PHP.
• The real Shopify incident of October: three developers (Hulk Product Options, Selleasy, Swym Wishlist Plus) confirmed that a third party had injected a script into their app that redirected users to a fake checkout.
• The Shopify checkout held: the attack ran on the store, one click before payment.
• Our agency's position: every installed app is a service provider that holds the keys to your storefront. Fewer apps, more native features, and a checkout test in incognito mode with every alert.

October 2026: two incidents, not one

Two stories collided in the same week, and most of the alerts you have read mix them up. On one hand, a vulnerability in the PHP language, which runs a large part of the web. On the other, a hacking campaign targeting Shopify apps. They have neither the same cause, nor the same victims, nor the same solutions. Separating them is the first step to knowing what you really need to do.

The PHP2Shell vulnerability: a flaw in the engine, not in your site

On October 21, 2026, the PHP team urgently released patches for two critical vulnerabilities, referenced as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell. Both are rated 9.2 out of 10 and allow an attacker to execute code on a server without credentials or a password. They were discovered in mid-August by researchers from Calif and Wiz, with the help of artificial intelligence models.

The timeline explains the concern. The vulnerability identifiers leaked the day before the patch, Amazon detected an initial exploitation attempt as early as October 17, four days before publication, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added PHP2Shell to its catalog of actively exploited vulnerabilities on October 26, following confirmed cases of code execution.

The key point for an e-commerce merchant: the vulnerability is in PHP itself, not in WordPress, WooCommerce, or PrestaShop. Updating your CMS or modules does not fix anything. Only updating PHP on the server to 8.2.35, 8.3.36, 8.4.27, or 8.5.12 closes the door. Versions 7.4, 8.0, and 8.1 received only minimal source code patches, and older versions received nothing at all.

App hijacking: a fake checkout one click before the real one

On October 10, a German developer, Roman Zipp, bought a keyboard on a Shopify store. He clicked "Checkout" and landed on a payment page that looked exactly like a Shopify checkout, but was hosted on an unknown .top domain. He traced the path back to an app installed on the store: Hulk Product Options.

In the following days, three developers confirmed an incident on their end:

• Hulk Product Options (HulkApps), on October 10: an unauthorized configuration injected into the app's theme extension.
• Selleasy (Logbase), on October 13: a third party accessed the developer's internal tool and added a script to the "Custom JS" setting of several stores.
• Swym Wishlist Plus, on October 14, then a second wave on October 18 that used the app's own access. Swym suspended its app for all merchants, revoked its Shopify access on October 20, and has been restoring service in stages since October 23.

The method is formidable. The fake page collects the buyer's name, address, and card, then sends them back to the real checkout so they can pay normally. The order goes through, your back office shows nothing unusual, and neither does your conversion rate. The script only triggered once per browsing session: a merchant testing their own checkout twice saw a perfectly clean page the second time.

"Every installed app is a service provider that holds the keys to your storefront. The wishlist is the best example: on a store with a limited catalog, we advise against it because it brings little in sales for a lot of code loaded on every page. In October, it was precisely a wishlist app that served as the entry point."

Volkier Bentinck, co-founder of Stellar Projects

Does Shopify use PHP?

No, not to run your store. The core of Shopify is developed in Ruby on Rails, your pages are generated with Liquid, Shopify's templating language, and the platform hosts and updates its own servers. There is no version of PHP to patch in your admin. As of October 27, Shopify had not published any statement on PHP2Shell, which is consistent: the platform has nothing to patch on this front.

The complete answer is more nuanced, because PHP has not disappeared from the ecosystem surrounding your store. Shopify has even been publishing an official package since August 26, 2026, for developing apps in PHP, compatible with Laravel and Symfony. Each app developer chooses their technology, and some openly admit it: Qikify confirmed that its apps run in PHP on its own servers, and patched them in the days that followed.

If you have kept a WordPress blog alongside your store, that is what you need to check this week, not Shopify. Our comparison Shopify or WordPress reviews what each solution leaves in your hands.

Shopify security: the real risk comes from apps

What October showed is that the attack surface of a Shopify store has shifted. The server is well guarded by Shopify. Apps, however, inject code into each of your pages, and this code depends on the security of their developer. This is a finding we have shared with our clients for a long time, first for performance reasons, now for security.

How the malicious code got in

Apps add code to your store via "app embeds", enabled in the theme editor. This code is served from Shopify's CDN, and in the case of HulkApps, the file itself had not changed by a single byte. The malicious part arrived in the form of configuration data, loaded from the developer's servers at each page view, then executed in the buyer's browser.

Direct consequence: a search in your theme files would have found nothing. The "clean" code audits of mid-October proved nothing. Only a real test of the purchase journey, in a new browsing session, allowed you to see the redirection.

Why the checkout held, and why that was not enough

The Shopify checkout was never compromised. The extensions that customize it run in an isolated environment, without access to the page or payment data. This is a real protection, and that is why attackers did not target it. They simply intercepted the click on the "Checkout" button, on the store, before the buyer reached this protected space.

Remember the nuance: Shopify secures the payment, not what your apps do on your product pages and in your cart. That area falls under your app choices. Our selection of Shopify apps that really pay off is part of this principle of sobriety.

What Shopify changed after the hacked apps

To our knowledge, Shopify has published neither a list of affected apps nor the number of stores involved. A spokesperson stated on October 17 that the platform could remove an app from the App Store to protect merchants. But the reaction was mainly seen in its release notes.

• October 15: new command shopify app security check in the CLI, which allows developers to analyze their app for the most common vulnerabilities.
• October 20: Shopify asks all app developers to act "this week": security analysis, switching to expiring access tokens (soon mandatory for public apps), two-factor authentication everywhere, API log review. The platform also announces a tightening of rules for the code that apps load on stores.
• October 20 then 23: new protection against unexpected redirects. Since the October 23 update, your store blocks links to sites that Shopify has identified as malicious and asks the buyer for confirmation for suspicious sites. Other links work normally, and domains connected to your store do not trigger a message.

A point of vigilance on the numbers circulating: Revenue Shield, developer of a checkout monitoring solution, counted 478 apps removed from the App Store between October 14 and 22. Shopify has neither confirmed this number nor explained most of these removals, and a removed app is not necessarily a hacked app. Conversely, a removed app continues to run on the stores that had already installed it: the removal does not automatically protect you.

Shopify, PrestaShop, WooCommerce: who patches what?

PHP2Shell made visible a difference that we forget when everything is going well: on a hosted platform, the platform patches; on a self-hosted solution, someone has to do it, and quickly. WooCommerce like PrestaShop reminded as early as October 21 that no update to their software patched the vulnerability.

To be fair, PHP2Shell does not justify changing platforms on its own. A responsive host deployed the patch in the days that followed. But a PrestaShop store that remained on PHP 7.4 received only a minimal source code patch, and the upgrade becomes an imposed project instead of being planned. Our analysis PrestaShop or Shopify quantifies this maintenance cost, and our migration guide to Shopify details how to switch without losing your SEO.

Check your store in 30 minutes

Here is the check we recommend to the stores we support. It requires no technical skills for the first five steps.

1. Test the purchase journey in a new session. Open an incognito window, on mobile then on computer, add a product and click "Checkout". The address must remain on your domain or on a Shopify domain. Close the window between two tests: the October script only triggered once per session.
2. List your app embeds, not just your apps. In the theme editor, open the app integrations tab and note everything that is active. That is where the code of the apps enters your pages.
3. Uninstall what is no longer useful. An installed and forgotten app remains an open door. Also check that no script remains after uninstallation.
4. Re-read the permissions of each app. A wishlist app has no reason to be able to modify your orders or your theme files. If the requested rights exceed the usage, replace the app.
5. Audit the collaborator accounts. Remove access from former service providers and enable two-factor authentication on all accounts, including those of your apps when they have their own interface.
6. Inventory your PHP components. Blog, landing page, ERP connector, booking tool: ask your host or your agency in writing the version of PHP used and the date of the PHP2Shell patch.
7. Question the developers of your critical apps. One question is enough: "Does your app run in PHP, and is the PHP2Shell patch applied?" A serious developer answers clearly and quickly.

If you find a redirection

Immediately disable the suspicious app embed in the theme editor, notify Shopify support and the app developer, then check in with your payment provider and your advisor on your notification obligations, especially with the CNIL if personal data may have been collected. On the support side, our article on Shopify support explains how to get a quick response.

Fewer apps, more native: our position

Our conviction does not date from October, but October gives it one more argument. Before installing an application, we always check if Shopify does not already do the work natively. Very often, a Shopify Flow workflow, metaobjects, or a Shopify Function replaces a paid app, without adding a line of third-party code to your pages.

Same logic for backups: we do not recommend a backup app on Shopify. The platform manages the availability of your data, and when a full export is useful, Matrixify does it occasionally, without permanent access to your store.

Concretely, three rules guide our recommendations:

• Native first. A Shopify feature only depends on Shopify's security.
• One app, one measured use. If no one can say what an app brings, it must go.
• An annual review of the app fleet, just like a review of your supplier contracts: who has access to what, and why.

This is also what our Shopify maintenance plan covers: monitoring, streamlining, and testing, rather than piling on.

Review your store

Do you know how many apps are actually running on your store, or which ones have access to what? This is exactly the type of audit we conduct for our clients, providing a clear list of what to keep, replace, or remove. Let's talk about your store-we'll respond within 24 hours.