The Checkout Hijack: Shopify Locked Down Checkout, So Attackers Built a Fake One

On October 10, a developer named Roman Zipp put a mechanical keyboard in his cart on a Shopify store, clicked checkout and landed on a page that looked exactly like Shopify checkout. His password manager then offered to fill the first-name field with the name on his credit card, which was odd enough to make him read the address bar: the page sat on a look-alike domain, biliing.top. Within days the same checkout hijack surfaced through three Shopify apps, and the developers of all three, HulkApps, Selleasy and Swym, confirmed that attackers had changed their apps' settings to send shoppers to fake payment pages.

The fake page was built not to be noticed. It copied the shopper's real cart, took the card details, showed a payment error and then forwarded the shopper to the genuine checkout, where the order went through as usual. The merchant saw an ordinary order, the shopper saw a small glitch, and the card number was gone.

There is an irony in where the attack landed. Shopify spent the past two years closing its checkout to outside code, and nothing so far suggests that Shopify's own checkout was breached. So the attackers moved one click earlier, to the button that leads there. This post covers how the hijack worked, why the order data hid it, what Shopify has changed, and the checks every Shopify merchant should run before Black Friday.

1. How the Checkout Hijack Worked

The attack did not need to touch a single theme file, which is why it was so hard to see. Many storefront apps let a merchant add custom JavaScript or HTML in the app's own settings, and the app then serves that code to every visitor alongside its own. In the Hulk Product Options case, Zipp traced the redirect to about 22.7 KB of attacker code returned by the app's own server under a custom JavaScript setting. A merchant comparing theme files would have found nothing, since the code arrived as app data on each page load.

Once loaded, the script waited for the shopper to click checkout, and it fired only once per browser session. It set a flag in session storage after the first redirect, so a merchant who tested the store in the same tab saw the normal checkout every time. The destinations were short-lived look-alike domains such as checkout-confirm.top and billing-confirm.top, most of which were not yet on the blocklists that browsers and security filters use.

The fake page itself was convincing because it used the shopper's own data. It showed the real products, quantities, totals and currency from the cart, and it looked enough like Shopify checkout that a mismatched logo was the main giveaway. After the shopper entered a card, the page sent everything to the attackers, reported a payment problem and passed the shopper on to the store's real checkout to pay again. Most shoppers would read that as a hiccup and finish the order.

2. Three Apps in Five Days, and a Pattern Going Back to July

The October wave moved fast. Hulk Product Options was first, on October 10, and Shopify pulled the code from the store Zipp found about 70 minutes after he made contact, then disabled the app's theme extension while HulkApps cleaned up. Selleasy followed on October 13, when its developer, Logbase, says an intruder reached an internal tool and planted a script in some stores' settings between 07:47 and 15:00 UTC. Swym Wishlist Plus came next, with its configuration changed for almost two hours on October 14, and a second wave on October 18 used the app's own Shopify access, which led Swym to switch the app off for every merchant.

None of this was entirely new. The developer of one app reported the same technique in July, and in September another developer found malicious custom code that redirected shoppers to a fake checkout for up to eight and a half hours before it was removed. Each company described a different way in, whether an exploit, an internal tool, a configuration channel or a stolen credential. One developer added a warning that deserves attention: credentials now leak from more places than before, including AI coding assistants and agents connected to codebases and stores with broader permissions than they need. Shopify made a similar point when it wrote that attacks are increasing "as AI gets better at finding vulnerabilities".

The human cost is easiest to see in one small business. WAGD, an Australian maker of dog harnesses, learned of the attack from a suspicious customer who had landed on the fake checkout and sent the owner the link. Shopify advised her to keep the store closed while it investigated, and it stayed shut for roughly six days in the middle of the fourth quarter. Merchants have also reported redirects on stores that run none of the named apps, so the list of affected apps may not be complete.

3. Why the Order Data Looked Normal

The cleverest part of the attack is that the store kept selling. Because the shopper was handed back to the real checkout, the order arrived with a real customer, a real address and a card that genuinely belonged to the buyer. Conversion rate, average order value and order-level fraud screening all saw a legitimate purchase, because it was one. The theft happened a step earlier, in a place none of those measures can see.

That shifts the damage onto the customer and, later, onto the brand. A shopper whose card is misused weeks after buying from a store will remember where they last typed it, and few will blame an app they have never heard of. Trust at checkout was already fragile: in Baymard's research, 19% of US shoppers had abandoned a checkout in the past three months because they did not trust the site with their card. A brand whose checkout once served a fake payment page is starting from further behind.

