A successful order does not always mean a customer’s payment details were handled safely. A series of security incidents affecting Shopify merchants has exposed a particularly deceptive form of online payment fraud: criminals intercept the journey to checkout, collect card information on a counterfeit payment page, and then return the shopper to the genuine checkout to complete the purchase.
The retailer receives the order. The customer receives an order confirmation. The payment provider processes the legitimate transaction. Yet sensitive card information may already have been transmitted to a server controlled by criminals.
During October 2026, security researchers and several Shopify app developers confirmed incidents involving malicious JavaScript delivered through third-party applications. The affected products included Hulk Product Options, Selleasy and Swym Wishlist Plus.
The attacks did not require criminals to compromise Shopify’s core checkout infrastructure. Instead, they exploited the ability of certain applications to supply executable code to storefront pages before customers reached the protected payment environment.
Understanding that distinction is essential. A secure hosted checkout cannot fully protect shoppers if malicious code redirects them to a fraudulent payment page before they arrive there.
What Is Shopify Checkout Hijacking?
Checkout hijacking is an attack in which unauthorized code changes the destination of a customer’s checkout action.
Rather than allowing the shopping cart to open the store’s legitimate checkout, the malicious script sends the shopper to another website. That external website imitates a genuine payment page and asks for information such as the customer’s name, card number, expiry date and card security code.
The criminal website may then display a temporary payment error or continue to the real checkout.
Unlike conventional phishing emails, this attack begins on a genuine online store. The customer has not necessarily followed a suspicious link, visited an unfamiliar advertisement or entered a fraudulent website directly.
They may have navigated to the retailer through a bookmark, search engine result or normal product link.
The deception occurs only when an apparently legitimate checkout button leads somewhere unexpected.
This makes the attack especially dangerous for retailers because the customer’s trust in the genuine store can be transferred to the counterfeit payment page.
How the October 2026 Shopify Payment Attacks Were Discovered
On October 10, 2026, software developer Roman Zipp encountered an unexpected payment page while attempting to calculate shipping costs for a purchase at mechanicalkeyboards.com.
After adding a product to his basket and proceeding towards checkout, his browser opened a convincing payment form hosted at an unrelated address.
The suspicious destination used the domain biliing.top, which closely resembled a payment-related service name.
Zipp investigated the website’s JavaScript execution and discovered that the redirection originated from functionality associated with the Hulk Product Options application.
His investigation revealed a crucial detail: the malicious code was not necessarily stored inside a modified Shopify theme file.
The application’s legitimate JavaScript requested configuration data from HulkApps infrastructure. The returned data contained an additional JavaScript payload that could execute within the storefront.
Further reports connected similar checkout redirections to other Shopify applications over the following days.
Confirmed incidents and developer responses
| Application | Incident | Developer’s findings |
|---|---|---|
| Hulk Product Options | October 10, 2026 | Unauthorized configuration changes affected its theme extension and redirected certain checkout attempts. The supplier reported removing the code and strengthening security controls. |
| Selleasy by Logbase | October 13, 2026 | An unauthorized party accessed an internal tool and introduced malicious JavaScript into settings for some merchants. Logbase reported removing the script and addressing the cause. |
| Swym Wishlist Plus | October 14, 2026 | Unauthorized changes to application configuration caused malicious code to load on a limited number of storefronts. Swym reported completing its mitigation measures that day. |
| Qikify Sticky Add to Cart and Mega Menu | July 22, 2026 | An earlier, separate incident involved malicious content in customizable application fields. Qikify reported resolving the issue in July and completing further security reviews. |
These incidents should not be interpreted as evidence that every merchant using the listed applications was compromised.
The developers described specific affected installations and exposure periods. Each company reported remediation work, while the extent of customer exposure remained a separate question requiring investigation.
There is also insufficient public evidence to attribute all the incidents to one attacker or one shared vulnerability.
How Criminals Turn an Ordinary Checkout Button Into a Phishing Trap
The most revealing aspect of the October attacks was the separation between the application code customers normally load and the additional instructions supplied through the application’s configuration system.
This explains how a storefront could begin redirecting shoppers without its theme files being visibly altered.
A legitimate app loads dynamic configuration
Third-party applications frequently add functionality to Shopify storefronts through app blocks, app embeds or JavaScript resources.
These applications may load product options, upsell offers, wishlist controls, cart enhancements or other interactive features.
Some of them retrieve configuration information from servers operated by the application developer.
In the Hulk Product Options case, the investigation identified a request to an application API that returned a configuration field named:
advanced_users.custom_jsThe field contained approximately 22.7 KB of JavaScript associated with the attack.
The distinction matters because the application could be delivered through a legitimate Shopify content delivery network while its runtime configuration contained unauthorized instructions.
A familiar script URL or trusted delivery domain therefore does not guarantee that everything executed by the script is safe.
The malicious code observes checkout activity
Once executed, the injected JavaScript could interact with the storefront and detect when a shopper attempted to continue from the shopping cart.
The code could also obtain information about the basket, allowing criminals to construct a convincing payment experience.
Depending on the implementation, this might include product details, quantities, prices and the order total.
Displaying accurate basket information makes the fraudulent page appear more credible than a generic phishing form.
The browser is redirected before genuine checkout begins
At the point where the customer clicks Checkout, the malicious code can interrupt the expected action and instruct the browser to navigate to an external website.
The shopper is no longer interacting with the retailer’s authorized payment flow.
Instead, they encounter a page that imitates the layout of a familiar e-commerce checkout.
The attacker may use branding, order summaries and payment-related language to encourage the customer to continue.
Payment details are sent to the attacker’s infrastructure
In the investigated case, the fake checkout collected payment information and transmitted submitted data to an external endpoint.
The researcher demonstrated this behavior using test information, confirming that the counterfeit page was capable of receiving details entered by shoppers.
A payment card number combined with an expiry date and security code can create a serious financial risk if obtained by criminals.
The fraudulent page did not need to charge the card itself to cause harm. Collecting usable payment details was sufficient to create the possibility of subsequent unauthorized activity.
The customer is transferred back to Shopify
After the fraudulent submission, the victim could be redirected to the legitimate checkout.
From that moment, the order might continue normally.
The merchant’s dashboard could show the expected payment status, product quantities, shipping details and customer record.
Nothing in that ordinary order record necessarily indicates that the shopper first encountered a criminal payment form.
This is the defining danger of checkout hijacking: the fraudulent step can be hidden inside an otherwise successful transaction.
Why a Standard Website Security Check May Miss the Attack
Many website security assessments concentrate on suspicious files, unexpected changes to the theme and known malicious domains.
Those checks remain useful, but the October incidents demonstrate several limitations.
There may be no modified theme file
If the unauthorized script is delivered through an application API response, comparing the current Shopify theme against an earlier backup may reveal no relevant changes.
The malicious behavior can originate from remotely supplied settings rather than from code stored in the retailer’s theme.
Investigators must therefore examine dynamic responses and application-controlled configuration, not just static assets.
The first checkout attempt may behave differently
In the HulkApps-related incident, the script used browser session storage to record that a checkout redirection had already occurred.
One observed marker was:
__ctf_shim_handoff_done_v1Once the marker was present, subsequent checkout attempts during that browser session could proceed without showing the fake page again.
This behavior can defeat a casual verification attempt.
A customer reports a suspicious checkout, the store owner tries again, and everything appears normal.
For reliable investigation, tests should start in genuinely fresh browser sessions, rather than repeatedly reloading the same window.
Store analytics may not show an obvious anomaly
A shopper who completes payment after being redirected back to the authentic checkout can generate a normal-looking order.
Traffic reports, payment success rates and conversion metrics may therefore fail to reveal the initial fraudulent step.
An unexplained change in sales performance can justify investigation, but stable sales figures cannot establish that checkout redirections are absent.
Fraudulent domains can change quickly
The observed campaign used several payment-related domains. Examples identified during the investigation include:
biliing[.]topcheckout-confirm[.]toporder-confirm[.]topaccount-confirm[.]topbilling-confirm[.]top
These are historical indicators of suspicious activity, not a complete catalogue of possible destinations.
An attacker can register additional domains or alter redirect logic. Blocking only the known addresses would therefore provide incomplete protection.
Similarly, a particular top-level domain is not proof of fraud. The full destination, its role in the payment process and the legitimacy of the service must be considered together.
How to Perform a Practical Checkout Security Audit
Merchants can carry out several meaningful checks without gaining access to Shopify’s internal infrastructure.
The objective is to determine whether customers are being directed through the authorized checkout process and to identify which applications can influence that journey.
Check 1: Establish the expected payment route
Document the legitimate domains involved in your payment flow.
Depending on the store configuration, checkout may operate under the merchant’s connected domain, a Shopify-controlled address or an authorized payment provider.
Services such as accelerated checkout and external payment methods may involve legitimate redirects.
The important question is whether every destination has an identifiable and approved purpose.
A generic assumption that every external domain is malicious would produce false alarms and could interfere with valid payment methods.
Check 2: Test checkout in a new private browser session
- Open a fresh private browsing window.
- Visit the store through its normal public address.
- Add a product to the shopping cart.
- Proceed to checkout using the usual customer controls.
- Inspect the destination URL carefully.
- Stop immediately if an unfamiliar page requests payment details.
- Repeat the assessment with a separate new session and, where practical, another device.
Do not submit real payment card information to a page suspected of being fraudulent.
Where full payment testing is required, use approved test facilities or controlled transactions through the genuine payment provider.
Check 3: Record navigation requests
For a more technical investigation, open the browser’s developer tools and select the Network panel.
Enable Preserve log before navigating towards checkout. This allows network activity to remain visible when the browser moves between pages.
Review document navigation, JavaScript requests and other relevant network entries for unexpected destinations.
Remember that the malicious action may occur only during the first checkout attempt in a session.
If evidence must be shared with a security investigator, ensure that exported network logs are protected and sensitive values such as authentication tokens or session cookies are removed where appropriate.
Check 4: Inspect installed applications and storefront embeds
Open Shopify administration and review the Apps and sales channels section.
Identify applications that modify product selection, cart behavior, navigation elements, checkout buttons or storefront JavaScript.
Then inspect the active theme using the theme editor.
App blocks and app embeds deserve attention because they allow third-party functionality to appear on storefront pages. Some app embeds can also run code without creating an obvious visual component.
Examine any custom HTML or JavaScript settings exposed by the applications.
These capabilities are not inherently malicious, but they increase the importance of strong access control and safe handling of externally supplied code.
Check 5: Review evidence beyond the active theme
Application configuration, dynamic script responses, browser session storage and third-party endpoints may contain indicators that do not exist in theme files.
A comprehensive assessment should include:
- Unexpected changes to application settings.
- Unknown scripts appearing during checkout navigation.
- Unfamiliar domains contacted immediately after a checkout click.
- Unexpected additions to browser session storage.
- Recent changes to application access permissions.
- Customer reports of unusual payment pages.
A known session-storage marker may help support an investigation, but its absence cannot prove that a store is secure. Attackers can use different markers or remove traces.
Check 6: Confirm the findings with relevant vendors
If your store uses an application associated with a disclosed incident, contact its developer for store-specific information.
Ask whether your installation was included in the affected population, what exposure period was identified and what steps were taken to remove malicious content.
A general public statement that an application is now safe does not necessarily answer whether individual customers were exposed before the problem was fixed.
What to Do When an Active Fake Checkout Is Confirmed
A verified redirect to a payment-card collection page outside the authorized purchase flow should be handled as an urgent security incident.
Stop exposing shoppers to the fraudulent form
Disable the confirmed malicious application component or take other steps necessary to interrupt the redirect.
If the source cannot be isolated reliably, temporarily restricting the ability to place orders may be necessary to prevent additional customer exposure.
Any protective action should account for dependencies. Disabling a product-options or cart-related application can affect prices, selections and order processing.
The store should not resume normal checkout operations until the fraudulent behavior has been eliminated and the legitimate purchase journey has been verified.
Preserve evidence before it disappears
Record the discovered URLs, observed timestamps, affected pages, browser behavior and application configuration.
Preserve relevant screenshots and sanitized network records when available.
Third-party application data may change quickly when vendors deploy fixes, making timely evidence collection particularly valuable.
Keep any sensitive investigation material securely restricted to authorized personnel.
Escalate the issue to Shopify and the app provider
Provide sufficient technical information for support teams to identify the storefront and investigate the compromised integration.
Request information about the incident timeline, confirmed remediation, affected settings and any additional action required from the merchant.
When possible, obtain written confirmation of the developer’s assessment for the specific store.
Review access to administrative and integration accounts
Audit staff accounts, third-party application permissions and credentials associated with relevant vendors.
Revoke access that is no longer required.
Where credentials may have been exposed, rotate them from a trusted environment and enable multifactor authentication for administrative users.
Removing the visible redirect does not automatically establish that the mechanism used to introduce the code has been secured.
Determine which customers may have been exposed
The affected group may include customers who abandoned checkout, not only those who placed successful orders.
Equally, the fact that a shopper visited the storefront during an incident window does not prove that the malicious page loaded or that card information was submitted.
Assess exposure using all available evidence, including:
- The confirmed period of malicious code delivery.
- Which storefront pages executed the affected application.
- Whether the script redirected every visitor or only selected sessions.
- Information supplied by the application developer.
- Customer reports of unexpected checkout pages.
- Available browser and infrastructure records.
Do not describe every customer in the exposure period as a confirmed victim without supporting evidence.
Protecting Customers Whose Card Details May Have Been Captured
If a shopper entered payment card information on an unauthorized website, they should contact their card issuer or bank without delay using an official contact channel.
The bank can advise whether the card should be blocked and replaced, and what steps are necessary to protect against unauthorized transactions.
The customer should also review recent card activity and report unfamiliar payments.
If account passwords were entered on the fraudulent page, those passwords should be changed immediately, including on other services where the same credentials were reused.
Retailers should communicate relevant confirmed information clearly and avoid directing customers to unofficial verification forms that request card details again.
A genuine checkout payment completed afterwards does not make previously exposed card credentials safe.
Data Breach Reporting: GDPR and Payment Industry Responsibilities
Merchants must distinguish between a suspected redirect, a confirmed malicious checkout and evidence that personal or payment information was disclosed.
These findings influence the legal and contractual obligations that may apply.
Under the GDPR, organizations acting as data controllers must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal-data breach when the breach is likely to result in a risk to individuals’ rights and freedoms.
Where a breach is likely to create a high risk for affected individuals, direct notification to those individuals may also be required without undue delay.
These requirements depend on the circumstances of the incident, not merely on whether a third-party application experienced a technical fault.
Merchants may also have incident-reporting obligations under agreements with payment processors, acquiring banks and card networks.
A vendor’s statement that its own database was not compromised does not rule out a separate disclosure of information entered into a criminal website.
Evidence preservation, prompt investigation and documented risk assessment are therefore essential.
Shopify’s October 2026 Redirect Protection: What Changed?
On October 20, Shopify announced an additional safeguard against unexpected external redirects from online stores.
The initial implementation introduced a confirmation step when customers were about to leave the storefront for an external website.
Shopify revised the mechanism on October 23.
Under the updated behavior, known malicious destinations are blocked, suspicious destinations trigger a confirmation prompt, and other external links can open without additional interruption.
The change provides another opportunity to prevent shoppers from unknowingly reaching a phishing destination.
However, classification-based protections have limitations. Newly registered fraudulent domains or previously unseen attack infrastructure may not immediately be recognized.
For that reason, Shopify’s redirect protections should be regarded as a protective layer alongside application security reviews and payment-journey monitoring.
They are not a reason to stop auditing third-party JavaScript.
How to Reduce the Risk of Future Checkout Hijacking
Long-term protection requires visibility into every component that can influence a shopper’s movement from product selection to payment.
Maintain an approved application inventory
Document the applications installed in the store, their business purpose, access permissions and ability to inject or execute storefront code.
Remove integrations that are no longer required and periodically review those with broad functionality.
Application quantity alone is not a measure of security, but unnecessary integrations increase the number of components that must be governed and monitored.
Evaluate vendors’ configuration security
When selecting third-party applications, consider whether the developer implements robust authentication, restrictive permissions and appropriate validation for configurable HTML or JavaScript fields.
Applications should not allow untrusted configuration content to become executable storefront code without adequate safeguards.
Developers should also restrict internal administration tools and protect credentials used to access merchant installations.
Monitor externally supplied JavaScript
Because the October attack involved code delivered through configuration responses, monitoring should go beyond static theme-file changes.
Changes to external scripts, application API responses and browser navigation should be treated as relevant security signals.
For high-volume stores, continuous or frequent payment-journey checks can help identify unexpected destinations before they affect large numbers of customers.
Monitoring systems should preserve sufficient diagnostic information to distinguish authorized changes from suspicious behavior.
Keep the payment journey as simple as practical
Not every marketing or convenience feature needs to run on pages directly involved in purchasing.
Where application design permits, limit unnecessary scripts in the cart and other payment-related interfaces.
Restrict highly privileged integrations to the functions they actually require.
Review the security implications of features capable of modifying checkout buttons, cart drawers and navigation behavior.
Use suitable browser-side security controls
Content Security Policy can help restrict certain categories of unauthorized script execution and external connections where the platform allows appropriate configuration.
Script-integrity controls and change monitoring may provide additional protection in supported environments.
These measures require careful implementation. They cannot be assumed to cover every dynamically supplied script or every behavior occurring through an already trusted application.
They should therefore complement, rather than replace, secure application design and ongoing verification.
Align payment-page protection with PCI DSS
PCI DSS includes requirements addressing the authorization and management of payment-page scripts and the detection of unauthorized changes.
Requirements 6.4.3 and 11.6.1 are particularly relevant to the broader problem of browser-based payment fraud and e-skimming.
The precise applicability depends on the merchant’s payment architecture, the applicable validation approach and responsibilities shared with payment service providers.
The PCI Security Standards Council has published additional guidance on protecting e-commerce payment pages from unauthorized scripts.
Merchants should review these requirements with the organizations responsible for their payment security compliance.
Frequently Asked Questions About Shopify Checkout Hijacking
Was Shopify’s own payment system hacked?
There is no public evidence that the central Shopify checkout was breached in the documented October incidents. The confirmed attacks involved malicious code delivered through certain third-party applications before shoppers reached the genuine checkout.
Which Shopify applications were involved?
Hulk Product Options, Selleasy and Swym Wishlist Plus were associated with confirmed incidents during October 2026. Earlier incidents with a similar redirect mechanism affected two Qikify applications in July. These findings do not mean that every installation of the named applications was compromised.
Can a fraudulent checkout collect card information without processing a payment?
Yes. A counterfeit page can transmit submitted card details to a criminal server without authorizing a legitimate payment. The attacker may subsequently return the shopper to the genuine payment system.
How can a merchant detect a checkout redirect that happens only once?
Test the purchase journey in a fresh private browsing session and record navigation requests using browser developer tools. Repeat the process in another new session or on a separate device. A previously redirected session may behave normally.
Will Shopify report stolen card information in the order details?
Not necessarily. In these attacks, sensitive information could be submitted to an external phishing website outside Shopify’s payment processing environment. A later legitimate order may not contain evidence of that earlier disclosure.
Does an HTTPS padlock mean a payment page is genuine?
No. HTTPS indicates that the connection to the displayed website is encrypted. Criminal websites can also use valid TLS certificates. The website’s identity and its authorization to handle the payment must still be verified.
Should merchants uninstall every application mentioned in the incident reports?
Not automatically. The developers reported remediation actions, and installation alone is not evidence that a particular store was affected. Merchants should verify their exposure, review current vendor information and disable any component that is still causing unauthorized behavior.
Can checkout hijacking affect platforms other than Shopify?
Yes. The underlying technique of intercepting checkout navigation with malicious JavaScript is not exclusive to Shopify. Other e-commerce platforms may face comparable threats through compromised extensions, unauthorized code changes or infected third-party scripts.
Is Shopify’s new redirect protection sufficient on its own?
No. It can block known malicious destinations and warn about suspicious links, but no classification system can guarantee immediate detection of every new fraudulent domain. Monitoring and application security remain necessary.
What is the first action when a customer reports an unfamiliar payment page?
Preserve the report, investigate the checkout journey and immediately contain any confirmed malicious redirect. Notify Shopify and the relevant application provider. If the customer entered card information on the unauthorized page, advise them to contact their card issuer through an official channel.
Trustworthy Checkout Security Requires Control Over the Entire Customer Journey
The October 2026 Shopify incidents revealed a significant weakness in the way online retailers often assess payment security.
Protecting the payment processor and keeping the shopping cart application updated are essential, but neither measure is sufficient if unauthorized JavaScript can redirect a customer before they reach the protected checkout.
The malicious code involved in the documented attacks did not necessarily require changes to the retailer’s theme or access to Shopify’s payment infrastructure. It could arrive through application configuration, execute in an ordinary storefront session and direct shoppers to a carefully disguised external payment page.
Because customers could then return to genuine checkout, the resulting orders might provide little indication that anything unusual had happened.
Retailers should therefore verify the complete purchase journey, not merely whether transactions are successful.
Effective protection combines carefully managed third-party applications, strong access controls, monitoring of dynamically delivered scripts, testing in fresh browser sessions and a clear process for responding to suspected payment-data exposure.
The decisive security question is not only whether customers can complete a purchase. It is whether every step between clicking Checkout and submitting payment information takes place through a service the retailer has authorized and verified.
Sources
- Roman Zipp – Shopify Shops Hit With Ongoing Checkout Hijack Attack, October 2026
- Roman Zipp – Statements From Companies Involved in Shopify Checkout Hijack
- Logbase – Selleasy Security Incident Statement, October 2026
- Swym – Security Incident Update, October 16, 2026
- Shopify Changelog – New Protection Against Unexpected Redirects
- Shopify Help Center – Extend Your Theme With Apps
- PCI Security Standards Council – Payment Page Security and Preventing E-Skimming
- European Commission – Personal Data Breach Notification Obligations