Shopify Checkout Phishing Attack: What Happened and How to Check Your Store

The Shopify checkout phishing attack is a campaign, first reported on October 10, 2026, in which third-party storefront apps were made to load code that sent shoppers who clicked Checkout to a fake checkout page. The fake page captured their card details, then passed them on to the store’s real checkout.

Status, checked October 19, 2026: New activity was reported as recently as October 18. Swym said in an FAQ that unauthorized activity starting at 21:17 UTC used the Wishlist Plus app’s access to add scripts to some stores, so it disabled the app for all merchants and revoked its Shopify credentials. Swym has since taken that FAQ down, and its status page still lists an ongoing incident. The App Store listings for Hulk Product Options, Swym Wishlist Plus, Selleasy, Boost AI Search & Filter and Privy all read “not currently available.” Boost and Privy have not linked their listings to the campaign.¹²³

Key takeaways

• Since at least October 10, 2026, some shoppers who clicked Checkout were shown a lookalike checkout that sent their card details to an attacker, then forwarded them to the real one.
• HulkApps, Selleasy and Swym have confirmed that an unauthorized party changed what their apps loaded on some storefronts. None has published a full root cause.
• No source says Shopify’s own checkout or systems were breached. The code ran on storefront pages, before checkout loaded.
• In the first wave the code arrived inside app settings, not theme files, so a code search would have missed it. The live checkout test is the check that matters.
• Every app that loads code on your storefront is code someone else can change. Cutting the ones you don’t need shrinks the risk for good.

Why you can trust us

Jacques has more than 15 years of development experience, and we have spent over four years working inside Shopify themes for hundreds of merchants. We build Fudge, which reads a store’s real theme code and can test a live storefront in a real browser.

This is not a forensic report. Every claim below is tied to a vendor statement, Shopify documentation, or the developer who found the attack, and we say so where a claim rests on one person’s report.

---

What happened in the Shopify checkout phishing attack?

Developer Roman Zipp found it by accident on October 10. He was buying from a keyboard retailer’s Shopify store, pressed Checkout, and his password manager tried to fill the wrong fields on a page that looked like Shopify’s checkout. The address bar showed a domain he didn’t know.⁴

He repeated it in a private window with test details. The form sent them to the attacker’s server, which replied with a record number, and the page then moved him on to the store’s genuine checkout.⁴

He traced the code to Hulk Product Options and reported it. His timeline shows the hijack gone from that store 16 minutes after Shopify escalated it internally. Within days, merchants who had never installed a HulkApps app reported the same fake checkout, and Selleasy and Swym confirmed incidents of their own.⁴⁵⁶⁷

Timeline

Date (2026)	Event
July 22	Qikify finds checkout redirects planted in settings fields of two of its apps and removes them the same day. It treats this as a separate case.8
October 10	Zipp finds the fake checkout. HulkApps later says unauthorized configurations reached Hulk Product Options that day.49
October 13, 07:47 to 15:00 UTC	Selleasy’s incident window, per its notice to an affected merchant.5
October 14, 10:06 to 11:56 UTC	Swym says its Wishlist Plus configuration was changed without authorization. Fixes were fully live by 16:32 UTC.7
October 15	HulkApps issues a statement. Zipp says seven merchants have contacted him and not all of them ran HulkApps.94
October 17	A Shopify spokesperson comments to iTnews.10
October 18, from 21:17 UTC	Swym reports new unauthorized activity using the app’s access, then disables the app for every merchant.1

---

How did the fake checkout redirect work?

The attackers never touched Shopify’s checkout. They hijacked the click that leads to it.

Apps put code on your storefront through app embeds, which Shopify injects just before the closing </head> or </body> tag of every page.¹¹ Checkout is a different world: apps that extend it run in an isolated sandbox with no access to the checkout page or to payment details.¹² We cover that sandbox in our guide to Shopify checkout extensibility.

So the code ran on the product page and cart, waited for a tap on Checkout, and sent the shopper elsewhere before Shopify’s checkout could load.