Two details make the exposure larger than the order list suggests. Some shoppers entered a card on the fake page and never completed the real purchase, so they appear nowhere in the store's orders, and the once-per-session trigger means a quick test by the merchant could easily miss the problem. On the other hand, Swym noted that shoppers who paid with a stored wallet such as Shop Pay, PayPal or Google Pay were not exposed in the same way, since they never typed a card number into a form for the fake page to collect.

4. Shopify Locked the Checkout, So the Attack Moved One Click Earlier

For most of the past decade, the riskiest code on a Shopify store sat inside checkout itself. Plus merchants could edit checkout.liquid and add scripts to the payment flow, and many did. Shopify retired that model in stages, with the information, shipping and payment pages moving to checkout extensibility in August 2024 and the thank-you and order status pages following in August 2025. Customization now runs through extensions that work inside a sandbox, without access to the page around them. By every account so far, that design held, since the attackers never broke into checkout.

The storefront is a different story. Product pages and the cart still run code from many apps at once, and a benchmark of 300 busy Shopify stores found that the median store runs 11 apps, with a tenth running 21 or more. Each app is a separate company with its own staff, internal tools and credentials, and any one of them that can place a script on the storefront can, if compromised, decide what happens when a shopper clicks checkout.

Retail has seen this before. In 2018, attackers compromised a third-party chatbot on Ticketmaster's payment page, and the UK regulator later fined Ticketmaster UK £1.25 million, with up to 9.4 million customers across Europe potentially affected. Since March 2025, PCI DSS 4.0 has required merchants to inventory and monitor the scripts on their payment pages for exactly that reason. The October hijack went around that rule, because it never touched the payment page. It replaced the payment page with a copy.

5. What Shopify Has Changed So Far

Shopify's response has come in layers. On October 17 a spokesperson told iTnews that "when an app falls short, we act", which includes delisting, and all three confirmed apps were unavailable on the App Store for a time. On October 20, Shopify published a note titled "Securing your app, together", which asked every app developer to act on a list of steps that week: scan the app with a new security check, move to expiring access tokens, which will soon be required for all public apps, and turn on two-step authentication across every account that touches the app. Shopify also said it is tightening the boundaries for storefront app code, adding IP address restrictions for app keys and raising App Store security requirements.

The same day, Shopify added a confirmation screen before a store sends a shopper to an outside website. Merchants objected within hours, because financing tools, booking pages and sister stores on other domains all triggered it, and on October 23 Shopify narrowed the warning so that it blocks only known malicious sites and asks for confirmation on suspicious ones. That is a sensible backstop, but it depends on the destination being recognized as bad, and the domains in this campaign were new and largely unlisted when they were used. The more durable fix is the one Shopify signaled for storefront app code, which would make it harder for any app to redirect a checkout click in the first place.

6. Six Checks for Shopify Merchants Before Black Friday

None of the confirmed apps was doing anything unusual by design, which is the uncomfortable lesson. The risk sits in ordinary features, so the defense is mostly ordinary housekeeping, and most of it fits into an afternoon. These checks are worth running now, before holiday traffic makes any interruption far more expensive.

First, list every app that can put code on the storefront. Note any app with a custom JavaScript or HTML field and every app embed switched on in the theme editor, and remove the ones the store no longer uses. The app that cannot load is the app that cannot be hijacked.

Second, test checkout the way a shopper reaches it. Open a fresh private window, go from a product page to the cart and click checkout, then confirm the address bar shows the store's own domain or Shopify checkout. Repeat in a new private window, since the script fired only once per session, and make it a weekly habit through the holidays.

Third, lock down every account that can change a setting. That means two-step authentication on the Shopify admin and on each app vendor's own dashboard, removing staff and collaborator access that is no longer needed, and reviewing which AI tools and custom apps hold tokens for the store.

Fourth, ask app vendors how their settings are protected. Who can change the code their app serves to the store, is every change logged, and would the merchant be told? A vendor that cannot answer those questions clearly is a risk worth weighing against the feature it provides.

Fifth, make stored wallets the easy path. Shop Pay, Apple Pay, Google Pay and PayPal already convert well, and in this attack they also kept card numbers away from the fake form.

Sixth, write the incident plan before it is needed. If a customer reports an odd payment page, password-protect the store, switch off the suspect app, record the time and the fake address, and contact Shopify and the developer. Then check the store's notification duties under breach laws and its payment processor agreement.