Shopify fake checkout attack: how hijacked apps redirected shoppers

On Saturday 10 October 2026, a German developer named Roman Zipp was shopping for a mechanical keyboard. He added one to his cart on a real Shopify store, clicked Checkout, and landed on what looked like a Shopify checkout page. When he clicked the first name field, his password manager offered to fill in the name on his credit card. That made him look at the address bar. The page was on biliing[.]top, a domain with a deliberate typo. The store was genuine, its products were genuine, and its checkout button had been quietly rewired to send him somewhere else.

Three days later, the same thing happened to a customer of WAGD, an Australian online retailer of dog harnesses. The customer happened to work in technology, took screenshots and sent the owner, Carly Clarke, the fake checkout’s address. Clarke shut the store at once and reported it to Shopify. It stayed closed, on Shopify’s advice, for six days.

Neither store had been hacked in the usual sense. The malicious code arrived through third-party apps the stores had installed, delivered from the app developers’ own systems. At least three app developers have now confirmed incidents in October: HulkApps, Logbase (maker of Selleasy) and Swym. A fourth, Qikify, had the same pattern in July. Several more apps have been reported by merchants but not confirmed. Nothing published so far suggests Shopify’s own checkout was compromised. The attack worked by making sure shoppers never reached it.

This post sets out what is confirmed, how the attack worked and why it was so hard to spot, and what to do if you run a Shopify store, or any online store built on third-party apps. Everything here is current as of 21 October 2026 (AEDT), and some of the developers’ investigations are still running.

The short answer

• What happened: attackers changed settings held on app developers’ servers, so that storefront apps on many Shopify stores served malicious JavaScript to shoppers. The script hijacked the Checkout button and sent shoppers to a lookalike payment page that collected card and personal details, then passed them back to the real checkout.
• Who confirmed it: HulkApps (Hulk Product Options, from 10 October), Logbase (Selleasy, 13 October) and Swym (Wishlist Plus, 14 October). Qikify had a matching incident on 22 July. None has said how many stores or shoppers were affected. Logbase says more than 49,000 active stores use Selleasy.
• Why it was hard to see: the code was not in the store’s theme files, it fired only once per browser session, the order still completed on the real checkout, and the fake domains were not on common blocklists when first reported.
• What Shopify did: disabled or delisted the affected apps while developers removed the code, and said publicly that merchants can review the permissions and activity of any app on their store.
• What to do now: test your checkout from a fresh private browser window, remove apps you do not need, find every app that renders merchant-configured code or content on your storefront, change passwords and turn on two-factor authentication, and if you were affected, work through your notification duties now rather than after the investigation ends.

Verified timeline

All times are UTC. Sources are the developers’ own statements, Roman Zipp’s original analysis and his compilation of company statements, and iTnews’ reporting on WAGD.

How the attack worked

Shopify apps that change what shoppers see usually do it through a theme app extension: a package of code and assets, including JavaScript, that Shopify injects into the store’s theme. The extension’s code is deployed to Shopify and served from Shopify’s own CDN. What it does on each page load, though, often depends on settings the merchant configures in the app, and those settings live on the app developer’s servers.

That gap is where the attack lived. Zipp’s analysis of the HulkApps case shows the full chain:

1. The Hulk Product Options extension loaded on the store’s pages from Shopify’s CDN, as it should.
2. On each page load it asked HulkApps’ API for the store’s configuration.
3. The response included a field for custom JavaScript, a feature that lets merchants add their own code. It contained about 23 KB of the attacker’s script.
4. The extension ran that script in every shopper’s browser.
5. The script attached itself to the Checkout button, cancelled the normal click, and sent the shopper to a lookalike checkout on a .top domain.
6. The fake page collected the shopper’s details, posted them to the attacker’s server, and then sent the shopper on to the store’s real checkout.

The other confirmed cases used the same channel with different keys. Logbase says an intruder reached one of its internal tools and used it to plant the script in the app’s settings for the affected stores. Swym describes an unauthorised change to its app’s configuration through an access channel it has since secured, and has added sanitisation against code injection. Qikify found the script in customisable HTML fields, such as the empty cart message and a menu item title, which the app rendered on the storefront.

In every confirmed case, the developer describes the change as made on its side, not in the merchant’s Shopify account or theme. The attacker changed something the app was built to serve to the stores using it, so one compromise at the developer could reach every store that loaded that setting. How many did is still unknown.