Route 1: code hidden in app settings

Many storefront apps ship a small script that, on every page load, asks the vendor’s servers for that store’s settings. In the first wave, those settings were the payload.

• HulkApps: the app’s own script came from Shopify’s CDN and was clean. Zipp found about 22.7 KB of extra JavaScript in a custom-code field of the settings it downloaded from HulkApps’ API.⁴
• Selleasy: its notice to merchants says an outsider got into one of Selleasy’s internal tools and planted a script in several stores’ Selleasy settings.⁵
• Swym (October 14): Swym describes an unauthorized change to the app configuration. Developer Dan Sutherland, who investigated an affected store, reports that the attack string sat where the “Add to Wishlist” button label should have been.⁷¹³
• Qikify (July): code was planted in customizable HTML fields of the app settings, and Qikify says nothing was written into merchants’ themes.⁸

A theme code search would not have found any of these. The code lived on the vendor’s servers and only appeared in the shopper’s browser.

Route 2: using the app’s access to the store

Swym’s October 18 incident is different. Swym says the activity used the Wishlist Plus app’s own access to merchant stores, not merchants’ staff accounts, to add scripts that tried to redirect shoppers. It tells merchants to check their theme files for edits made by the Swym app and to search them for checkout-guard.¹

That makes a theme search worth running too. We show how below.

What the code did in the shopper’s browser

From the code Zipp captured:⁴

1. It listened for the tap or click on Checkout.
2. It loaded a lookalike checkout on an outside domain.
3. The card details went to the attacker’s server.
4. The shopper was forwarded to the real checkout to pay again, so the order still came through.
5. It set __ctf_shim_handoff_done_v1 in session storage so it would not fire twice for the same shopper.

HulkApps adds that the redirect failed on some visits and some browsers blocked it.⁹ Put together, a store owner testing their own checkout could easily see nothing.

Domains named so far

Do not visit these. Each is written with brackets so it can’t be clicked.

Domain	Named by
biliing[.]top	Zipp, and merchants on the Community thread45
checkout-confirm[.]top	Zipp4
order-confirm[.]top	Zipp4
account-confirm[.]top	Dan Sutherland, a Community commenter, and Swym (seen in similar attacks)1351
billing-confirm[.]top	Dan Sutherland13
checkout-guard[.]top	Swym (its October 18 incident)1
checkout-secure[.]top	Swym (seen in similar attacks)1

How did the attackers get in?

Nobody has said publicly. HulkApps calls it “an exploit.” Selleasy names an internal tool. Swym describes an unauthorized change, then use of the app’s access.⁹⁵¹

Zipp lists four possibilities for the HulkApps case and has confirmed none of them: a merchant’s HulkApps account, a HulkApps employee’s account, HulkApps itself, or another app altering the configuration.⁴

How solid it is	Claims
Confirmed by the vendor	HulkApps (October 10), Selleasy (October 13) and Swym (October 14 and 18) say an unauthorized party changed what their apps loaded on some stores.
Reported by one person, not confirmed	Boost and Privy as delivery routes. Swym’s October 14 payload sitting in a button label and staying cached in the browser. An August case at Hextom.1345
Not public	The way in, the number of stores and shoppers affected, the number of cards captured, and whether the incidents are connected.

---

Which Shopify apps were involved?

There is no evidence that any of these vendors wrote the malicious code. HulkApps, Selleasy, Swym and Qikify say attackers used their apps to deliver it.

Was Hulk Product Options hacked? What HulkApps says

According to HulkApps, an exploit slipped unauthorized configurations into Hulk Product Options on October 10, in a broader attack on several Shopify apps. HulkApps traces every redirect linked to its apps to one place, the Hulk Product Options theme extension. Shopify switched that extension off as a precaution and later restored it.⁹

It has hired an independent security firm, strengthened authentication, and told merchants they don’t need to uninstall. The listing still showed as unavailable on October 19.⁹³

Selleasy (Logbase)

