Researchers report AI agent framework used to skim cards from 119 e-commerce sites

A financially motivated operator has been using open-source AI agent frameworks to attack online retailers in bulk, according to findings from the security startup Gambit reported by BleepingComputer. The campaign has been running since at least July and was still active on 22 September. Gambit says more than 600,000 valid card records were taken, and that skimmer code ended up on at least 119 websites [1].

The striking part is not the tooling but the throughput. Between 10 and 15 September the operator reportedly launched 105 distinct attack waves and got somewhere on at least 27 of them. Gambit’s numbers put the average cost at roughly $25 per target — an OpenRouter account showed $7,005.71 spent over about four weeks as of 25 August, with total campaign spend estimated at $12,000 to $18,000. The operator’s own cost review reportedly matched that, averaging $25.46 across 101 completed scans, ranging from $3.13 to $79.31 [1].

Gambit researchers say they obtained access to a staging server used by the operator, which is where much of the direct evidence came from. The operator appears to be Chinese, gave the agents short instructions describing the objective, and largely let them work [1].

Who is affected

Gambit names victim categories rather than companies: a Fortune 500 hospitality company, a major US airline, a large US industrial supplies distributor and an online fashion retailer are all described as breached [1]. The named merchants are not disclosed, so individual shoppers have no way to check exposure from this reporting alone.

The victim counts in the source are not fully consistent and worth reading carefully. The report describes 600,000+ card records stolen from two companies, skimmers deployed against five other organisations, and a total of 119 websites carrying skimmers. Those figures are probably counting different things — organisations breached versus individual sites hosting the skimmer — but the source does not reconcile them.

Targeting was opportunistic and ranked. The operator reportedly fed results from a website traffic-ranking service into the target list produced by the scanner, then prioritised sites running custom software on the assumption that bespoke code is weaker [1].

How it worked

Three components are described [1]:

• Strix, an open-source penetration testing framework, handled scanning and vulnerability discovery. It ran 146 times against 138 hosts between 23 and 31 August, accumulating 633 hours of scanning.
• Cairn, described as an autonomous exploitation engine, was given objectives such as getting a shell or administrative access. The source notes this is a different thing from the same-named AI malware analysis tool released by Cisco Talos.
• Hermes handled orchestration, post-exploitation and tactical decisions, running on claude-opus-4.6. It carried a persona labelled “SOUL - Red Team Operator” and 121 skills, 78 of them attack-related.

Skimmer placement varied with the level of access obtained, the vulnerabilities found and the target’s architecture. Per the source [1], the injection points seen included:

• database field edits
• Kubernetes deployment changes
• content poisoning in object storage, CDNs and server-side caches
• script tags added to checkout pages or to Google tag blocks
• malicious code appended to legitimate JavaScript files
• cron jobs that put the skimmer back after it was removed

The source does not identify which vulnerabilities or products were exploited to gain initial access, and no CVEs are named. Treat the initial-access path as unknown.

The destructive part

One Hermes skill file instructed the agent to clean up after exfiltration by wiping card data out of Magento databases in batches [1]. That is presumably an anti-forensics measure, but the practical effect was data loss: Gambit says several retailers suffered operational disruption because of it.

That changes the shape of the incident. A skimming compromise is normally a confidentiality problem you handle with notification and card reissuance. Here the same intrusion also destroys records the merchant needs, so recovery depends on backups that predate the wipe, and reconstructing what was taken depends on logs the attacker may have been positioned to touch.

One caveat on sourcing: this all traces back to a single vendor report relayed by one outlet. There is no independent corroboration in the material available to us, and the underlying research has not been cross-checked here.

What to do

• Check what your checkout pages actually load. Compare the scripts served to real users against an approved inventory, from an external vantage point, not just from staging. Include tag manager containers and third-party CDN paths.
• Look for reinstallation mechanisms, not just the skimmer. Audit cron jobs, scheduled tasks, Kubernetes manifests and deployment pipelines. Removing injected JavaScript without finding the restore job buys you hours, not a fix.
• Verify integrity of cached and object-store content. Server-side caches, S3 buckets and CDN origins were all reportedly used as injection points. Confirm write permissions on those paths and check for unexpected recent modifications.
• If you run Magento, check for unexplained gaps in payment-related fields. Batch wiping of card data is a reported behaviour in this campaign. Treat missing data as a possible indicator of compromise rather than a database fault.
• Test that backups survive an attacker with write access. Immutable or offline copies matter here specifically because the intrusion included deliberate destruction.
• Assume scanning volume is no longer a filter. The reported campaign covered 633 scanning hours against 138 hosts in nine days, within a total estimated spend of $12,000 to $18,000; the source does not break out what the scanning phase alone cost. Either way, small and mid-sized merchants with custom code sit inside the economically viable target set. Prioritise external attack surface reduction accordingly.
• Prepare notification and card-reissuance paths in advance. If cardholder data is in scope, the response clock starts before you finish scoping the intrusion.