Shopify Checkout Hijack: What Happened and How to Check Your Store

Transparency note: Trafik Plus makes Snap Bundle, a Shopify app for bundles and upsells. None of the apps in this incident are ours, and we are not affected, but we sit on the same side of the fence as the vendors named below. This article sticks to what public sources say and links each claim.

The short answer

Since October 10, 2026, a Shopify phishing attack has been sending shoppers on real Shopify stores to fake checkout pages that steal card details. The redirect comes from code injected into the configuration of third-party apps (Hulk Product Options, Selleasy, Swym Wishlist Plus), not from a flaw in Shopify's checkout. It fires once per browser session, then sends the shopper on to the real checkout, so the order goes through and nobody notices.

It is not over. Between October 14 and 18, Shopify pulled 126 apps from the App Store(opens in a new tab), including Privy, Rebuy, Rokt's Upcart and Aftersell, and several Bold apps. On October 19, a store's visitors were still being sent to a fake checkout for about ten minutes.

If you run a Shopify store, take five minutes today: open your store in a private window, click Checkout, and check the domain in the address bar. The steps are below.

What happened in the Shopify phishing attack

• Oct 10, 12:10. Developer Roman Zipp(opens in a new tab) is buying from a keyboard store when his password manager offers to fill his card name into a "First name" field on biliing[.]top. A vape shop owner had reported the same domain on Reddit 18 days earlier.
• Oct 10, 15:27–16:37. Zipp reports it to Shopify. It is escalated at 16:21 and fixed at 16:37. Shopify temporarily disables the Hulk Product Options theme extension.
• Oct 13. Selleasy, by Logbase, is hit between 07:47 and 15:00 UTC. We covered the fallout in our Selleasy alternatives guide.
• Oct 14. Swym confirms an unauthorized change to the configuration of Wishlist Plus.
• Oct 16. The App Store listings of Hulk Product Options, Swym Wishlist Plus and Selleasy show as unavailable(opens in a new tab).
• Oct 14–18. Shopify delists 126 apps(opens in a new tab), about a hundred of them on October 15. Privy, Boost AI Search & Filter and Rebuy follow on October 18. Privy is named in new reports; its involvement is not confirmed.
• Oct 19. CRO consultant Kévin Miguet(opens in a new tab) reports that for ten minutes every visitor of a client store was sent to checkout-guard[.]top, a new domain, before the redirect vanished. Other merchants reply that they saw the same thing the day before.

As of October 19, the root cause is still unknown and Shopify has not published a statement. It pointed Zipp to its changelog and could not say how many stores were affected. Zipp counted five to seven merchants by October 15, which is surely low.

How the Shopify checkout hijack works

The attack never touches Shopify's checkout. It happens one step earlier, on the storefront, through code that a store app is allowed to load.

1. A trusted app loads its usual script. In the first case, it was Hulk Product Options' own file, served from cdn.shopify.com as part of its theme app extension(opens in a new tab).
2. The script fetches its settings from the vendor's server. The response contained a field meant for merchant customizations, `custom_js`. The attacker had put 22.7 KB of JavaScript in it.
3. The injected code hijacks the Checkout button. When the shopper clicks, they land on a page that copies Shopify's checkout, on a domain such as biliing[.]top, checkout-confirm[.]top, order-confirm[.]top or checkout-guard[.]top. The logo is often wrong.
4. The fake page collects the card, sends it to the attacker's server, then forwards the shopper to the real checkout.
5. It fires once per session.(opens in a new tab) Session storage keys starting with `__ctf_` stop it from running twice, so a merchant who tests twice in the same tab sees nothing.

Ad blockers and DNS filters did not catch the domains. The attacker did not need to break into Shopify: they only needed write access to an app's configuration. How they got it is still unknown. Zipp lists four options: a compromised merchant account, a compromised vendor employee account, a compromise of the vendor itself, or another malicious app.

Which apps were affected

The wider delisting wave

The confirmed cases are only the tip. Here are the biggest apps among the 126 delisted between October 14 and 18(opens in a new tab), by number of reviews:

Read this list with care. Shopify has not said why each app was removed, and its own Shopify Product Network app is on it, so a delisting is not proof of a breach. What these apps have in common is that most of them run code on the storefront: cart drawers, upsells, filters, pop-ups, product options. A delisting also removes the App Store page only; an app you already installed keeps running on your store until you turn it off.