Logbase calls October 13 a deliberate, planned attack that injected a script into some of the stores Selleasy serves. It found no evidence of a breach of its backend or database, and says Shopify confirmed the code was removed the same day.⁶

Its notice to affected merchants adds the window, 07:47 to 15:00 UTC, and says it has locked the Custom JS setting so no tool or API can change it.⁵

Swym Wishlist Plus (Swym)

Swym has published two incidents:

1. October 14: a configuration change made a script load on some storefronts, which may have sent shoppers to a fake checkout. Swym rotated its API secrets and added sanitization rules. It asks merchants to report anything they saw between 10:06 and 16:32 UTC.⁷
2. October 18: new activity used the app’s access to add scripts to some stores. Swym switched the app off for every merchant, revoked its Shopify credentials, and says it can’t yet confirm or deny any impact on shoppers.¹

Swym published the October 18 details in an FAQ on October 19 and removed it later that day. Its status page still describes an ongoing incident, and at 15:30 UTC on October 19 said Swym was preparing to deploy mitigations.¹²

Not confirmed: Boost AI Search & Filter and Privy

Neither vendor has linked its problems to this campaign, and an unavailable listing doesn’t prove an app was compromised. Both listings were unavailable on October 19.³

• Boost: its status page says its theme app extension was switched off for all stores on October 17 and that Shopify turned it back on the next day. It describes an incident affecting app functionality and does not mention security.¹⁴ A commenter on the Shopify Community thread says the same redirect appeared on October 17 on a store they work on, through the Boost app.⁵
• Privy: its status page reports an outage of its on-site displays from October 17 to 18, with no mention of security.¹⁵ One commenter on Zipp’s post names Privy as the source on their stores.⁴

Earlier: Qikify’s July incident

Qikify’s own notice covers July 22, 2026, when some checkouts from its Sticky Add to Cart and Mega Menu apps were diverted to a fraudulent page via the apps’ settings fields. Qikify reset authentication across all its apps on July 29, and both were back on the App Store by August 21.⁸

Zipp’s post also lists an August case at Hextom. Hextom has published no notice and we couldn’t verify it.

---

Was Shopify hacked? What Shopify has said

Nothing published so far says so. Neither Shopify nor any vendor statement describes a breach of Shopify’s own systems.

Shopify hasn’t published a post or changelog entry about the campaign as of October 19. A spokesperson told iTnews: “When an app falls short, we act.” Shopify says that can mean delisting the app, and in those cases it asks the app’s developer to contact affected merchants directly.¹⁰ Its Partner policy page lists stronger options too, including removing an app from merchants’ stores and cutting off its API access.¹⁶

Shopify did act on individual reports. An Australian merchant hit through Selleasy was advised to keep her store closed while Shopify looked into it, and on October 19 told iTnews that Shopify had said she could reopen.¹⁰⁵

---

How do you check your store for the fake checkout redirect?

Duplicate your live theme before you change anything (Online Store, the … menu on your theme, Duplicate). Then work through these in order.

1. Run the five-minute checkout test

This is the check that would have caught the first wave.

• Open a new private window. It starts with empty browser storage, which matters twice over: the script fired once per session, and one developer reports that Swym’s settings were cached in the browser and could keep the payload alive after the app was switched off.¹³
• Add a product to the cart and use the standard Checkout button rather than an express option like Shop Pay or PayPal.
• Read the address bar the moment the checkout page appears. Shopify’s checkout runs on your own domain, or on your myshopify.com address if you haven’t connected one. Shopify moved it there in 2017.¹⁷ Any other domain at that point is a red flag. Don’t enter card details. Treat it as an incident.
• Close the window, open a fresh one, and repeat from the cart drawer. Qikify says its Sticky Add to Cart redirect fired when shoppers clicked Checkout in the cart drawer.⁸
• Repeat once more on your phone.

Card pages from your payment provider or bank, such as 3-D Secure, can appear later in checkout. The red flag is a different domain at the point the checkout page first loads.

2. Find every app that can run code on your pages