Why it was so hard to spot

The attack was designed to survive a merchant’s checks.

• It fired once per session. Zipp found the script recorded in the browser’s session storage that it had already redirected a shopper, and never tried again in that session. A merchant who clicked Checkout twice in the same browser would see the fake page once, or not at all, and then the real checkout every time after.
• The order still went through. After harvesting the details, the fake page handed the shopper back to the genuine checkout. The merchant saw a normal sale, and the shopper may only have noticed later, on their card statement.
• Nothing was in the theme. Clarke told Zipp she had searched her theme export for anything suspicious and found nothing. The code arrived at run time from the developer’s server.
• The domains were fresh. When Zipp first checked, the fake checkout domains were not listed by URLhaus or Google Safe Browsing. Spamhaus listed some of them days later.
• It did not always work. HulkApps and Logbase both say the redirect did not succeed on every visit, and some browsers blocked it. That is good for shoppers, and it also made the problem harder for merchants to reproduce.

Confirmed, reported and unknown

Confirmed by the developer. HulkApps (Hulk Product Options, 10 October), Logbase (Selleasy, 13 October) and Swym (Wishlist Plus, 14 October) have each confirmed that an unauthorised party altered their app’s configuration or settings. HulkApps and Logbase confirm redirects to a fake checkout; Swym says shoppers on affected pages may have been sent to a lookalike checkout. Qikify confirmed a matching incident in July and says it was not part of the October wave. WAGD is the Australian store confirmed affected through Selleasy.

Reported, not confirmed. Merchants have connected redirects to other apps, including Boost AI Search & Filter, Privy and Consentmo, according to Zipp. Boost confirmed an incident that led Shopify to switch off its storefront extension for every store, but has not described it as a redirect. Zipp also lists Hextom as an earlier incident, resolved in August. On 19 October a merchant commenting on Zipp’s post reported redirects to another domain, checkout-guard[.]top, on three stores that ran none of the named apps. Treat all of these as unconfirmed until the developers say otherwise, and treat the list of affected apps as possibly incomplete.

Unknown.

• How many stores and shoppers were affected. No developer has published a number.
• Whether the incidents are one campaign. HulkApps describes its incident as one part of a broader attack on several Shopify apps. Zipp says the frequency is very suspicious, but he cannot yet link them. The shared fake checkout domains suggest a common operator, at least for the HulkApps and Selleasy cases, where merchants reported the same domain.
• How the attackers got in. Logbase points to an internal tool. Swym points to an access channel. HulkApps cites an exploit. Qikify, according to Zipp, believes a credential leaked from outside its own systems, and raised AI coding assistants and agents with broad access to code, terminals and stores as one way credentials now leak.
• What happened to the card data. Shoppers who typed card details into a fake page should assume those details are compromised.

Clarke’s experience of the response is worth noting for anyone planning their own: “I’ve received more information from individual app developers than from Shopify itself,” she told iTnews. Shopify told her she could reopen on 19 October, six days after she closed.

Not a Shopify breach, but a supply chain problem

It is tempting to read this as a Shopify breach, and nothing published supports that. No statement so far suggests Shopify’s checkout, accounts or payment systems were compromised. But it is also not purely the app developers’ problem, and that is the part that matters for merchants.

Every app that puts code on your storefront is a supplier with the ability to run software in your customers’ browsers, on your domain, at the moment they are about to pay. Most merchants choose those apps for features and price, install them in a minute, and never revisit them. The attacker in this case did not need to beat Shopify’s security or the merchant’s. They needed one app developer with weak controls on the settings it serves to its customers’ stores.

The pattern is old. Attacks that inject card-stealing scripts into checkout pages, often grouped under the name Magecart, have hit major retailers for a decade, frequently through a third-party script rather than the retailer’s own code. In June 2024 the new owner of the Polyfill.io JavaScript library used it to inject malicious code into more than 100,000 websites. The new element here is the delivery channel: settings fields that an app fetches from its developer’s servers at run time, rather than the app code deployed to Shopify.

This is the same lesson as our third-party risk guide and our piece on code entering your estate without a vendor review: the risk sits with whatever can change what runs in your environment, not just with the vendors you formally assessed.

What to do if you run a Shopify store

This week

