Why we're updating our Swym alert
When we published our Swym Wishlist Plus alert last week, this looked like one app with a problem. As of October 22 it is at least nine Shopify apps, two of them reaching back to July and August, plus critical security releases for PHP and Node.js landing in the same seven days.
The short version: the checkout hijack was never a theme problem or a Shopify-core problem. In every confirmed case the malicious script came from an app developer's own backend, delivered through a settings field the app already loads on your storefront. That is why our original advice still holds, and why we have added a few things to it.
This post reacts to each app on Roman Zipp's running list, covers the PHP and Node releases, and explains what we have done on our side. Links to original sources are at the end so you can form your own view.
How the checkout hijack works, in plain English
Nothing in your theme was changed. The attack lived in the app vendor's settings, and the app's normal storefront script pulled it in.
Many apps let a merchant add "custom JS" or custom HTML labels in the app's own admin. The app saves that text on the vendor's servers.
On every page load, the app's storefront script calls the vendor's API and runs whatever custom code comes back.
Attackers got into those vendor settings (a compromised internal tool at Selleasy, an "access channel" at Swym, an unexplained "exploit" at HulkApps) and dropped in a ~22 KB script.
The script watches for the Checkout click, then sends the shopper to a look-alike page on a
.topdomain that collects card and billing details, then forwards them to the real checkout. It fires once per browser session, so the store owner often never sees it.
Because the payload came from the vendor's API, a theme file scan would show nothing. That is also why Shopify's fix is on the storefront side: as of October 20, online stores ask customers to confirm before leaving for an outside website. It does not name the apps, but it breaks the silent redirect.
App by app: where things stand and what we recommend
Status is as of October 22 and follows Roman Zipp's list plus what we have heard directly. "De-listed" means Shopify pulled the App Store listing; it does not by itself prove the app was compromised, and it does not remove the app from stores that already have it installed.
| App | Status (Oct 22) | What we know | Our take for clients |
|---|---|---|---|
| HulkApps / Hulk Product Options | Fixed; extension restored by Shopify; listing was pulled | Oct 10. Unauthorized "custom JS" config in the Product Options theme extension redirected checkouts. HulkApps calls it "an exploit," has hired an outside firm, and says only this one app was involved. | The first and best-documented case. If you run it, confirm the extension is re-enabled and the custom JS field is empty or yours. We are fine keeping it installed once that is verified. |
| Selleasy (Logbase) | Fixed same day; forensic audit pending | Oct 13, 07:47–15:00 UTC. An attacker got into an internal Selleasy tool and wrote a script into the Custom JS setting on a number of stores. Selleasy locked that setting so no tool or API can change it now. | The most transparent vendor so far, with a public incident page. Low concern going forward. |
| Swym Wishlist Plus | De-listed; app was disabled for security work and is now coming back online in phases | Oct 14, 10:06–16:32 UTC. An unauthorized config change made a script load on a subset of storefronts. Swym rotated credentials, added sanitization, and emailed affected merchants in two waves. | This is the app our original post covered. Swym temporarily disabled the app to add security measures and, per its October 22 merchant email, is restoring features in a phased rollout with possible brief interruptions; they will notify merchants when full service is back and no merchant action is needed. We are holding our clients until that all-clear and the listing returns. If you used it on Oct 14, consider telling shoppers who typed a card number that day. |
| Boost AI Search & Filter | De-listed; incident posted on Boost's status page | Reported by merchants around Oct 17; Boost opened a status incident. Details from Boost are thin so far. | Same mechanism as the others as far as we can tell. We are checking any client with Boost installed and waiting on a fuller statement. |
| Privy – Email, SMS & Pop Ups | De-listed; unconfirmed | One merchant reported the redirect on Oct 17 across all of their sites and traced it to Privy. No public statement from Privy yet. | Treat as likely but unconfirmed. If you run Privy, do the incognito checkout test today and keep the app disabled until Privy says something. |
| Consentmo GDPR Compliance | De-listed (self-reported); fixed same morning; working toward relisting | Oct 19, roughly 08:00–09:18 UTC. A large-scale automated attack abused a Consentmo endpoint (~1,300 requests/min, rotating IPs) to alter cookie banners across tens of thousands of stores with a script that read the cart and redirected checkout clicks. Only visitors who had not yet made a consent choice saw it. Consentmo shut it down in 90 minutes, restored every banner, reported itself to Shopify, and has had a CREST-accredited firm complete a review and pen test. Per their merchant email, 63% of stores had zero impressions on the altered banner and 88% had ten or fewer. | A different entry point than the custom-JS cases, same payload. Consentmo's handling has been the model for the group: fast shutdown, per-store impact numbers emailed to merchants, and a voluntary report to Shopify. Safe to keep installed; if you got their email, check the impression and cart counts for your store. |
| 17TRACK | De-listed; unconfirmed | Two merchants reported the attack on Oct 20–21 via a new domain, cartassure[.]top. 17TRACK and Shopify are investigating; nothing public yet. | Newest entry on the list and the one to watch. The new domain means the campaign is still moving. |
| Hextom | Resolved (August) | An earlier, separate incident, resolved before this wave. | No action. |
| Qikify | Resolved (July) | Malicious code was injected into two HTML content fields; Qikify believes a leaked credential was the cause and audited every app with an outside firm. | No action. Their write-up on credential leakage via over-permissioned AI tools is worth reading. |
The pattern across all nine: a vendor-side settings field that the storefront script trusts without question. The fix on the vendor side is the same every time: lock the field, sanitize what it loads, and alert on changes.
Same week: critical PHP and Node.js releases
A cluster of unrelated patches landed on October 21 while the Shopify story was unfolding: PHP, Node.js, Go, and a compromised intermediate certificate authority (eMudhra) that Node and others pulled from their trust stores. Neither touches Shopify-hosted stores, but both touch the servers behind many brand sites, headless builds, and custom apps.
PHP ("PHP2Shell")
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical bugs, CVE-2026-109618 and CVE-2026-109619, rated 9.2 and allowing unauthenticated remote code execution. Details leaked a day before the patch, and watchTowr reports exploitation attempts in the wild.
PHP's own note: there is no complete mitigation; updating is the only safe choice. Versions as far back as PHP 5 are reported affected, and PHP 5 and 7 will not get a patch.
This is a PHP-core bug, so it hits WordPress, Magento, Laravel, and any custom PHP site equally. Application-level logins do not help; PHP processes the request before your code runs.
If your site is on WP Engine, you are covered. They moved fast and had hosts patched quickly, which is why we host all of our PHP clients there. If you are on a VPS or another host, check your PHP version today.
Node.js
Node.js 26.12.1, 24.22.1 and 22.23.4 fix ten vulnerabilities, four rated high: an out-of-bounds write in the Brotli decoder that permits remote code execution (CVE-2026-111497), a
dns.resolvename-truncation bug, and two TLS hostname-check bypasses. The release also pulls in updated c-ares, Undici, OpenSSL and CA certificates.No in-the-wild exploitation reported as of October 22, but Node says end-of-life lines are always considered affected.
This matters for anyone running a Hydrogen or other headless storefront, a custom Shopify app on Node, or a Node-based middleware. Update the runtime, not just your packages.
How a good vendor responded. Rebuy emailed every merchant on October 21 to say what they did the same day: Cloudflare emergency firewall rules, the PHP feature the exploit targets (session upload progress) disabled, both PHP bugs patched within hours, the compromised certificate authority removed, Node.js and Go upgraded to patched builds, logs reviewed with no sign of exploitation, and multi-factor authentication switched on for all customer accounts. No merchant action needed. That is the standard to hold every app in your stack to this week: did they tell you what they run, and did they tell you when it was patched?
The common thread with the Shopify incidents is not the technology. It is that a dependency you do not write can become the way in, and the only defense is knowing what you run and patching it the day the fix ships.
What Text Connects has done
Our own apps. We are validating every Shopify app we have written, and so far we have found no issues. More importantly, none of our current apps has the kind of access that made this attack possible:
We do not deliver frontend code or JavaScript from any current app. There is no "custom JS" field on our side for anyone to poison.
We do not have any current app that writes to themes. Your theme is yours; our apps read data and act in the Admin, not in your storefront.
That is a design choice, not luck. An app that cannot inject into your storefront cannot be turned into a redirect, no matter whose credentials leak.
Runtime patches. We are updating every app we manage to the patched Node.js releases. For PHP, every site we manage is hosted on WP Engine, which patched its hosts quickly after the October 21 release, so none of our PHP clients needed a manual update.
A scanner for client stores. Because the payload lived in vendor APIs rather than theme files, a theme scan would not have caught any of this. So we built a scanner that runs against client stores and does what a shopper does: opens a clean browser, adds an item, clicks Checkout, and confirms it lands on the real Shopify checkout. It also watches every third-party response for the known indicators, keeps a baseline of which outside hosts your store talks to, and alerts us when a new one appears. We are running it across the stores we manage, several times a day.
What you can do today
Run the incognito test yourself: new private window, add to cart, click Checkout, confirm the URL is
checkout.shopify.comor your own domain. Do it once a day while this is active.Check your installed apps against the table above. Anything de-listed and unexplained: disable the app embed until the vendor speaks.
Turn on two-factor authentication on Shopify and on every app vendor account that offers it. Several of these incidents trace back to a stolen credential.
Audit which AI tools, agents and custom apps have tokens for your store, and cut any that do not need them.
If you host a PHP or Node site anywhere, confirm it is on a patched version this week.
If you want us to add your store to the scanner, or to walk through your app list with you, reply to this post or reach out through your usual contact.
Read the originals
Shopify shops hit with ongoing Checkout Hijack attack — Roman Zipp's original investigation and running app list (updated Oct 22)
Statements from companies involved — HulkApps, Selleasy, Swym and Qikify in their own words
Shopify changelog: new protection against unexpected redirects — the Oct 20 storefront change
Qikify security incident notice — the July incident and their notes on credential leakage
Our original Swym alert — Text Connects, Oct 16