The Skimmer Was the Decoy: What 600,000 Stolen Cards Say About Where Payment Security Breaks

Between September 10 and September 15 2026, one operator launched 105 attack projects against online businesses.

According to Gambit Security's research, at least 27 companies were compromised, including a Fortune 500 hospitality company, a major US airline, a large industrial supplies distributor and an online fashion retailer. The average cost per target was US$25.46.

Most of the coverage will focus on the AI.

The attacker had open-source agent tools driving commercial and open weight models, and the agents probed, exploited and adapted on their own, with the human typing only a few prompts per target.

That part is new and it matters.

But look past the AI and one fact matters more for anyone who owns a payment environment.

The 600,000 cards did not come from skimmers. They came from databases.

Two Campaigns in One

Gambit's report describes two ways the attacker made money.

The first is the one the payments industry has spent years on: skimming. Scripts that steal cards on the checkout page were ordered against at least 27 victims and confirmed in place on 19, and more than 100 other websites showed related skimmers.

This is classic Magecart, run by software.

The second is older and much bigger. The attacker exfiltrated more than 600,000 card records from just two companies, taken straight out of their databases. Roughly 488,000 of those cards (79 percent) were issued in the US. The rest came from more than 200 other countries and territories.

If your payment security plan is mostly about the checkout page, it covered the smaller of the two attacks.

The Keys Were in the Building

The route to those databases is worth reading slowly. Gambit published one attack chain in full.

In short:

Unauthenticated SQL injection → read a plaintext one time passcode to bypass MFA → admin access → arbitrary file upload → remote code execution → root through a misconfigured sudo rule → pivot across an NFS mount → dump 46 secrets from AWS Secrets Manager → main Magento database → Magento encryption key → stored card numbers decrypted.

The last two steps are the ones that matter. The agents pulled the Magento encryption key and used it to decrypt the stored card field.

That is the detail every CISO should take away. That database was encrypted, and the encryption made no difference, because the key lived in the same environment the attacker had already taken over.

The attacker also left instructions for tidying up. The playbook included a skill called "Database Wipe After Extraction." It told the agents to erase card fields after taking them, using chunked PHP scripts over serialized fields, sized for "millions of rows."

Whoever wrote that expected big databases full of real card numbers.

Eight Ways Into a Checkout Page

Now the skimmers.

Gambit found eight separate ways of planting them. The list is worth reading because it shows why watching the checkout page is harder than the product demos suggest.

1. Adding a loader to a trusted library. The loader was appended to the site's own jQuery or Bootstrap files, and the file timestamps were set back to hide the change.
2. Script tags from outside domains on checkout pages, using lookalike names such as cdn[.]netlfjs[.]com.
3. Google Tag Manager. Code was slipped between legitimate gtag calls and pushed out of sight with about 100 tab characters.
4. The victim's own storage. Stolen AWS credentials let the attacker write to the bucket behind the victim's CDN, so the skimmer came from the victim's own infrastructure.
5. Database content. A loader was added to product descriptions through an admin pod, then moved into files on the victim's own domain.
6. Kubernetes. The skimmer was written into the initContainer settings of the live storefront deployment.
7. The server cache. Code went straight into the cached checkout page.
8. A job that replanted itself. A cron job in a JBoss log folder checked file sizes every two minutes and put the skimmer back whenever a clean version went live.

Checkout page defences built on an allowlist load approved script sources and block everything else.

That works against technique 2. It is much weaker against techniques 1, 3, 4, 5, 6 and 7, where the malicious code arrives from a source the site already trusts: its own domain, its own storage bucket, or a tag manager every marketing team relies on.

Technique 8 is a message in itself. Cleaning up the site and hoping is not a plan when something on the server undoes your fix every two minutes.

Browser protection still matters.

PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 exist for good reason, and the best tools watch how scripts actually behave inside the page rather than only where they come from.

But this campaign makes the scale clear: the checkout page was where the attacker raised small, ongoing income.

The database was where the big money was.

What Changes the Outcome

Gambit's own conclusion is the right starting point.

Where the agents got in, it usually took less than a day and often just a few hours. The report's answer is a resilience first mentality and a security stack that works at AI speed.

When an AI agent can find a new way into each target for the cost of a lunch, you have to assume it gets in. What you control is what it finds when it does.

In practice, for payment data:

• Nothing to steal in the database. With vaulted tokenization, real card numbers are replaced by random tokens that keep the same format, and the mapping is held in a vault that is isolated from the application. A dump of the Magento database gives the attacker tokens. There is no math to reverse and no decryption key in the environment to find. What is left to protect is the right to ask for a card number back.
• Card numbers reach the application already tokenized. When tokenization happens inline, before traffic reaches the application tier, the server never holds the real card number. Code that harvests card data on the server, from the application or from the database collects only tokens. A skimmer that runs in the shopper's browser is different, even when it was planted on the server, and that is the last point below.
• Getting real numbers back is tightly controlled. Turning a token back into a card number should depend on who is asking and what policy allows. Owning the server should not be enough. This is where the design decisions matter, and where buyers should push their vendors hardest.
• Protection in the browser. Scripts running in the shopper's browser read card numbers before any network control can see them. That layer needs its own tool, watching real scripts in real sessions. Tokenization makes the rest of the environment worthless to an attacker. It does not replace browser integrity.

None of this would have stopped the SQL injection. It would have changed what that injection was worth.

The Attacker is Interchangeable

It is tempting to treat this as an AI story, and at US$25 a target it is one.

But the agents did nothing a skilled human intruder couldn't do. They did it faster, more cheaply and at scale, and that removes the last excuse for relying on perimeter defences.

The same lesson applies whether the intruder is a human, an AI agent, malware or an insider:

You cannot guarantee an attacker won't get into your environment. You can make sure that getting in doesn't mean getting the data.

Sources: Eyal Sela, Gambit Security, "AI Agents Are Hacking Online Retailers for $25 a Company," September 22, 2026; Thomas Brewster, "A Chinese Hacker Used AI To Attack 100+ Companies In One Of Largest AI Hacks Yet," Forbes, September 22, 2026.