1. Test your checkout properly. Open a new private or incognito window, add a product to the cart, click Checkout, and confirm the address bar stays on your own store domain or Shopify’s checkout. Close the window and repeat, because the script fired only once per session. Test on a phone as well as a computer.
2. Remove apps you don’t use. Uninstall them rather than leaving them disabled. Then go to Online Store, Themes, Customise, App embeds, and switch off any embed you do not recognise or need.
3. Find every app that renders configured content on your storefront. Start with settings named custom JavaScript, custom HTML, custom CSS or advanced code, which carried the script in the HulkApps and Selleasy cases. Do not stop there: Qikify’s incident used content fields such as the empty cart message, and Swym has since added sanitisation against code injection, so any field an app displays to shoppers can carry the same risk. Ask each developer who can change those settings, whether changes are logged, and whether you will be told.
4. Reset credentials and turn on two-factor authentication. Do it for your Shopify account and every staff account, and for any separate accounts you hold with app developers. Review the permissions each app holds, and check which AI tools, custom apps and collaborators have access to your store’s admin or API tokens.
5. Watch your app developers’ notices. Read the emails and status pages from every app you run, including the ones you assumed were unaffected.

If your store was affected

1. Preserve evidence. Keep screenshots, the fake checkout address, the times customers reported it, your app list and versions, and every message from Shopify and the app developer.
2. Work out the exposure window. The developers’ statements give their windows in UTC. Convert them to your timezone and match them to your orders and traffic.
3. Tell your payment provider. Card details were the target. Your provider and the card schemes need to know.
4. Decide on telling customers. Swym suggested its merchants think about contacting shoppers who keyed card details into the checkout during its window. It said payments through wallets such as Shop Pay, PayPal and Google Pay were not exposed in the same way. Customers who entered card details should contact their bank.
5. Assess your privacy obligations now. If the Privacy Act covers your business, the Notifiable Data Breaches scheme requires you to assess a suspected eligible data breach quickly, and to take reasonable steps to finish that assessment within 30 days. Many businesses with an annual turnover of $3 million or less are exempt, but not all of them. Whether details typed into an attacker’s page count as information your business held is a legal question, so take advice and do not wait for the developer’s investigation to finish.
6. Report it. Report the incident through ASD’s ReportCyber, and report the fake domain to Google Safe Browsing so browsers start warning shoppers sooner.

If you are a larger retailer or run several stores

Larger retailers face the same risk with more at stake: more customers, more apps, and in many cases formal compliance obligations.

• Put storefront apps in your supplier register. Each one needs an owner, a reason to exist and a review date. ASD’s new ASD Essentials framework, published on 15 October 2026, has a chapter for organisations that run entirely on SaaS and PaaS. It puts integrations alongside identity and tenant configuration as where a SaaS customer’s security posture is decided, and asks organisations to find sanctioned and unsanctioned integrations and bring them under governance. A storefront app is exactly that kind of integration.
• Check your PCI DSS position with your acquirer. Since 31 March 2025, SAQ A has included a criterion on script attacks, but the PCI Security Standards Council’s FAQ limits it to merchants whose own pages embed a payment form, such as an iframe. It does not apply where payment is redirected to, or fully outsourced to, a payment provider, which is how Shopify stores normally take payment. That does not make the risk someone else’s: in this attack, a fake page took the card details before any payment provider was involved. If you also run storefronts with embedded payment forms, the criterion applies there, and the FAQ points to script management and change detection as ways to meet it.
• Monitor the checkout continuously. A scheduled test that opens a fresh browser, adds a product, clicks Checkout and alerts if the destination domain changes would very likely have caught this attack within hours. It costs little to build or buy.
• Put terms in your app contracts. Where you have leverage, ask for incident notification within a fixed time, change logs for any setting that can deliver code to your storefront, and the ability to switch those features off.
• Rehearse the closure decision. WAGD closed within minutes of hearing from a customer, which was the right call. Decide in advance who can make that call for you, and what you would tell customers.

The questions to ask your app developers

Whether you run one store or fifty, every developer whose app touches your storefront should be able to answer these:

1. Can anyone at your company, or any tool you run, change the code or content my storefront loads, without my approval?
2. Are changes to those settings logged, reviewed, and alerted on?
3. How do your staff sign in to the internal tools that can change merchant settings, and is multi-factor authentication enforced?
4. Do you sanitise merchant-entered text before rendering it on storefronts?
5. How quickly will you tell me if my store is affected by an incident, and through which channel?

