A Shopify app audit before Black Friday takes about 20 minutes: list every app that runs code on your storefront, uninstall the ones nobody uses, and test checkout three times in a private window. October’s app hijacks show why the boring version beats any new security tool.
The apps that hurt stores this month were not unknown apps. They were trusted, popular apps doing exactly what merchants had installed them to do, until someone else changed what they loaded.
A shopper adds a hoodie to her cart, clicks Checkout, and lands on a page that looks exactly like yours. She types in her card. A second later she is on your real checkout, the order goes through, and nothing in your admin looks unusual. The only person who knows anything went wrong is whoever collected her card number.
That is what a group of Shopify apps were turned into this month. Shopify’s own checkout was not breached. The weak point was the apps sitting on the storefront, and the fix is not a new security product. It is the app audit most of us keep meaning to do.
Whether you are running a $10K month or a $1M month, the next four weeks are when the most expensive traffic of your year arrives. This is the 20 minutes I would spend first.
In October 2026, attackers changed what several popular Shopify apps loaded on storefronts, so that some shoppers who clicked Checkout were sent to a lookalike payment page before being forwarded to the store’s real checkout. According to Fudge’s running timeline of the checkout phishing campaign, developer Roman Zipp found the fake checkout on October 10, and HulkApps later said unauthorized configurations reached Hulk Product Options that same day.
Selleasy and Swym Wishlist Plus confirmed incidents of their own within days. Selleasy’s window ran on October 13. Swym reported its Wishlist Plus configuration was changed on October 14, then reported new unauthorized activity on October 18 and disabled the app for every merchant. As of Fudge’s October 19 check, no source said Shopify’s own checkout or systems had been breached. The code ran on storefront pages before checkout ever loaded.
The mechanism matters more than the names. cside’s teardown of the HulkApps hijack found the malicious code was not in the app’s own file at all. It arrived from the vendor’s configuration service, in a settings field built to hold custom JavaScript, and was injected when the page loaded. In other words, the app worked as designed. It was designed to run whatever code sat in that field.
That is the part worth sitting with. Plenty of storefront apps accept custom code as a setting, because merchants and agencies ask for that flexibility. Every one of those fields is a place where code you never wrote runs in front of your customers. I’m not going to tell you which apps are safe, because nobody can promise that this month. What you can control is how many of those doors are open, and whether you would notice if one of them changed.
I have left out two numbers you may see elsewhere: a count of apps pulled from the App Store, and any count of stores or shoppers affected. No vendor has published either one from a primary source, and guessing at them would not change what you should do this week.
Merchants who checked their own stores saw nothing because the malicious script fired only once per browser session and only on a real click of the Checkout button. cside reports the code wrote a marker into session storage so it would not fire twice for the same shopper, and that synthetic scanners and ordinary page loads did not trigger it at all.
Think about what that means for the way most of us test. You open your store in the same browser you use all day, click around, maybe run a test order. If you had already triggered the script once in that session, you would never see it again. If you went straight to checkout through Shop Pay or another express button, you might skip the standard Checkout click the script was listening for. Your store looked clean to you, to crawlers, and to most monitoring.
The agency team at Digismoothie saw it from the other side. In Digismoothie’s account of the fake checkouts on its clients’ stores, Tomas Janu describes client reports on October 13, traces the script to the Selleasy app, and calls the attack almost invisible to checkout session monitoring, because not every visitor was redirected and the ones who were still ended up placing a real order. Disabling the app embed stopped it.
Now, here is why this lands right before Black Friday. The consequence does not show up as an error on your dashboard. It shows up weeks later as customers reporting fraud on cards they used with you, and as disputes you cannot win because the order itself was legitimate. If you read my piece on Black Friday chargebacks that land in January, this is the same lesson from a different angle: the problems that cost the most in Q4 are the quiet ones that surface after the money is gone.
The 20 minute Shopify app audit is three steps: find every app that can run code on your storefront, uninstall the ones nobody uses, and test checkout three times from a fresh private window. You do not need a developer for any of it, and you can finish before lunch.
Two notes on that last step. Use a fresh window each time, because the script only fired once per session. And test the plain Checkout button, because that is the click it listened for. Fudge recommends exactly this pattern, including the cart drawer and a mobile pass.
If something looks wrong, do not just switch the app off and move on. cside’s guidance is to save screenshots and timestamps first, then contact the app vendor in writing, open a case with Shopify Support, and call your payment processor. That paper trail matters if customers start reporting fraud in December.
Then repeat step three once a week through Cyber Monday. It takes five minutes, and it is the only part of this audit that would have caught October’s attack in progress.
Apps can break your store without anyone being hacked, which is why the audit question is ownership, not just security. Paolo Vidali, Founder and CEO of Hidden Gears, told me about a merchant his team worked with on episode 413 of the eCommerce Fastlane podcast. A quote app on that store had pushed an update over a weekend, with nothing in its changelog, and started using a JavaScript library that clashed with one the site already relied on.
In Paolo’s words: “So it created jQuery conflict, bricked the entire site. And that was something no one did, just the app changed and the entire ability to buy stuff on the site died over the weekend.”
What got them out of it is the part I want you to copy. They kept a development copy of the store with the same apps installed, so they deleted apps one at a time on that copy until the problem disappeared. And the first questions Paolo asks in any audit are the ones most stores cannot answer: “Who actually is the quote unquote product owner for this? Like, who on the team is responsible for figuring out, like, is this working? Are we still using it?”
I have lived the boring version of this many times. On episode 467 with Maxx Blank of Triple Whale, I told the story of a brand I ran an app audit with. They had an app that someone installed for forecasting only, it cost $500 a month, and in my words on that episode, “that person left the company and didn’t tell them this $500 app is still running.” That is roughly $6,000 a year spent on a tool nobody was using.
Put those two stories next to October’s hijacks and the pattern is the same. An app nobody owns is an app nobody watches. It costs you money when it sits idle, it breaks your checkout when its vendor ships a bad update, and it becomes someone else’s door into your storefront when its settings are changed. My call, if this were your store: any storefront app without a named owner by Friday gets uninstalled, not paused. If someone misses it in December, they can make the case to reinstall it after Cyber Monday.
Under $500K a year, cut your storefront apps to the few that directly make or protect a sale, and remove everything else before Black Friday. Above $1M, the goal shifts from cutting to ownership: every remaining app gets a named owner, and that owner asks each vendor what their app loaded on your store and when.
If you are under $500K, you almost certainly have apps you installed to test an idea, a popup from last year’s sale, a second reviews widget, an upsell you meant to tune. None of them are worth a fake checkout or a weekend outage. Keep the apps that take payment, handle shipping, collect reviews, and capture email. Everything else waits until January, when you can add it back on purpose. This is the premature complexity pattern I have watched for years: stores at this stage rarely lose Black Friday for lack of an app, and they regularly lose it to one.
Between $500K and $2M, the risk is accumulated weight. Our guide to what breaks first when you scale ad spend makes the same point from the performance side: on Shopify, the parts that buckle under load are the theme, the app scripts, and the outside services you added, not the parts Shopify runs. Run the full audit, and start with any app that accepts custom code in its settings.
Past $1M, and certainly past $5M, uninstalling is harder because more apps carry real workflows. Here the move is a short register: app name, owner, what it loads on the storefront, whether it accepts custom code, and the date you last confirmed its settings. Then ask each vendor in writing what changed on your store in October and whether their app was involved. A vendor who cannot answer that clearly has told you something useful.
Whatever your stage, resist the urge to fix this by buying another app. Our Black Friday apps roundup carries a skip condition on every pick for a reason. Adding a script monitoring tool to a store with 30 unowned apps adds one more script. Subtract first.
This audit tells you whether your storefront is clean today, not whether shoppers were affected before you looked. It also cannot promise that an app you keep will never be changed by someone else next week. Those limits are real, and pretending otherwise would do you a disservice.
If you ran any of the named apps in October, the private window test only shows the current state. It will not show whether a fake checkout ran on your store on October 13. For that, ask the vendor directly, check whether customers have reported unexpected card charges, and talk to your payment processor before Black Friday rather than after. cside also recommends rotating your Shopify and app vendor passwords, turning on two factor authentication, and reviewing who has staff or collaborator access, which is a sensible 10 minute addition for anyone who wants to go one step further.
The other limit is scope. This is a storefront audit. It does not review your theme’s own code, your tracking pixels in Customer events, or the private apps an agency built for you. Digismoothie suggests scanning the live theme and reviewing pixels too. If you have a developer or agency on retainer, hand them that part. If you do not, the three steps above still close the doors that mattered most this month.
And one honest note on my own perspective. I do not run a store. What I know about app stacks comes from six years inside Shopify working with brands like these, hundreds of podcast conversations with founders and agency partners, and reading everything I can find when something like October happens. The advice here is deliberately boring, because the boring version is the one people actually finish.
You check by testing checkout from a fresh private window and confirming the page stays on your own domain or your myshopify.com address. Open a new private window, add a product, and click the standard Checkout button rather than Shop Pay or another express option, then repeat from the cart drawer and on your phone. The malicious script fired only once per browser session, so testing in your everyday browser can miss it. This only shows your store’s current state. If you ran Hulk Product Options, Selleasy or Swym Wishlist Plus in October 2026, also ask the vendor in writing whether your store was involved and talk to your payment processor.
Hulk Product Options, Selleasy and Swym Wishlist Plus are the apps whose vendors confirmed unauthorized changes in October 2026. HulkApps said unauthorized configurations reached Hulk Product Options on October 10, Selleasy confirmed an incident window on October 13, and Swym reported configuration changes on October 14 and new activity on October 18, after which it disabled the app for every merchant. Other apps were pulled from the App Store during the same weeks, but not every delisted app was linked to the attack, so treat any wider list you see as unconfirmed unless the vendor itself has said so.
No, you need to remove the storefront apps nobody uses and give every remaining app an owner. Keep the apps that take payment, handle shipping, collect reviews and capture email, because those protect sales. Uninstall anything installed for an old test, a past promotion or a team member who has left. Turning off an app embed is not the same as uninstalling, so remove the app itself if nobody would notice it was gone. Stores under $500K a year can usually cut the most. Larger stores should focus on ownership and on asking vendors what their apps loaded and when.
Test your Shopify checkout at least once a week from now through Cyber Monday, and again after any app update or theme change. Each test takes about five minutes: open a fresh private window, add a product, click the standard Checkout button, and confirm the address bar shows your own domain or your myshopify.com address. Repeat from the cart drawer and on a phone. A fresh window matters because the October script fired only once per session. Some agencies automate this with a browser testing tool, which is worth it once you are running paid traffic at scale.
No source has said Shopify’s own checkout or systems were breached in October 2026. The fake checkout pages ran on outside domains, and the malicious code ran on storefront pages through third party app settings before Shopify’s checkout loaded. Shoppers who were redirected entered card details on the attacker’s page and were then forwarded to the store’s real Shopify checkout, which is why orders still went through normally. That distinction matters for what you do next: the fix lives in your app list and your testing habits, not in switching away from Shopify’s checkout.