• Settings > Apps lists your installed apps.¹⁸ Note Hulk Product Options, Swym Wishlist Plus and Selleasy (confirmed incidents), and whether you run Boost AI Search & Filter or Privy. Open any app to see its Extensions card, which shows what is active and where.¹⁸
• Online Store > Edit theme, then the App embeds icon in the sidebar, shows every embed that is switched on.¹⁹ Each one can load code on every page.

3. Search your theme for known markers

Go to Online Store, open the … menu on your live theme and choose Edit code. The search button in the left sidebar searches across all theme files.²⁰ For a guided tour of the editor, see how to edit your Shopify theme.

Search for:

• Each domain from the table above, without the brackets (for example biliing.top)
• checkout-guard, which Swym asks merchants to search for¹
• __ctf_, the prefix of the storage keys Zipp found⁴

Searching for .top on its own will flood you with harmless CSS and JavaScript matches.

A clean search covers the theme only. Code that arrives inside an app’s settings never appears there.

4. Optional: look in the browser’s developer tools

If you know Chrome DevTools, open it during a test checkout. Look for __ctf_ keys under Application > Session storage. In the Network tab, check every domain your product and cart pages contact, and make sure you can name the owner of each one.

5. Listen to your customers

Because the fake page passed shoppers on to the real checkout, orders can look completely normal. The signals come from customers instead: a support email about an odd-looking payment page, or a report of card fraud soon after ordering from you.

---

Can Fudge check my store for the checkout phishing redirect?

Partly. Fudge can run the live checkout test that would have caught the first wave, and search your theme for the October 18 markers. It can’t see vendor servers or prove that no card was taken.

What Fudge can check

• The live test, in a real browser. Fudge opens your published store, adds a product, clicks Checkout from the cart page and the cart drawer, and records every page it lands on, every domain the page contacts, and what those requests return. That is where code hidden in app settings shows up. It’s the same capability behind our checkout flow walkthrough.
• The theme search. Fudge can search every file in your published theme for the domains and markers above, and list the app embeds that are switched on. See our theme code investigation.
• A safe rebuild path. It can switch off a suspect embed in a draft copy of your theme for testing. If you have already seen a redirect, don’t wait for a draft: switch the embed off on your live theme now.

What a Fudge check cannot prove

• It can’t list your installed apps or read the settings inside an app’s own admin.
• It can’t see vendor servers or logs, or tell you whether a card was captured.
• It runs from a cloud browser in one location. Nobody knows whether this code skipped automated browsers or certain countries, and it already failed on some visits.
• It can’t handle the response for you: Shopify Support, your payment processor and your customers.

So the honest result of a clean run is: no redirect or known marker was seen in this test, at this time. It is not: your store was never affected.

Prompt: ask Fudge to run the check

Copy this into Fudge:

Run a read-only security check of my published Shopify store for the October 2026 checkout phishing redirect. Do not edit, draft or publish anything. Do not type payment details, and do not submit any form on a page outside my store’s domain.

1. On my published store, use a separate browser agent for each run so each one starts with empty storage. At mobile and desktop sizes, open a product page, add it to the cart, and click the main Checkout button, once from the cart page and once from the cart drawer. Report every URL the browser lands on, and tell me straight away if it leaves my store’s domain or myshopify.com address before the checkout page loads.
2. List every outside domain that loads scripts or receives requests on the product and cart pages, grouped by the app or service it belongs to. Flag any domain ending in .top and any response that contains a redirect.
3. Check session storage and local storage for keys starting with __ctf_ and, if you can tell, which script set them.
4. Search every file in my published theme for biliing.top, checkout-confirm.top, order-confirm.top, account-confirm.top, billing-confirm.top, checkout-guard, checkout-secure.top and __ctf_, plus any script that sends shoppers to another domain when they click Checkout.
5. List the app embeds switched on in my published theme and the app behind each one.

For every finding, give the file or URL, what the code does, and how confident you are. End by listing what this check could not see.

---

What should you do if your store is affected?

First, contain it

