Someone else's JavaScript on your checkout: what the 2026 skimming wave means for small stores

In January 2026, researchers announced they had unraveled a card-skimming operation that had been running quietly since 2022. By the time anyone noticed, the network had touched thousands of online stores and pulled cardholder data across six major payment networks. Not five years of near-misses. Not a single flagged transaction that tipped off the merchants involved. Four years of silence, ended only when a research team stumbled onto it while investigating something unrelated.

If you run a small or mid-size store on Shopify, WooCommerce, or BigCommerce, the unsettling part of that story isn't the scale. It's the duration. A skimmer that operates for four years without detection isn't the result of unlucky merchants missing a warning sign. It's built specifically so there is no warning sign to miss.

What Magecart looks like in 2026

The term Magecart originally described a loose collection of groups that injected card-stealing JavaScript into Magento checkout pages, back when Magento was the default choice for mid-size stores. The name stuck, and it now covers a broader category: client-side skimmers that run inside a browser during checkout and quietly copy form data to an attacker-controlled server before the payment even processes.

The 2026 version of this attack is harder to spot than its predecessors. Older skimmers sat directly on the payment form and were relatively easy to find with a script audit, because the payment field was the obvious target. Newer skimmers often start collecting on the product page or cart page instead, capturing name, address, and card details as a customer types them, well before the checkout step. Some inject through a compromised third-party script, such as a review widget, a chat plugin, or an analytics tag, rather than through the store's own codebase. The store owner never touched anything malicious. A vendor they trust did.

Why PCI DSS 4.0 now expects you to know your own scripts

The Payment Card Industry Data Security Standard has always covered how card data is stored and transmitted. PCI DSS 4.0 added something new: explicit rules about what runs in the customer's browser during checkout, because regulators caught up to the reality that skimming happens client-side, not just on the server.

Requirement 6.4.3 asks merchants to maintain an inventory of scripts that load on the payment page, with a documented reason each one is there and confirmation it's authorized. Requirement 11.6.1 goes further: it expects a mechanism that detects unauthorized changes to the payment page, including new scripts, and alerts a human within a defined window rather than surfacing the issue during a routine audit weeks later. These aren't abstract compliance checkboxes. They exist because the standards council watched years of exactly this kind of breach and concluded that after-the-fact log review wasn't catching it fast enough.

The blind spot for stores without a security team

Large retailers have security operations teams that review script inventories as a matter of routine. A store doing $50,000 or $500,000 a year on Shopify, WooCommerce, or BigCommerce almost certainly doesn't, and that's not a criticism, it's just the reality of running a lean operation.

Most small stores accumulate third-party scripts the same way: an app for reviews, a pixel for a new ad platform, a chat widget a former employee installed two years ago and nobody removed. Each one is a legitimate business decision at the time it's added. Collectively, they're an unmonitored surface that satisfies exactly the gap 6.4.3 is meant to close, except most small merchants have never inventoried it, let alone re-checked it since. A platform update, an app update, or a compromised app developer's account can change that surface without the store owner touching anything. It's a version of the same fragility covered in why Shopify stores lose orders during theme updates: the store owner didn't make the change that broke something, but they're the one who has to explain it.

Why nothing looking different is exactly the point

Here's the part that trips people up: a skimmed checkout usually works perfectly. The order confirms. The customer gets their email receipt. Revenue shows up in the dashboard looking normal. There's no error message, no slow page, no broken button, because the skimmer's entire job is to copy data quietly while the legitimate transaction completes without a hitch.

That's a very different failure mode from the ones most store owners are already watching for. A stock-out shows up as a sales drop. A pricing error shows up as a margin problem. Downtime shows up as, well, downtime. A skimmer shows up as nothing at all, until a bank notices a pattern of fraud across cards that all made a purchase at your store, or until a researcher publishes a report months or years later with your domain in the list.

What checkout script monitoring actually catches

The practical answer to an invisible problem is a system that establishes what "normal" looks like and flags deviations, which is the same logic behind Cassian monitoring a store's uptime, pricing, or stock levels. Checkout script monitoring works the same way: it takes a baseline of the scripts loading on your product, cart, and payment pages, then watches for anything new, changed, or unauthorized, and alerts a person rather than waiting for a monthly report.

This maps directly onto the intent of PCI DSS 11.6.1, which expects change detection with a human notified in a defined timeframe, not just a log entry nobody reads. Cassian™'s security scanning (Cassian Shield™) and broader Cassian Score™ health summary are built around that same principle: continuous checks that catch unauthorized changes to a store's payment surface, so an owner without a security team still gets a signal when something shifts. It won't catch everything, no monitoring tool does, but a script that changes without anyone on your team touching it is exactly the kind of event worth an alert. It's the same reasoning behind watching for unusual order patterns, as covered in card-testing attacks: why small stores get hit and how to spot one early, or noticing when scripts your store depended on simply stop running, as happened in the Shopify Scripts deprecation of June 2026. The common thread is the same: silent change is the risk, and detection has to be continuous, not periodic.

Where this leaves you

None of this means small stores are defenseless, or that every store owner needs to become a security engineer. It means the checkout page deserves the same continuous attention as uptime, stock, or pricing, because a skimmer's success depends entirely on nobody looking until it's too late. Knowing what scripts run on your payment page, and getting a plain alert the moment that list changes without your say-so, closes most of the gap between a four-year breach and a same-week catch.