Skip to main content
Back to BlogE-Commerce

Shopify Checkout Hijack: Why the Hole Was Never in Shopify

561 MediaOctober 24, 20266 min read

On October 20, Shopify posted a changelog entry titled "New protection against unexpected redirects." Storefronts would ask shoppers to confirm before leaving for an external site.

Three days later, Shopify updated it. The storefront now blocks only sites Shopify has already identified as malicious. Suspicious sites get a prompt. Every other external link opens with no message.

That entry is the platform's visible answer to the Shopify checkout hijack, a campaign that surfaced in mid-October and pushed shoppers from real checkouts to lookalike pages built to harvest card details. Most coverage lands in the same place: audit your apps, check your theme, wait for Shopify.

But that is not the story for your business. The code was never in Shopify, and it was never in your theme.

TL;DR

  • The script arrived through a third-party app's configuration: about 22.7 KB of JavaScript in a custom_js field, served from the vendor's API and injected at runtime. Theme files stayed clean.
  • It fired only when a real shopper clicked Checkout, then set a session flag so it would not fire twice. Scanners missed it. So did merchants retesting their own checkout.
  • Orders completed. Revenue dashboards looked normal.
  • Shopify's October 20 protection was narrowed to a blocklist on October 23. The attack domains were not on Google Safe Browsing or URLhaus when found, so a blocklist misses them.

The Code Was Never on Your Site

Developer Roman Zipp found the hijack on October 10 while buying a keyboard. His password manager offered his credit card's name for the first-name field, which made him look at the address bar. The domain was not the store's.

He traced it to the Hulk Product Options theme extension. The app loads a file, hulkcode.js, from Shopify's own CDN. On page load, that file asks the HulkApps API for the store's configuration. The response came back carrying about 22.7 KB of JavaScript in a custom_js field, which the app injected at runtime. Client-side security firm cside reached the same conclusion: the attack code lived in configuration the vendor served from its own servers, not in the store's theme.

The chain of trust ran: your store, to Shopify's CDN, to a vendor's API, to a settings field someone else could write to.

Nothing in your theme changed. Nothing in Shopify's code changed.

Shopify's Fix Got Narrower on Friday, Not Stronger

The October 20 version prompted on most outbound links, exempting only connected domains and a short list of supported Shopify and social sites. Merchants pushed back within a day. A Shopify Community thread opened October 21 asked for an opt-out or a trusted-domain list, and a developer forum report the same day showed a country selector linking two storefronts firing the prompt on legitimate traffic.

Fair complaints. A defensible product decision. Just not protection.

A blocklist catches what is already known. When Zipp checked the phishing domains, they were not on Google Safe Browsing or URLhaus, and his ad blockers and DNS filters did not stop the script. Some reached Spamhaus on October 15, five days after discovery.

A fresh .top domain costs a few dollars. That is the whole counter to a blocklist.

Why Your Dashboard Showed Nothing Wrong

This should worry you more than the malware does.

The fake page imitated Shopify's checkout, collected card and personal details, posted them to the attacker's endpoint, then forwarded the shopper to the real checkout. In cside's words, "because the stolen order still completes on the real checkout, revenue dashboards show nothing unusual." The order went through. You got the revenue.

It also fired once per session, so a merchant who heard about the attack and tested their own checkout would most likely land on the real one.

Conversion rate normal. Order volume normal. Theme clean. Scanner clean. Retest clean.

"We checked and we're fine" was not evidence of anything.

Every "Paste Your Code Here" Field Is a Door You Gave Away

This travels well past Shopify.

Your site has a tag manager container, probably a chat widget, a review widget, a consent banner, and some number of plugins. Several of those store custom HTML or JavaScript in a settings field. That field is a remote code path into the page where customers type their card number, and you are not the only one who can write to it.

WordPress has the same shape. So does a Boca Raton home services site with a third-party scheduling widget on its quote page: same risk, lead form instead of a cart. If your forms sit at the bottom of your funnel architecture, so does every script loaded next to them.

The Vendor's Admin Panel Is Part of Your Attack Surface

Logbase, which makes Selleasy, said an unauthorized party gained access to an internal tool and used it to add the script to stores, removing it from all stores by 15:00 UTC on October 13. Swym said an unauthorized change to the app's configuration came through an access channel it has since secured.

The attacker never touched those merchants. They got into the vendor's internal tooling and wrote to the storefront through a feature working exactly as designed.

Zipp's tracker lists seven apps in this wave as affected or unconfirmed: HulkApps, Swym Wishlist Plus, Selleasy, 17TRACK, Boost AI Search & Filter, Privy and Consentmo. Four of those are marked unconfirmed, so treat the list as an ongoing investigation, not a verdict.

You cannot patch a vendor's internal tooling or guess which app is next. What you control is how many of these write paths exist at all, and most stores carry several they stopped using a year ago. That is the gap between buying tools and shipping systems, showing up as risk.

What To Do This Week

  1. Cut the apps you cannot justify. Open your app list and your theme's app embeds, and uninstall everything you cannot name a current reason for. Not disable. Uninstall. A disabled embed from an app that still holds storefront access is still a door.
  2. Baseline every code field. In every remaining app's settings, find the custom JavaScript, HTML and CSS fields and screenshot what is in them today. That is a known-good baseline, the thing nobody had on October 10.
  3. Test like a shopper, then lock the doors. Test checkout in three separate fresh private windows, mobile and desktop, reading the domain on the payment step each time. Once per session is not a test. Then require two-factor authentication on every account that can install an app.

FAQ

How did the Shopify checkout hijack happen?

Attackers put JavaScript into third-party app configuration rather than into store themes. The Hulk Product Options app requested its settings from the vendor's API, and the response contained about 22.7 KB of malicious code in a custom_js field, which the app injected at runtime. Theme files stayed clean throughout.

Was Shopify itself hacked?

No. The compromises happened at third-party app vendors, and the code reached storefronts through app features working as intended. Affected apps were de-listed from the App Store, HulkApps says Shopify temporarily disabled its theme extension, and Shopify added redirect protection that it narrowed on October 23.

How do I know if my store was affected?

You probably cannot tell from your dashboard, because orders completed normally and the script hid itself after one firing per session. Check your apps against the reported list, review every app settings field for code you did not put there, and test checkout in fresh private windows. If you find a redirect, contact Shopify Support and review your notification obligations under your payment processor agreement and state law.

The Reframe

Every platform story gets read as a platform problem. This one is not. Shopify's code held, your theme held, and your customers still handed their cards to someone else.

What failed was the assumption that the things rendering inside your website are things you control. You do not. You rent them, from vendors you have not thought about since the day you installed them. Same lesson as every other platform dependency: what you rent was never the advantage.

Book a 30-minute website and e-commerce risk review with our Shopify team. No pitch, just a read on what is actually running on your pages and what you can cut this month. Get a free strategy call.

Shopifycheckout securitythird-party scriptse-commerceapp security
Share

Get more of this in your Google results

Pick 561 Media as a preferred source and we'll show up more often in Top Stories and AI answers.

Make us a preferred source on Google

Want help applying this to your business?

We turn these strategies into results for businesses like yours. Let's talk about what would work for you.

Get a Free Strategy Call