• Capture the evidence. Screenshot the fake page with its address visible, copy the full URL, and note the time. In DevTools you can save the Network log as a HAR file. HAR files can contain your login cookies, so share them only with Shopify Support or the app vendor.
• Switch the code off. Turn off the app’s embed under App embeds and save, or uninstall the app.¹⁹ Uninstalling doesn’t always remove everything an app added to your theme, so check the theme as well.²¹ Our guide to removing leftover app code walks through it.
• Test again in a fresh private window. Cached settings can outlive the app being switched off.¹³

Then, report it

• The app vendor: get it in writing: what was injected, when it was live on your store, and their public statement.
• Shopify Support: send your evidence, and be ready for Shopify to suggest closing the store during its investigation, as it did for at least one merchant.⁵
• Your payment processor: for Shopify Payments, raise it in your Support case. For any other gateway, contact them directly. Cards may have been copied even on orders that completed normally.
• The domain: Zipp reported the domains he found to Google Safe Browsing and URLhaus, which helps browsers start warning shoppers.⁴

Then, close the doors

• Change your Shopify password and your password for each app vendor’s dashboard, and turn on two-step authentication.²²
• Under Settings > Users, filter to Collaborators and remove any partner access you don’t need. Generating a new collaborator request code retires the old one.²³
• Review which apps and AI tools have access to your store, as Zipp suggests.⁴ That includes Fudge.
• Ask a lawyer and your payment processor whether you need to notify shoppers or regulators. Swym points merchants to breach-notification and data-protection laws, and to their payment processor agreement.⁷ This is not legal advice.

What to tell customers who ask: your real checkout lives on your own domain. If they saw a different address when paying, they should call their card issuer about the card. Hold off on promises about refunds until your payment processor has looked at your case.

---

How do you reduce your risk from storefront apps?

Every app that loads code on your storefront is code someone else can change. That includes apps you trust.

When an app fetches its settings from the vendor’s servers on each page load, what runs on your store can change without a single edit to your theme. Nothing shows in your theme files or your theme history. You find out when a customer does.

Shopify is narrowing how apps load code. Since October 1, 2026, apps can’t create new script tags, and Shopify stops loading storefront script tags on March 1, 2027.²⁴ That leaves app embeds as the main supported route, and you can review those in one panel. It doesn’t stop an embed from fetching new code from its vendor, and an app with theme access can still edit theme files.

Ask three questions of every app embed

1. Do we still use it? If not, uninstall it and clean up what it left behind.
2. Does it have a custom JavaScript or custom HTML setting? Open it and make sure you recognize everything in it. Zipp found the HulkApps payload in a custom JavaScript field, Selleasy locked its Custom JS setting after the attack, and Qikify names two HTML content fields.⁴⁵⁸
3. Could your theme do this job itself?

Move what you can into your theme

Some of the jobs these apps do can be built into your theme instead. Native code lives in your theme files, changes only when someone edits them, and any developer can read it. It isn’t immune: an app with theme access can still edit it, which is why Swym asks merchants to check their theme files. But a change to it shows up in a code search.

• Product options such as engraving text, gift notes and swatches can use variants and line item properties. Options that change the price need variants or a separate add-on product. Our product configurator guide covers the building blocks.
• Cart upsells and cross-sells can use Shopify’s own product recommendations in a cart section. See how to add upsells in the Shopify cart.
• Bundles can often use Shopify’s native bundles. We compared the two in native Shopify bundles vs bundle apps.

Some apps earn their place. A wishlist that syncs across devices or search across a large catalog usually needs a backend. Keep those, turn off any custom-code settings you don’t use, and rerun the checkout test after each update.

With Fudge, the native route starts with a prompt like this:

Hulk Product Options currently shows these options on my product pages: [engraving text, max 20 characters; gift wrap yes/no, +$5]. If they still render on my live product page, check them there too. Rebuild them as native theme code and save each choice as a line item property so it shows on the order. For options that change the price, explain the approaches and trade-offs before you build. Work in a draft theme so I can test it before I remove the app.

