Several Shopify app vendors have acknowledged unauthorized changes that caused some storefronts to send shoppers from a checkout button to fake payment pages in October 2026.
Public reports and vendor statements have tied confirmed October cases to Hulk Product Options from HulkApps, Selleasy from Logbase, and Swym Wishlist Plus. In the first public case, developer Roman Zipp traced a fake checkout redirect on October 10 while shopping on a Shopify store. HulkApps later said an exploit introduced unauthorized configurations into Hulk Product Options, affected the app’s theme extension, and redirected some checkouts to a fake external checkout page.
Logbase said Selleasy was hit on October 13 by a planned cyberattack in which an unauthorized script was injected into some stores served by the app. The company said it found no evidence of a data breach or leak in the Selleasy backend or database, fixed the root cause within hours, and contacted affected merchants.
Swym said an unauthorized party changed the Swym Wishlist Plus app configuration on October 14 between about 10:06 UTC and 11:56 UTC, causing a script to load on some storefronts. Swym said shoppers who clicked checkout on affected pages may have been redirected to an imitation checkout page designed to collect payment card details. In an October 20 FAQ, Swym said it paused the app for all merchants as a precaution and that customer data may have been compromised if shoppers entered details manually on the external site. By October 23, Swym said it was restoring access for merchants in batches while monitoring its systems.
Those confirmations do not turn every App Store removal or merchant report into a confirmed compromise. Several posts and trackers have linked other delisted or unavailable apps to the same wave, but a delisting by itself can happen for many reasons. Until a vendor, Shopify, or a technical analysis ties a specific app to malicious storefront code, those reports should be treated as unconfirmed.
How shoppers could be redirected without a broken order flow
The public evidence points to third-party app code running on storefront pages before Shopify’s hosted checkout loaded, not to a proven compromise of Shopify’s checkout itself. Shopify’s checkout architecture heavily restricts custom code, and the company has previously described sandboxing as a way to isolate app-provided code there.
On storefront pages, third-party app code may be allowed to read the page, alter elements, and intercept clicks. In the Hulk Product Options case, cside’s technical analysis found the app’s file served from Shopify’s CDN was unchanged. The attacker-controlled JavaScript arrived through app configuration data returned by the vendor’s API, then ran inside the storefront.
That script could wait for a shopper to click checkout, cancel the normal navigation, and send the shopper to a lookalike payment page on another domain. After collecting details, the fake page could forward the shopper to the real checkout, allowing the order to complete and making the merchant’s sales data look normal.
Zipp and cside both reported behavior that made the hijack harder to reproduce, including a once-per-browser-session trigger. A merchant testing the same cart twice in the same browser could see the genuine checkout on the second attempt and miss the earlier redirect.
Shopify added redirect warnings, then narrowed them
Shopify posted a changelog entry on October 20 saying online stores would ask customers to confirm before being sent to websites outside the store. The company said connected store domains and supported Shopify or social websites would not trigger the message.
On October 23, Shopify updated the same changelog entry. The updated note says storefronts now block links only to websites Shopify has identified as malicious and ask for confirmation only for websites Shopify considers suspicious. Otherwise, customers go directly to other websites.
The change shows Shopify is adding platform-level friction around unexpected redirects, but it also shows why app review still matters. A warning based on malicious or suspicious domain identification is useful only when the destination has already been flagged. Fresh phishing domains can appear before blocklists or reputation systems catch up.
Shopify is pressuring app developers to tighten access
In a separate October 20 developer post, Shopify told app developers to act that week. The requested steps included running Shopify-specific security checks, moving to expiring access tokens, sanitizing rendered data, reviewing API logs, enabling two-step authentication across accounts, and keeping emergency contacts current.
Shopify also said it is tightening boundaries for storefront app code, adding IP address restrictions so keys work only from developer servers, and raising App Store security requirements. The post did not name the checkout-hijacking incidents directly, but its timing and focus match the risk exposed by the public reports: a trusted app can become a delivery channel if its configuration, access token, internal tool, or rendering path is abused.
Merchant checks that matter now
For Shopify merchants, the immediate priority is to identify which apps can run code before checkout. That includes theme app extensions, app embeds, app blocks, scripts loaded by themes, tag managers, and any app setting that accepts custom JavaScript or HTML.
Merchants should also consider whether each app needs to execute code on the storefront, whether its vendor can change runtime configuration without a new Shopify release, and how quickly they would notice if that configuration changed.
Useful checks include:
Testing checkout from a fresh private browser window and verifying the address bar before entering payment details.
Repeating the test in a new session or on a second device, because reported payloads could run only once per session.
Turning off app embeds that are not recognized or not actively used.
Reviewing app settings for custom JavaScript, HTML, button labels, rich text fields, and other content that is rendered into storefront pages.
Checking recent theme file changes, especially when an app has permission to edit themes or Swym has contacted the merchant about an impact.
Capturing URLs, screenshots, timestamps, app names, and browser details before disabling suspected code, then reporting the issue to Shopify and the app vendor.
If shoppers report that a store sent them to a different domain before payment, the issue should be treated as a possible payment-data exposure until the app vendor, Shopify, payment processor, and appropriate advisors say otherwise. Swym’s own incident guidance notes that merchants may have separate notification obligations under breach-notification laws, data protection laws, or payment-processor agreements.
What remains unknown
As of October 23, public reporting has not established a complete list of affected apps, the number of affected stores, the number of shoppers who entered details on fake pages, or whether the incidents came from one actor or multiple actors using similar techniques. Vendor statements also do not provide a full root-cause account for every case.
For merchants, app inventory and checkout-path testing are now part of payment-security monitoring, not just store maintenance.
Get new small business insights by email
Practical ideas and useful articles to help you make better business decisions.
Tech Help Canada Staff researches, writes, and reviews practical content for business owners and professionals. Our coverage spans business, marketing, SEO, technology, and the tools and systems people use to grow and operate online. We focus on clear, useful information backed by research, hands-on experience, and editorial review. Learn more about our team and editorial standards. Need help with something? Contact Us