Two warnings about this table. First, it only lists apps that have been named publicly; the attacker reused one method across several vendors, so another app could be next. Second, a store in the Community thread(opens in a new tab) was hit on October 13 without having any HulkApps app installed, so "I don't use Hulk" is not a reason to skip the check.

What the vendors said, from the statements collected by Roman Zipp(opens in a new tab):

• HulkApps: "an exploit introduced unauthorized configurations into Hulk Product Options". No other Hulk app was affected, and the company brought in an outside security firm.
• Logbase (Selleasy): "a deliberate, planned cyber attack" in which "an unauthorized party gained access to an internal Selleasy tool". The Custom JS setting is now locked.
• Swym: "an unauthorized change to the app's configuration", adding that it "does not collect, process or store card data".

The pattern is not new. Qikify(opens in a new tab) disclosed a similar injection in July, which it traced to "a compromised credential, most likely leaked from outside their own systems".

Is Shopify checkout safe?

Yes, the checkout itself is. Shopify says it is "certified Level 1 PCI DSS compliant"(opens in a new tab), and since 2017 the checkout has run on your store's own domain(opens in a new tab) or myshopify.com. Checkout UI extensions(opens in a new tab) run in an isolated sandbox and cannot read card fields.

The weak point is everything before the checkout: the theme, and the apps that inject scripts into it. A theme app extension can add code to the head or body of every storefront page. That is how bundles, wishlists and product options work, and it is also how this attack worked.

The PCI Security Standards Council saw this coming: "Scripts running in consumers' browsers are now a significant target for attackers."(opens in a new tab) PCI DSS 4.0 made script inventories (requirement 6.4.3) and tamper detection on payment pages (11.6.1) mandatory after March 31, 2025.

So the useful question is not "is Shopify checkout secure?" but "does every click on Checkout in my store reach Shopify's checkout?"

How to check if your store is affected

1. Open your store in a fresh private window. It has to be new, because the redirect fires only once per session.
2. Add a product to the cart and click the plain Checkout button, not Shop Pay or an express button.
3. Look at the address bar. You should see your own domain or checkout.shopify.com. A .top domain, or anything else you do not recognize, means your store is affected.
4. Close the window and repeat from the cart drawer, from the cart page, and on a phone over mobile data.
5. Open DevTools before clicking. In Application > Session storage, look for keys starting with `__ctf_`. In the Network tab, filter on `.top`.
6. Compare your installed apps with the list of delisted apps(opens in a new tab). For every match, run the test again and ask the vendor in writing whether their configuration was changed.

Then look at the signals you already have: customer emails about a strange payment page, card fraud reports after a purchase, and odd entries in your abandoned checkouts(opens in a new tab).

What to do if your store was hit

1. Keep the evidence before you change anything: screenshots, the fake URL, a HAR export from DevTools, and a duplicate of your live theme.
2. Stop the script. Turn off the app's embed in the theme editor (see app embeds(opens in a new tab)) or uninstall the app(opens in a new tab). Check the theme files for code the app left behind.
3. Get the vendor's account in writing: what was injected, when, and what they changed.
4. Contact Shopify Support and your payment processor. The processor can watch for fraud on the cards used during the window.
5. Lock down access. Change passwords, turn on two-step authentication(opens in a new tab) for every staff account, and review collaborator accounts(opens in a new tab) and the AI tools that have access to your store.
6. Report the domain to Google Safe Browsing(opens in a new tab) and URLhaus(opens in a new tab) so browsers start blocking it.
7. Ask a lawyer whether you must notify customers. That depends on where you and your customers are.

How to protect your store from the next one

• Audit every "custom JS" or "custom HTML" setting in your apps. That field is the door this attack walked through. If you do not use it, ask the vendor whether it can be turned off.
• Fewer apps, fewer doors. Every app that injects storefront code is a supplier with access to your checkout button. Uninstall the ones you do not use, and remove their leftover code.
• Make the checkout test a habit: after every app install or update, and once a week during peak season.
• Keep a script inventory of what loads on your storefront and who owns it. It is what PCI 6.4.3 asks for, and a script monitoring tool covers 11.6.1.
• Choose apps that do their work inside Shopify's own surfaces (checkout UI extensions, Shopify Functions) rather than apps that rewrite your storefront with remote code.
• Read the vendor's security page before you install. A vendor that publishes incidents, like Qikify did, is easier to trust than one that goes silent.

Frequently asked questions