Fudge is also an app with access to your theme, so the same advice applies to us: grant only the access you use, and review it. The changes you ask Fudge for go into a draft copy of your theme, and none of them reach your live store until you review and publish them in the Shopify store editor.

---

Does Shopify’s PCI compliance cover this?

Shopify is certified Level 1 PCI DSS compliant.²⁵ In our reading, that certification is about Shopify’s platform and checkout. It can’t vouch for what a third-party script does on your product page before the shopper gets there.

The PCI Security Standards Council has a name for this pattern, double-entry skimming: a fake payment form comes first, and the shopper enters their details again on the real one.²⁶ Its script requirements for payment pages, 6.4.3 and 11.6.1, took effect on March 31, 2025, but the Council’s FAQ says the related SAQ A check is aimed at merchants that embed a payment form in their own pages, not those that redirect shoppers to a provider’s page.²⁷²⁸ The FAQ doesn’t name Shopify, so ask your acquirer how a Shopify-hosted checkout is classified for your store.

---

FAQ

Footnotes

1. Swym, “Wishlist Plus Security Precaution: Frequently Asked Questions”, published October 19, 2026 at getswym.com/resources/wishlist-plus-incident-faq. We read it that morning. Swym removed the page later the same day. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. Swym status page, checked October 19, 2026, including its 15:30 UTC update. ↩ ↩²

3. Shopify App Store listings for Hulk Product Options, Swym Wishlist Plus, Selleasy, Boost AI Search & Filter and Privy, each checked October 19, 2026. ↩ ↩² ↩³

4. Roman Zipp, Shopify shops hit with ongoing Checkout Hijack attack, published October 10, 2026, updated October 16, 2026, including reader comments through October 17. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷

5. Shopify Community, URGENT: checkout phishing redirect - anyone else affected?, October 15 to 17, 2026, including Selleasy’s notice as shared by the original poster. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

6. Logbase, Selleasy service status: incident of October 13, last updated October 16, 2026. ↩ ↩²

7. Swym, Security Incident Update, October 16, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

8. Qikify, Security incident notice, last updated August 21, 2026, with a note added October 10, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

9. HulkApps statement in the comments of Zipp’s post, October 15, 2026, and HulkApps’ comment on Dan Sutherland’s LinkedIn post, October 15, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

10. Juha Saarinen, Shopify tells Australian store to stay shut after hijacked extensions divert shoppers, iTnews, October 16, 2026, updated October 17 and 19, 2026. ↩ ↩² ↩³

11. Shopify developer documentation, Configure theme app extensions. ↩

12. Shopify developer documentation, Checkout UI extensions, Security section. ↩

13. Dan Sutherland, LinkedIn post on a Shopify checkout phishing redirect, October 14, 2026. One developer’s analysis of one store, not confirmed by Swym. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

14. Boost Commerce status page, incident of October 17 to 18, 2026, checked October 19, 2026. ↩

15. Privy status page, displays outage of October 17 to 18, 2026, checked October 19, 2026. ↩

16. Shopify Help Center, Enforcement of Shopify’s Partner Program Policies. ↩

17. Shopify, Introducing Store Checkout On Your Own Business Domain, July 14, 2017. ↩

18. Shopify Help Center, Managing apps. ↩ ↩²

19. Shopify Help Center, Extend your theme with apps. ↩ ↩²

20. Shopify Help Center, Editing theme code. ↩

21. Shopify Help Center, Uninstalling apps. ↩

22. Shopify Help Center, Two-step authentication for users. Shopify Plus stores can require a secure sign-in method for all users. ↩

23. Shopify Help Center, Collaborator accounts. ↩

24. Shopify developer documentation, Storefront script tags. ↩

25. Shopify, PCI compliance. ↩

26. PCI Security Standards Council, Payment Page Security and Preventing E-Skimming, information supplement v1.0, March 2025, “Double-Entry Skimming” section. Announced here, March 10, 2025. ↩

27. PCI Security Standards Council, Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A, January 30, 2025. ↩

28. PCI Security Standards Council, FAQ 1588, February 2025. ↩