An honest “we’re working on it” is a better answer than silence. A developer who cannot answer the first question has a storefront supply chain that nobody controls.

How we can help

Many of the stores that run these apps are small businesses, and the best defences here are cheap: fewer apps, regular checkout tests, two-factor authentication and a plan. For organisations with more at stake:

• Our penetration testing covers web applications and APIs, by a certified offensive practitioner, if you want an independent look at what your storefront and its integrations actually do.
• Our security posture assessment is a two-week, fixed-price review with evidence, including your supplier register, which is where storefront apps belong.
• Our fractional CISO gives you a named person accountable to your board for decisions like these.

A checklist for this week

1. Run the private-window checkout test, twice, on desktop and mobile.
2. List every installed app and uninstall the ones you do not use.
3. Switch off app embeds you do not recognise or need.
4. Identify every app that renders configured code or content on your storefront, starting with custom JavaScript and HTML settings, and ask its developer the five questions above.
5. Change your Shopify and app developer account passwords and turn on two-factor authentication for every staff account.
6. Review app permissions, collaborator access, custom apps and AI tools connected to your store.
7. Set up an automated checkout test that alerts when the checkout domain changes.
8. If you were affected: preserve evidence, tell your payment provider, start your Notifiable Data Breaches assessment, and report through ReportCyber.
9. Confirm with your acquirer which PCI DSS questionnaire applies to each storefront, and whether its script criterion covers you.
10. Decide who can close your store in an incident, and write down what you would tell customers.

Further reading

• Roman Zipp: Shopify shops hit with ongoing Checkout Hijack attack, the original technical analysis, updated as new apps were reported
• Roman Zipp: Statements from companies involved in the Shopify Checkout Hijack (19 October)
• iTnews, Juha Saarinen: Shopify tells Australian store to stay shut after hijacked extensions divert shoppers (16 October, updated 19 October)
• Tech Business News: Shopify stores caught in fake checkout attack as hijacked apps redirect shoppers (18 October)
• Logbase: Selleasy service status
• Qikify: Security incident notice (July 2026 incident)

Frequently asked questions

Was Shopify hacked?

Nothing published so far suggests it was. No statement from Shopify or the app developers indicates that Shopify’s checkout, payment systems or merchant accounts were compromised. The malicious code came through third-party apps, after attackers changed settings held on the app developers’ own systems. Shopify disabled or delisted the affected apps while the code was removed.

Which Shopify apps were affected?

HulkApps (Hulk Product Options), Logbase (Selleasy) and Swym (Wishlist Plus) have confirmed incidents in October 2026. Qikify had a similar incident in July 2026. Merchants have reported other apps, including Boost AI Search & Filter, Privy and Consentmo, but those developers had not confirmed a redirect at the time of writing.

How do I check whether my Shopify store is affected?

Open a new private or incognito window, add a product to your cart and click Checkout. The page should stay on your own domain or Shopify’s checkout. Repeat in a fresh window, and on a phone, because the malicious script fired only once per browser session.

I bought something from a Shopify store recently. Should I be worried?

If the checkout page’s web address was not the store’s own domain or Shopify’s, or you remember an unusual address, contact your bank and ask about replacing your card. Payments made with wallets such as Shop Pay, PayPal or Google Pay were not exposed in the same way, according to Swym.

Does my business have to report this?

It depends on whether the Privacy Act covers your business and whether personal information was compromised. Many businesses with an annual turnover of $3 million or less are exempt, but not all. If you are covered and suspect a breach, the Notifiable Data Breaches scheme requires a prompt assessment, with reasonable steps to finish it within 30 days. Take legal advice early.

How did the attackers get into the apps?

The developers have described different routes: an internal tool (Selleasy), an access channel (Swym), an exploit (HulkApps) and, for Qikify’s July incident, a credential believed to have leaked from outside its systems. None has published a full root cause yet, and nobody has publicly linked the incidents to one group.

How do I stop this happening to my store?

Install fewer apps, remove the ones you do not use, know which apps can put code or content on your storefront, enforce two-factor authentication everywhere, and test your checkout regularly from a fresh browser. An automated checkout test that alerts on a change of domain is one of the most effective ways to detect this attack.

Where to start

Run the private-window test now, before you finish your coffee. If it passes, list your apps and ask the five questions. If you want help working out which of your suppliers can change what your customers see, talk to us. If you want a baseline first, the maturity assessment takes ten minutes.