A customer adds a product to a Shopify store, opens the cart and clicks the familiar checkout button. The next page looks plausible. It may even contain the right products, quantities and prices. But the browser has left the legitimate purchasing journey and reached a phishing page.
That is the central risk in the Shopify app checkout hijacks reported in October 2026. Public reporting and developer statements describe malicious storefront behavior delivered through third-party app configuration. The important question for a merchant is whether an app can influence the path a customer takes to checkout, and whether the store's actual journey has been checked.
This article explains the reporting, the behavior of two code samples we reviewed, our earlier experience with an injected HTML translation field, and the separate PHP security announcement published on October 20. It also sets out a practical response and the app inventory we recommend building before the next incident.
Research checked on October 21, 2026, at 10:35 UTC. The PHP notice was still an advance announcement at that time. We distinguish observed behavior, developer statements, our own experience and unresolved questions throughout. Delisting alone does not establish compromise, and the available reporting does not establish that Shopify's hosted core was breached.
If you want help identifying the apps on your store's critical paths, book a Shopify app security advisory with shoplab. We can review the installed-app landscape, prioritize evidence gathering and plan changes around your store's dependencies.
Book an app security advisoryWhat happened in the Shopify checkout attacks?
In his October 10 investigation of the checkout hijack, Roman Zipp describes encountering a suspicious checkout journey while shopping. He traced the behavior through the Hulk Product Options storefront extension to configuration returned by a HulkApps API. That configuration contained custom JavaScript that diverted the checkout action.
The distinction matters. A storefront can load an extension from a familiar CDN and still receive behavior from another system afterward. A review limited to the theme's files or the hostname of the initial script would not necessarily reveal the injected configuration.
Zipp also reports testing the external checkout with fabricated details and observing information being sent to an external endpoint before the browser returned to the legitimate checkout. That is his reported live observation. We reviewed the supplied samples as text; we did not execute them, visit their destinations or repeat that payment-form experiment.
The public timeline contains several different events:
| Date in 2026 | What the source supports | How to interpret it |
|---|---|---|
| July | Our team encountered an injected payload in an app translation field that accepted HTML. | This is shoplab's first-hand account, discussed below. It does not establish a connection to the October events. |
| July–August | Qikify's statement describes malicious content in customizable HTML fields in July and says the issue was fully resolved by August. | The statement explicitly separates this earlier incident from the October wave. |
| October 10 | Zipp published his traced observation involving Hulk Product Options. HulkApps subsequently described unauthorized configuration and external checkout redirects. | This supports a specific app-delivered incident, not a claim about every HulkApps product or installation. |
| October 13 | Logbase described unauthorized access to an internal tool and modified settings affecting a number of Selleasy stores, between 07:47 and 15:00 UTC. | The vendor said the injected scripts had been removed by 15:00 UTC. Its account is a dated statement about that incident. |
| October 14 | Swym described unauthorized configuration changes affecting a limited subset of storefront pages; it reported mitigation fully deployed at 16:32 UTC. | This does not establish that every Swym installation or every customer session was affected. |
| October 20 | The PHP security team announced an upcoming release addressing two critical vulnerabilities. | This is a separate backend security alert. No cited source connects it to the checkout hijacks. |
The developer accounts above are collected in Zipp's compilation of company statements. They provide useful incident windows and containment claims, but merchants still need to establish what happened in their own stores. The reporting does not provide a verified total of affected shops, stolen records or a single common entry point across all incidents.
Which apps are confirmed, and which claims remain unconfirmed?
Hulk Product Options, Selleasy and Swym Wishlist Plus are supported by specific incident reporting and developer accounts describing unauthorized configuration or injected code. The scope of each statement matters as much as the app name.
HulkApps described unauthorized configuration affecting its Product Options theme extension. Its statement said it found no evidence that other Hulk apps delivered the redirects. Logbase described an unauthorized party modifying settings through an internal tool; it reported no evidence at that stage of a Selleasy backend or database breach, while investigation continued. Swym reported no evidence of merchant-account access or access to data stored by Swym.
Those statements should be read precisely. A developer finding no evidence of access to its database does not establish that a shopper who entered details into an external phishing page suffered no exposure. The app backend, merchant account, browser and external destination are different places where evidence can exist.
Other apps have been named in public discussions or appeared in delisting lists without equivalent confirmation. In its October 20 overview, Revenue Shield distinguishes vendor-confirmed cases from unconfirmed reports. It identifies Privy and Boost AI Search & Filter as named in reports without a confirmed phishing cause in the vendor information it discusses. We do not classify either as a confirmed checkout compromise on that basis.
For a merchant, the useful record is therefore more specific than a list of “bad apps”: which product, what evidence, which incident window, what capability was affected, what the developer has confirmed, and which questions remain unanswered.
How the first checkout interception sample works
The first sample shows how malicious storefront code can take control of the transition from cart to checkout. Understanding the sequence helps defenders choose a useful test without reproducing the payload.
It waits for an ordinary checkout action
The code registers listeners for several kinds of interaction, including pointer, touch, click and form-submission events. It looks for recognizable checkout controls. This is broader than replacing one visible link: the listener can sit higher in the page's event structure and intercept an action that appears to belong to a normal theme button.
On a qualifying interaction, it interrupts the intended action and prevents other handlers from completing it. A checkout button can therefore look unchanged while the browser takes a different route after the click. Inspecting the button's visible label or destination alone is not a complete test.
It carries the real basket into the handoff
The sample reads the current storefront cart and prepares information about products, variants, quantities, images, currency, totals and discounts. It attempts to obtain a stable cart snapshot before handing the browser off, with a fallback if the detailed preparation fails.
This gives the external page context that can make it feel connected to the genuine purchase. A phishing checkout showing the correct basket is more convincing than an unrelated form. The cart information is useful camouflage even though it is not, by itself, a payment credential.
The sample also keeps a route back to the genuine checkout. This helps explain why an apparently successful purchase afterward would not necessarily disprove an earlier diversion. The suspicious page can be an extra stop in the journey rather than its final destination.
Its session behavior can mislead a quick retest
The code records a transaction identifier and a handoff flag in browser session storage. After a handoff, a later checkout attempt in the same session can be allowed to continue normally. A merchant who clicks twice may therefore see a suspicious result followed by a healthy-looking result.
That makes a fresh browser context important when reproducing this particular behavior. It does not mean every sample behaves identically, or that a private window guarantees detection. The test needs to record the sequence and session conditions, not just the final page.
The storefront sample and the phishing page are separate
Our static review establishes interception, basket-context preparation and navigation to an external destination. It does not show the implementation of the external page's payment capture. The claim about information being collected there comes from Zipp's separate reported observation.
We are deliberately not publishing executable code, encoded bodies or attacker destinations. A merchant can understand the failure and investigate the relevant surfaces without distributing a working checkout-diversion script.
Our July finding: when a translation field becomes executable
In July 2026, our team encountered an injected payload in an app translation field that accepted HTML. A setting presented as customer-facing copy had become a route into browser execution.
HTML support is not inherently a vulnerability. Merchants may need formatting, links or other controlled markup. The security boundary is whether the app treats the field as restricted content and sanitizes it accordingly, or lets executable markup and event handlers reach the storefront.
The second illustrative sample reviewed for this article uses that latter kind of boundary. It contains an HTML wrapper that triggers encoded browser code, then removes its triggering element. Encoding makes the behavior harder to notice during a casual review of a translation value; it does not encrypt the code or make it safe.
The example was published on October 21. Its publication date and internal date markers do not independently establish when a merchant was affected. Our July chronology comes from our team's account, and the published example is not being presented as an original, timestamped forensic artifact from that incident.
An invisible layer can sit above the real button
The decoded sample combines several mechanisms. It locates a sticky-cart checkout control and positions a transparent interactive layer over it. Visually, the shopper sees the legitimate button; the interaction can land on the inserted layer instead.
The code also responds to page changes, drawer activity, scrolling and resizing so that the layer remains aligned as the cart interface moves. This is why checking only the original HTML, or testing before a cart drawer has fully opened, can miss relevant behavior. Modern storefronts change after the first document loads.
Alongside the overlay, the sample intercepts checkout-related clicks and form submissions. It reads and normalizes basket context, retains the intended checkout return destination, suppresses duplicate handling and prepares the off-site handoff. These overlapping behaviors make it more adaptable than a single changed hyperlink, without proving a particular success rate or common attacker.
Server logs may show only part of the transfer
The sample attempts to carry context through browser state and the fragment portion of a navigation URL. A URL fragment is ordinarily not sent in the HTTP request, but code on the destination page can read it. Consequently, a server access log may not contain all the context available to the browser at the destination.
Browser privacy protections can also affect cross-origin browser-state behavior. Static analysis tells us what the code attempts; it is not proof that each transport works uniformly in every browser.
Most importantly, finding malicious content in a translation field identifies where it was delivered. It does not reveal how an attacker obtained permission to change that field. We cannot infer an authentication vulnerability, a stolen credential or a connection to October's incidents from a field value or a suggestive variable name.
What a delisted Shopify app actually tells you
HeyApps' delisted-app archive is useful for tracking marketplace availability and retaining listing history. It also distinguishes recovered entries. We recommend using it as a source to cross-check the apps a store has installed.
It is not a list of proven victims or malicious developers. Its archive spans removals for different reasons and periods. Revenue Shield's October 20 article described 135 removals since October 14; that is a dated count for a defined period, not a verified count of apps involved in the attack. Neither that figure nor the larger HeyApps archive should become a headline claiming that the same number of apps were hacked.
Delisting and remediation also answer different questions. An app becoming unavailable for new installs does not demonstrate that its existing installation, app embed, configuration, credentials or residual theme code has been removed from a merchant's store. Conversely, an app's reappearance in the marketplace does not verify the historical exposure of a particular store.
For every relevant entry, record the date observed, current listing status, developer statement and actual installed state. Ask why the app was removed and whether the developer identifies an affected period or required merchant action. Avoid treating a missing listing as a reason to accuse a vendor, or a restored listing as a substitute for checking your own checkout.
The October PHP alert: a separate issue to investigate
On October 20, the PHP security team published an advance notice of an upcoming critical security release. It announced fixes for two vulnerabilities, each rated CVSS v4.0 9.2, scheduled for October 21 at 14:00 UTC.
At our October 21, 10:35 UTC check, the notice had not yet published CVE identifiers, technical details, affected-version ranges or fixed-version numbers. It promised those details with the release. Its statement that publication could be accelerated if exploitation evidence appeared was conditional; it was not an announcement of confirmed active exploitation.
This is relevant to Shopify app providers operating PHP backends. Their infrastructure is separate from Shopify's hosted platform. A merchant can use Shopify while relying on external app services built with PHP or other technologies, and the developer is responsible for maintaining those services.
The announcement does not establish that a named Shopify app is vulnerable, that older apps are necessarily built with PHP, or that the PHP issues caused the checkout incidents above. Applicability depends on the eventual advisory and the provider's actual runtime and configuration. A public storefront fingerprint rarely establishes those backend facts.
Merchants should ask relevant providers four concrete questions:
- Does the app use PHP in a component relevant to our store, and is its deployed configuration affected by the published advisory?
- Which supported fix or mitigation applies, and when will it be deployed?
- How will completion be verified, including any persistent configuration or credential issues if compromise is suspected?
- Who will provide a dated update if the assessment changes?
The official PHP support lifecycle is a separate maintenance check. An unsupported branch is a concern even without evidence that these particular vulnerabilities apply. A normal storefront checkout test cannot prove that an app vendor has patched its backend.
What merchants should do now
1. Establish the store's current behavior
Use a fresh browser session and follow a realistic route: open a product, select any required variant, add it to the cart, open the actual cart interface and click its checkout control. Record the time, device, product, locale and path tested, plus the top-level destinations the browser visits.
Do not jump straight to the known checkout address. That bypasses the storefront interaction these samples intercept. Include the cart drawer and any app-provided sticky-cart control that customers use. If the destination looks suspicious, stop before entering personal or payment details.
An unfamiliar domain deserves investigation, but it is not automatic proof of phishing. Legitimate merchant domains, Shopify checkout, Shop Pay and approved payment providers can all appear in a purchase journey. Compare the observed destinations with the merchant's expected flow, including regional and payment-method differences.
2. Preserve evidence before cleanup
Capture relevant timestamps, screenshots, app and theme configuration, suspicious destinations and available logs. Keep sensitive evidence in a restricted incident record, not in a public support thread. Avoid copying or opening suspicious payloads in an ordinary browsing session.
If diversion is observed, involve Shopify and the relevant developer promptly, follow current containment instructions and disable the implicated execution surface where operationally safe. Preserve enough evidence to understand the affected window. Removing an unrelated collection of apps can break the store and make the investigation harder.
3. Look beyond the theme download
Review theme app embeds and leftover code, external scripts, custom-JavaScript settings, translations, rich-text or HTML fields, and configuration returned by app services. Review custom app access and relevant webhooks where the evidence points there.
The October reporting demonstrates why a clean theme archive is not a complete answer: an app can supply behavior after the page loads. Likewise, deleting one visible payload may leave the account or configuration service that supplied it accessible to an attacker.
4. Ask for evidence of scope and containment
Request the developer's incident window, affected-store determination, impacted capabilities, containment steps and outstanding root-cause questions. Establish which statements concern its own database and which concern shopper interaction with an external page.
Review administrative access and credentials with the relevant owners. A password change alone does not remove persisted content, invalidate every token or establish that the source of unauthorized changes is closed. Revocation and rotation should be based on the access involved, with attention to the integrations they may interrupt.
5. Address customer impact and verify recovery
If shoppers may have submitted details to an external page, involve the appropriate security, payment and privacy advisers. Notification duties depend on the facts and applicable jurisdiction; a generic internet checklist cannot decide them for every merchant.
After remediation, repeat the affected journey in fresh sessions and across the relevant interfaces. Record what changed and what was rechecked. Keep the incident open where scope, persistence or backend remediation remains unresolved, even if one current checkout test looks normal.
Book an app security advisoryBuild an app inventory around critical business paths
An installed-app list becomes useful when it explains what each app can do and what depends on it. A list of logos or monthly subscription costs cannot answer whether an app can influence checkout, access customer records or interrupt fulfillment when removed.
At shoplab, our starting point is the installed-app catalog and its relationship to the store's workflows. This builds on app-inventory work we have done for Maniko and Pergolux. Those references describe our assessment approach, not involvement in the incidents discussed here.
For each app and custom integration, the register should cover:
| Area | What we record | Why it changes the decision |
|---|---|---|
| Purpose and ownership | Business function, developer, internal owner and current usage | Establishes who can explain the dependency and approve changes. |
| Access | Granted API scopes, relevant data categories and write capabilities | Shows the potential consequences of unauthorized access. |
| Storefront execution | App embeds, scripts, configuration calls and editable content fields | Identifies where an app can change what shoppers see or click. |
| Critical paths | Product selection, cart, checkout transition, customer accounts, orders and fulfillment | Prioritizes impact on customers and revenue. |
| Provider evidence | Incident notices, response dates, maintenance information and relevant patch confirmations | Separates verified facts from unanswered questions. |
| Removal consequences | Theme remnants, data export, workflows, replacement needs and rollback plan | Makes containment and planned removal safer. |
A risk assessment should consider capability, exposure, business impact and strength of evidence together. A storefront app with broad configuration access and an unresolved incident needs a different response from an unused app with a narrow permission set. An unknown backend patch status is a question to resolve, not a confirmed vulnerability to invent.
Public scans are only one input. An admin-only or server-side app may leave no visible browser footprint. Conversely, a detected analytics domain, payment service or shared library does not automatically correspond to an installed Shopify app. We reconcile browser observations with the merchant's actual installed apps, permissions, custom integrations and provider responses.
The deliverable should be an actionable register: what is known, what is uncertain, which items need immediate attention, who owns the next action and how completion will be verified. Start with our free Shopify checkout check for one observed journey, then use those findings alongside the app inventory and ongoing store-management process.
What a quick desktop checkout check can and cannot prove
Run our free desktop checkout check to observe one storefront journey and get a report with visible app and service indicators.
A small browser-based check is useful as an initial observation. It can visit a product, interact with the cart, click the real checkout button, record redirects and show the result with screenshots. A report can include the journey taken, expected versus observed destinations, visible app or service indicators, and any step that could not be completed.
The report needs an honest outcome vocabulary. “Expected checkout reached in this run” is supportable. “Your store is secure” is not. An unexpected destination needs review; a bot challenge, unavailable product or unsupported cart interaction should produce an inconclusive result, not a green success badge.
One desktop run does not cover every device, locale, region, customer state, delayed trigger or payment method. Session-dependent behavior is especially important here. A test that reaches the correct final checkout could still have passed through an earlier unexpected page, so the full navigation sequence matters.
It also cannot establish which apps are installed only on the backend, whether a provider's infrastructure is patched, or whether historical shoppers were exposed. The appropriate next step after a limited check is to investigate its findings and fill those gaps through an app assessment. The browser should stop before entering real customer or payment information or placing an order.
Reducing the same risk after the incident
Treat app review as part of store operations. Keep a named owner for each integration, remove unnecessary access through a planned process, and revisit critical-path apps when their permissions, ownership or configuration change. Follow developer security notices and maintain an incident contact route before it is urgently needed.
If your team develops an app, distinguish content from executable behavior. Restrict who can change sensitive configuration, validate and sanitize supported markup, protect administrative tools, keep an audit trail and maintain the backend runtime. A flexible translation or custom-content feature still needs a clearly enforced trust boundary.
For bespoke functionality, Shopify app development should include those maintenance and operational responsibilities in the scope. A feature is not finished simply because its happy path renders correctly.
Frequently asked questions
Was Shopify itself hacked?
The sources discussed here describe checkout diversion delivered through third-party app configuration and storefront behavior. They do not establish a breach of Shopify's hosted core. That distinction does not reduce the seriousness of a customer being sent to an external phishing page; it helps identify the systems and providers that need investigation.
Does a delisted app mean my store was compromised?
No. Delisting is a marketplace status and can have different causes. Check whether the app is installed, what the developer has confirmed, whether your store falls within a stated incident window and what your own evidence shows. Do not turn an archive entry into a finding of compromise without supporting evidence.
Is uninstalling the app enough?
It may remove an important part of the exposure, but it does not by itself establish complete cleanup or historical scope. Relevant theme remnants, persisted configuration, credentials and other affected systems may still require investigation. Follow current developer and Shopify guidance and verify the actual storefront behavior after changes.
Can a store pass a check and still have a problem?
Yes. A test observes a particular session and journey. The first sample reviewed here can allow later checkout attempts through after a handoff in the same session. Different devices, cart controls, regions or backend-only issues may also lie outside a single test. A clean result should state exactly what was checked.
Which Shopify apps are affected by the PHP announcement?
The October 20 advance notice does not identify Shopify apps or publish affected-version ranges. Applicability must be checked against the full PHP advisory and each provider's deployed configuration when those details are available. PHP use or app age alone is not evidence of vulnerability or compromise.
Can shoplab identify every installed app from a public scan?
No. Browser-visible scripts and requests provide a partial set of indicators. A comprehensive register requires authorized access to the merchant's installed-app information, permissions and relevant custom integrations, plus developer answers where infrastructure details are not publicly visible. We distinguish confirmed installations from inferred service fingerprints.
What do I get from an app security assessment?
The assessment turns the app landscape into a prioritized action plan: installed apps and owners, permissions and data access, storefront execution, critical-path dependencies, relevant incident and patch evidence, open questions, and recommended next steps. It provides a basis for decisions and follow-up verification; it does not certify that a store can never be compromised.
Book a Shopify app security advisory
If you are unsure which apps can influence checkout, whether a delisting is relevant to your store, or which providers need to answer the PHP advisory, start with a focused conversation.
We will use your store's app landscape and business dependencies to define the right assessment. From there, we can agree the inventory, access review, observed checkout checks and provider follow-up needed to produce a useful risk assessment. You leave with priorities and accountable next steps instead of a generic list of apps to delete.
Have your installed-app list, any developer incident notices and the approximate time of suspicious behavior ready if available. Do not send payment details, passwords or executable payloads through a booking form.
Book an app security advisorySources and research boundaries
- HeyApps' delisted Shopify app archive: listing-status history, reviewed October 21; not a list of proven compromises.
- PHP's October 20 notice of an upcoming critical security release: two announced vulnerabilities and the scheduled release, checked before publication of technical details.
- PHP's supported-version lifecycle: maintenance status, separate from the affected-version scope of a particular advisory.
- shoplab's code sample on GitHub Gist: reference for the static explanation of the HTML translation-field injection. The code is not embedded or executed here; its October 21 upload does not independently establish the date of our reported July discovery.
Our technical explanation is based on static review of the two supplied samples. We did not execute them or test their external destinations. The July translation-field discovery is shoplab's own account. We do not claim a common attacker, a verified total of affected merchants or an independently established root cause for every incident.
