Shopify Checkout Hijack: Hacked Apps, Fake Checkouts

A checkout hijack, also reported as Shopify checkout phishing, is an attack that intercepts the click from a store's cart to its payment page and sends the shopper somewhere else. From 10 October 2026, at least three Shopify apps did this on an unknown number of stores: shoppers who pressed Checkout saw a lookalike checkout on an attacker's domain, entered card details, then were forwarded to the real Shopify checkout, so the order completed as normal.

The code did not come from Shopify and did not sit in the store's theme. It arrived through hacked Shopify apps: third-party storefront apps whose settings had been changed without authorisation. An app embed is the switch in the Shopify theme editor that lets an installed app load its own code on every page of the online store; the code itself comes from the developer's servers, not the theme. If you run a Shopify store with any app embed enabled, the five-minute test below is the one thing to do today.

What have HulkApps, Logbase and Swym said about the checkout hijack?

All three developers say an unauthorised party changed what their app loaded on some storefronts, not the app code Shopify reviews, and each has published a statement; none has published a store count.

The attack was found on 10 October 2026 by developer Roman Zipp, who was buying a keyboard on a Shopify store when his password manager offered to fill a card name into a "First name" field and he noticed the address bar showed biliing[.]top, not the store or Shopify. His write-up, updated through 22 October, is the primary record, and his follow-up collects the developers' statements. In summary:

• HulkApps: as part of "a wide attack that also impacted multiple Shopify apps", an exploit introduced unauthorised configurations into Hulk Product Options on 10 October 2026. These affected the app's theme extension and redirected some checkouts to a fake external checkout page. Shopify temporarily disabled the theme extension until the code was removed. HulkApps has strengthened authentication, added safeguards against unauthorised configuration changes, and engaged an independent firm for incident response and a penetration test. It has not published a root cause.
• Logbase (Selleasy): on 13 October 2026 an attacker reached a legacy internal support tool through an anonymising network and used it to add a malicious script to the settings of a number of stores, starting at 07:47 UTC. Logbase disabled custom scripts across all Selleasy stores at 12:22 UTC, reported to Shopify at 14:59 UTC, and had every affected store cleaned by 15:58 UTC. It shut the tool down permanently, rotated app credentials on 15 October, commissioned Astra Security for assessment and penetration testing (16 to 20 October), and says merchants' Shopify accounts and credentials were not used.
• Logbase, continued: Selleasy returned to the App Store on 27 October.
• Swym (Wishlist Plus): an unauthorised party changed the app's configuration between about 10:06 and 11:56 UTC on 14 October 2026 through an "access channel" since secured, which made a script load on certain pages of a limited subset of storefronts. Fixes were fully deployed by 16:32 UTC.
• Swym, continued: Swym restricted the endpoints involved, rotated API secrets and credentials, added input sanitisation, and advises merchants to consider notifying shoppers who typed a card number directly into checkout between 10:06 and 16:32 UTC that day. Its investigation is ongoing.

As of 7 November 2026 we have found no Shopify statement naming the incident beyond the changelog entries. In the Community thread, merchants describe contact through support and the security team; one merchant in the Shopify Community thread writes that Shopify's security team advised keeping the store closed for almost 48 hours after a customer was redirected on 13 October.

Which Shopify apps and dates are confirmed?

Three apps are confirmed by their own developers: Hulk Product Options, Selleasy and Swym Wishlist Plus. Boost, Privy, 17TRACK and Consentmo are merchant reports or temporary de-listings only, and Qikify is a separate July incident using the same technique.

The attacker domains reported so far in Zipp's write-up are biliing[.]top, checkout-confirm[.]top, order-confirm[.]top, account-confirm[.]top and billing-confirm[.]top. Zipp notes that most were still not on the common blocklists when he last checked, so a browser warning is not something to rely on.

Does the checkout hijack affect Shopify, Shopify Plus, WooCommerce or BigCommerce stores?

The campaign targeted Shopify storefronts, but the technique applies to any platform that lets a third-party script load its own instructions at runtime.

How did the Shopify checkout hijack work?

In the confirmed cases the hijack had five steps: a clean app file loaded from Shopify's CDN, a settings request to the developer's API, attack code returned in a custom JavaScript field, a click handler that cancelled the real Checkout navigation and redirected the shopper to a lookalike checkout on the attacker's domain, and a fake page that captured the card and forwarded the shopper to the genuine Shopify checkout. The clearest technical account is c/side's analysis of the HulkApps case, which matches what Zipp traced in his browser:

1. A clean file loads. Hulk Product Options ships a theme app extension that loads hulkcode.js from Shopify's CDN. That file was not modified.
2. The file asks for its configuration. On page load it calls the HulkApps API with the store and product. The JSON reply includes a custom_js field, a feature that lets merchants add their own JavaScript.
3. The configuration carries the attack. On affected stores that field held about 22 KB of attack code, which the app wrote into the page as a script. In developer tools it shows as an anonymous script with no source file.
4. The Checkout click is hijacked. The script listens for the click, cancels the real navigation and redirects to a lookalike checkout on the attacker's domain.
5. The card is captured, then the shopper is passed on. The fake page posts the form to the attacker's server, then sends the shopper to the genuine Shopify checkout. It also sets a session flag so it fires only once per browser session, which is why merchants who refreshed the page could not reproduce it.

