How to Check Your Shopify Apps After the October Checkout Hijacks

In October 2026, shoppers on a number of Shopify stores clicked Checkout and landed on a payment page that looked right, showed the right basket and was not Shopify's. They had been sent there by an app the store had installed: Hulk Product Options from HulkApps, the Selleasy upsell app from Logbase, or Swym Wishlist Plus. In each case an attacker changed the app's settings, and the app delivered the attacker's code to the storefront.

This is a Shopify hack in the sense most merchants fear, but not in the way the word suggests. Nobody broke into Shopify's checkout. The attack happened on the store, one click before checkout, through code the merchant had invited in. That is good news, because it means there are checks you can run yourself. This guide explains what happened and walks through a ten-minute Shopify app security check for the apps on your own store.

The three incidents were made public within a few days of each other. None of the vendors has said how many stores were affected, and whether the three share a cause has not been confirmed. Here is what the vendors and the researchers who analysed the attacks have published.

The details differ per app, but the pattern is the same. Many storefront apps load a small script from Shopify's CDN, then ask the app's own server for the store's settings: labels, colours, rules and, in some apps, a field where the merchant can paste custom JavaScript or HTML. The attackers did not need to change the app. They changed the settings, and the app faithfully delivered them to every shopper.

In the HulkApps case, cside found a function that cancelled the real Checkout click and sent the shopper to a lookalike page on another domain. The fake page showed the real basket, took card and billing details, then forwarded the shopper to the genuine Shopify checkout. The order went through as normal, so neither the shopper nor the merchant had a reason to suspect anything.

Two details made it hard to catch. The redirect fired once per browser session and then went quiet, so a merchant who reloaded the page to check usually saw nothing wrong. And because it lived in configuration rather than code, the app itself still looked clean on inspection.

Shopify has spent the last few years closing the doors into its checkout. The checkout.liquid file and the additional scripts box on the Thank you and Order status pages have been retired, and script tags on those pages are switched off too. Apps now customise checkout through sandboxed extensions instead of arbitrary code.

That leaves the storefront, the product page and the cart drawer where the Checkout button lives, as the place third-party code still runs freely. It is also the place most merchants never look at closely, because the theme works and the apps were approved.

You do not need a developer for the first pass. Set aside ten minutes, open your Shopify admin in one tab and your storefront in a private window, and work through these four checks in order.

While you are in the admin, turn on two-step authentication for every staff account, remove staff and collaborator accounts that no longer need access, and change any password that has been shared by email or chat. Swym recommended the same steps to its merchants, even though its incident came through the app's access rather than staff accounts. They cost nothing and close the other common way in.

If you have a developer, ask them for one more check: open the browser's developer tools on your storefront and look at which domains the page loads scripts from and sends data to. Anything you cannot match to an app you know about is worth a conversation. cside also suggests looking in session storage for keys beginning with __ctf_, the marker the HulkApps payload left behind.

Collect evidence before you change anything: screenshots that show the address bar, the time, the page and device you were on. Then switch off the app's embed or uninstall the app, contact the vendor in writing, and open a case with Shopify Support. Tell your payment provider too, and take advice on whether you need to notify customers, which depends on where you and they are based.

Shopify has also added a safety net. Since 20 October, online stores block links to sites Shopify has identified as fraudulent and ask shoppers to confirm before leaving for a small number of higher-risk sites. If a customer tells you they saw that message, Shopify's advice is to ask which page they were on and what they clicked, and to review the apps you recently installed or updated and your theme code.

Passing Shopify's app review tells you an app met the platform's requirements on the day it was reviewed. It does not tell you how the developer protects the servers and admin tools that feed the app its settings every day after that. October was a reminder that both matter.

Before installing anything new, especially in the weeks before Black Friday, ask four questions. Which permissions does it request, and why does it need each one? Does it add to your theme through a theme app extension, which disappears cleanly on uninstall, or by editing theme files? Does it offer a field for custom code, and who can change it? And does the developer publish a status page or incident history, so you would hear about a problem from them first?

The lesson for developers is that the attack surface does not end at the code Shopify reviews. Settings that reach the storefront need the same care as code: escape every value before it is rendered, treat a custom JavaScript field as a privileged feature with its own access controls and audit log, and protect the internal tools that can change a merchant's configuration as carefully as production itself.