Shopify App Delisted in October 2026? How to Tell If It Is Safe and Audit Every App on Your Store

If you opened the Shopify App Store in October 2026 and found one of your apps missing, you were not alone. The HeyApps delisted apps tracker currently counts 570 apps no longer on the Shopify App Store, with 125 since restored. The delisting dates in its October list run from October 15 to October 28, 2026, and they include some of the biggest names in the store, such as Booster AI SEO + AEO Optimizer (over 5,500 reviews), Privy (over 4,200), and Color Swatch King (over 3,100).

That happened at the same time as a wave of confirmed checkout hijacks, where attackers used a few trusted apps to send shoppers to fake payment pages. So it is natural to connect the two.

Most of the time, you would be wrong.

I build and run Shopify apps, and I have spent the last two weeks fielding the same message from merchants: "My app disappeared from the App Store. Am I hacked?" This guide answers that question properly, then walks you through auditing every app on your store, delisted or not.

What "Delisted" Actually Means

When an app is delisted, it no longer appears in App Store search or category pages. That is all the word means on its own.

An app can be delisted because:

• It failed to meet an updated App Store requirement on time
• The developer chose to unlist it, for example to stop new installs while fixing something
• It is being replaced by a new listing
• Shopify paused it during a review
• Shopify removed it for a policy or security reason

In most of these cases, the app keeps working on stores where it is already installed. Delisting stops new installs. It does not uninstall the app from your store or switch it off.

So the useful question is not "was it delisted?" but "has the developer or Shopify confirmed a security issue, and what did they say to do?"

How to check whether your app was delisted

The quickest way is the HeyApps delisted apps tracker. It lists every app no longer on the Shopify App Store, sorted by review count, with the date it was delisted and a separate "Recovered" tab for apps that have come back. It keeps the archived listing pages and reviews, so you can still see what an app was and how merchants rated it. If you sign in, you can set email alerts for when a specific app is delisted or returns, which is useful for the handful of apps your store depends on.

The tracker itself is careful on this point: it notes that delisting alone does not mean an app was hacked, and that it is unclear whether any of the October delistings are related to the checkout attacks. Use it to find out what changed, then use the confirmed list below and the developer's own notice to find out why.

A few things the numbers tell you:

• 125 restorations out of 570 shows many delistings are temporary, often while a developer works through a review or a requirement
• Big apps were affected, not just small ones. Review counts in the thousands appear on the list, so delisting is not a sign that an app is low quality
• The confirmed hijack cases are a tiny share. Only a few apps on the list have been confirmed as part of the checkout attacks

What Has Actually Been Confirmed

Here is the confirmed list as of October 28, 2026, based on the developers' own statements. For the full technical timeline, see Shopify checkout hijacking, October 2026: affected apps and timeline.

And here is what is not confirmed:

If your app is in the second table or not on either list, there is no public evidence it was compromised. That does not mean you skip the audit below. It means you do not need to panic-uninstall something your store depends on.

The Pattern Behind the Confirmed Cases

Looking at the confirmed incidents together, a clear pattern shows up.

The merchant's theme was clean. In every confirmed case, the malicious code did not live in the store's theme files.

Shopify's checkout was untouched. The attack sent shoppers away from checkout, not into a broken one.

The code came through app settings. Most of these apps had a feature that let someone paste custom JavaScript or HTML, which the app then loaded on every storefront. Attackers got access to the vendor's side and used that feature.

It loaded from the vendor's servers. The app fetched its settings, and the settings contained the attack. Nothing on the merchant's side changed.

That pattern tells you where to look. Apps that can run custom code on your storefront carry more risk than apps that only work inside your admin.

How to Audit Every App on Your Store

Set aside an hour. You do not need to be technical for most of this.

Step 1: Make a list

Go to Settings, then Apps and sales channels. Write down every app, what it does, and whether you actually use it.

Then ask a simple question for each one: if this app vanished tomorrow, would anything break? If the answer is no, uninstall it. Every unused app is still access to your store.

Step 2: Sort apps by risk

Put each remaining app into one of three groups:

Higher risk: apps that put code on your storefront

• Product options, upsells, bundles, sticky carts, menus
• Wishlists, reviews, popups, chat widgets
• Any app with a "custom JS," "custom CSS/HTML," or "advanced code" setting

Medium risk: apps with wide data access

• Apps that read or edit orders, customers, or discounts
• Old custom apps built by freelancers or agencies

Lower risk: admin-only tools

• Reporting, inventory, or internal workflow apps that never touch the storefront

Spend most of your time on the first group.

Step 3: Check app embeds

Open your theme editor and go to App embeds. You will see every app that injects code into your storefront. Turn off anything you do not recognize or do not need.