By their own accounts, Selleasy and Swym were hit the same way, through settings their apps read at runtime rather than through the app code Shopify reviews. That is why searching your theme files found nothing: the payload was never in the theme.

How do I check if my Shopify store has the checkout redirect?

The test takes about five minutes: open a private window, add a product, press Checkout and read the address bar. Then work through the other four checks below.

1. Run the live checkout test. Open a private browser window, add a product to the cart, press Checkout and read the address bar. It must be your store domain, your myshopify.com domain or checkout.shopify.com; if Shop Pay opens, that page is on shop.app. Repeat in a fresh private window, because the hijack fired once per session, and test on a phone as well as a desktop.
2. List every app that runs code on your storefront. In the Shopify admin go to Online Store, Themes, Customize, then App embeds. Each enabled embed is code a third party can change after Shopify's review. Note which ones you actually use. Since 5 November 2026, Settings, Apps in the admin also shows each app's latest activity, flags security issues, and says whether the app uses expiring access tokens and IP restrictions, per Shopify's changelog.
3. Search for the known markers. Download the theme (Online Store, Themes, the three-dot menu, Download theme file) and search every file for biliing, checkout-confirm, order-confirm, account-confirm and billing-confirm. A clean result does not clear you, because the October payload never touched theme files, but a hit is proof.
4. Look in the browser's network tab. On the cart page open developer tools, go to Network, tick Preserve log, press Checkout and look for any request to a domain you do not recognise. Merchants in the Community thread also reported the markers __ctf_shim_handoff_done_v1 in session storage and SWYM139, __lby139_ and _lb139t in injected scripts.
5. Ask your customers. Check support mail and chat for anyone who mentions a strange checkout, a card declined on a page that looked wrong, or a password manager behaving oddly. The first reported case was found by a shopper, and merchants in the Community thread describe customers raising the alarm.

What should I do if my store redirected shoppers to a fake checkout?

Contain the app first, then report, notify and rotate, in that order.

• Contain first. Disable the app embed for the suspected app in the theme editor, or uninstall the app, then rerun the checkout test in a new private window.
• Report it. Contact Shopify support with the fake domain, the time and a screenshot, and tell the app developer; Logbase and Swym both published contact routes for affected merchants.
• Tell shoppers who may have typed a card number. Swym's advice is specific: anyone who entered a card directly at checkout during the affected window may need a notice; Shop Pay, PayPal, Google Pay and similar wallets were not captured the same way. Check your obligations under UK GDPR, PCI DSS and your payment processor agreement.
• Rotate what the apps could reach. Change your Shopify password and your account passwords on HulkApps, Swym or Selleasy, and review which staff accounts, AI tools and agents have access to your store.

What if I cannot remove the app today?

Disabling the app embed stops the storefront code without losing the app's data; the three steps below cover that and what to ask the developer.

• Turn off the embed, keep the app. Disabling an app embed in the theme editor stops its storefront code without uninstalling the app or losing its data; Boost and Swym both told merchants to re-enable the embed once they were clear.
• Ask the developer to lock the custom code field. Logbase locked Selleasy's Custom JS setting so it cannot be changed through any tool or API. Ask every app with a custom JavaScript or free HTML field whether changes are logged and whether it can be locked.
• Watch the request log, not the theme. Until the embed is off, the only reliable signal is the live test and the network tab, repeated daily, because the payload can be re-served from the developer's side at any time.

How do I stop app embeds hijacking checkout in future?

Every app embed is code someone else can change at any time, without a new App Store review, because the embed can fetch its instructions from the developer's servers at runtime. Three habits cut the exposure:

• Keep only the embeds you use. Enabled embeds for apps that were trialled and forgotten are a common finding in a Shopify store audit. Each one can load new code without a new App Store review.
• Prefer settings you can see. If an app offers a custom JavaScript or free HTML field in its own dashboard, that field is exactly where this campaign hid.
• Run the checkout test on a schedule. Once a week, in a private window, on desktop and mobile. It takes five minutes and it is the same check that found the first reported case on 10 October.

On the AI question: ADWEEK reported on 3 November that some developers suspect AI tooling behind the attacks.

The only app developer to put that in writing is Qikify, whose July notice says credentials now leak from more places than before, including AI coding assistants and agents connected to codebases and stores with too many permissions, and that it is not blaming people who use those tools. HulkApps, Logbase and Swym have not attributed their incidents to AI. We will add a dated update when any of them publishes a root cause.

What has Shopify changed for app developers?

Shopify has not named the apps or the campaign, but its developer blog carries three security posts in the same three weeks, each marked action required:

For a merchant the practical effect is the Settings, Apps page: from 20 November an app that has not locked its API access to its own servers is flagged there, which is a reasonable signal for deciding which apps to keep.

What to do next

Run the checkout test now, then book an hour this week to go through App embeds and switch off everything you do not use. Shopify's published deadlines point the same way: script tags stop running on storefronts on 1 March 2027 and public apps must use expiring tokens from 1 January 2027, both covered in our Fall 2026 Editions post.

For the wider pattern of trusted dependencies turning into delivery channels, see the LiteLLM supply chain attack from the same month. If you want a review of which apps run code on your storefront and what each one can change, our Shopify development team does that review as part of a store audit.