Then check your theme code (or ask your developer to) for snippets left behind by apps you uninstalled. Old snippets can keep loading scripts from servers you no longer have a relationship with.

Step 4: Inspect custom code fields

For every app with a custom code setting, open it and look at what is there. If you see code you or your developer did not add, disable that app's embed right away and contact the developer.

If you do not need the custom code feature, leave it empty.

Step 5: Check permissions against purpose

Open each app's details and look at the access it has. A wishlist app reading customer data makes sense. A wishlist app editing orders does not. If the access looks wider than the job, ask the developer why.

Step 6: Test checkout properly

Open a new private window, add a product, click Checkout, and confirm you stay on your domain or checkout.shopify.com. Close the window fully and repeat several times, on desktop and mobile. The October scripts fired only once per session, so one test can miss it.

On desktop, you can also open DevTools, go to Application, then Session storage, and check for keys starting with __ctf_. That is a confirmed sign of the October campaign.

Step 7: Secure the accounts around your apps

• Require two-step authentication for every staff and collaborator account
• Remove former staff, freelancers, and agencies
• Review old custom apps, which since January 1, 2026 can only be newly created through the Dev Dashboard, and remove any that are no longer maintained

Step 8: Ask your critical vendors five questions

For the apps your store depends on, email the developer:

• Who can change the code your app loads on my storefront, and is that protected by two-step authentication?
• Do you log and alert on changes to custom code settings?
• Have you run Shopify's new shopify app security check and fixed the findings?
• Do you use expiring access tokens?
• What is your incident response process, and how will you notify me?

A good developer will answer quickly and clearly. A vague answer is useful information too.

Step 9: Plan a fallback for critical apps

If one app powers something your store cannot run without, such as your product page options or main navigation, know what you would do if you had to switch it off for a day. Sometimes that is a simpler built-in Shopify feature. Sometimes it is a second app you have already tested.

If Your App Was Delisted: A Quick Decision Guide

The developer published a notice explaining it. Read it and follow the instructions. Test your checkout.

The developer says it was a security incident and it is fixed. Test your checkout several times, check session storage for __ctf_ keys, and review any custom code fields. If everything is clean, you can usually keep using it. Ask what changed to stop it happening again.

The app was confirmed as part of the checkout hijacks and is not restored. Disable its storefront embed until the developer confirms it is safe.

There is no explanation at all. Email the developer. While you wait, test checkout and, if the app loads code on your storefront, consider disabling its embed until you hear back. If it is admin-only, there is less urgency.

If You Find Something Wrong

• Put your store behind a password
• Disable the suspect app's embed
• Save screenshots, a HAR file from DevTools, and timestamps before removing anything
• Contact Shopify Support, the app developer, and your payment provider
• Work out which orders and customers may be affected
• Check your notification obligations under local law
• Retest before reopening

Why "Build Everything In-House" Is Not the Answer

After incidents like this, some agencies suggest replacing apps with custom code. For a few critical features at large brands, that can make sense. For most stores, it trades one risk for another. Custom code built by a contractor who moves on is often less maintained and less monitored than a well-run app.

The better answer is fewer apps, chosen carefully, with a clear owner on your team who checks them regularly.

What Shopify Is Changing

Shopify has asked every developer to act on a security checklist and has announced three upcoming changes: tighter limits on storefront app code, IP restrictions on API keys, and higher App Store security requirements. Over time, that should make the custom-code path that attackers used much harder to abuse.

For the full list of changes and checklists for both merchants and developers, read my Shopify app security update 2026 guide.

Frequently Asked Questions

Does a delisted Shopify app stop working on my store?

Usually not. Delisting removes the app from App Store search and stops new installs. Installed apps typically keep working unless the developer or Shopify disables them.

Is my app unsafe because it was delisted?

Not necessarily. Many apps were delisted in October 2026 for reasons unrelated to security. Check for a developer notice and test your checkout.

Which delisted apps were actually part of the attacks?

Confirmed by developers: Hulk Product Options, Selleasy, and Swym Wishlist Plus in October, plus earlier cases from Qikify (July) and Orichi (September).

What type of app carries the most risk?

Apps that load code on your storefront, especially those with custom JavaScript or HTML settings. Those were the entry point in most confirmed cases.

How often should I audit my apps?

Do a full audit now, then a quick review every quarter and after any major app update or team change.

Last checked October 29, 2026. This guide will be updated as developers and Shopify publish more information.

Sources

• Delisted Shopify apps tracker (HeyApps, figures as of October 29, 2026)
• What our July security incident taught us (Qikify)
• Inside the HulkApps Shopify checkout hijack (cside)
• Securing your app, together (Shopify developer changelog)
• Legacy custom apps can't be created after January 1, 2026 (Shopify changelog)
• Public incident statements from HulkApps, Logbase, Swym, and Orichi