An Attacker Pointed AI Agents at 105 Online Retailers for About $25 a Target. Here's What Your Small Store Should Assume Now.
Israeli security firm Gambit reports that an attacker used open-source AI agents to run 105 attack waves against online retailers between September 10 and 15, and got into at least 27 of them. Gambit puts the cost at about $25 per target. More than 600,000 valid card details were stolen from two companies. If you run a store with custom code and a checkout page, the economics of who is worth attacking just changed.
What Gambit actually found
According to BleepingComputer's write-up of the report, the operator gave the agents short instructions and let them run. Three tools did the work. Strix handled vulnerability scanning, and the report counts 146 runs against 138 hosts between August 23 and 31, about 633 scanning hours. Cairn handled autonomous exploitation, with goals like getting a shell or admin access. Hermes orchestrated the campaign and made tactical decisions after a foothold, reportedly using claude-opus-4.6 through OpenRouter.
Targets came from a website traffic-ranking service, and sites running custom software were prioritized, presumably because they were more likely to have exploitable bugs. Gambit says access often took only a few hours. The injection methods were varied: modifying legitimate JavaScript, adding script tags to checkout pages, poisoning S3 and CDN content and server-side caches, and using cron jobs to put skimmers back after cleanup.
The cost numbers are the story
An OpenRouter account associated with the operator showed $7,005.71 spent over about four weeks as of August 25. The operator's own review, per Gambit, showed a mean cost of $25.46 across 101 completed scans, ranging from $3.13 to $79.31. Gambit estimates total campaign costs of $12,000 to $18,000.
Compare that to what a small store holds. A few thousand stored customer records, a payment page and an admin login are worth far more than $25 to someone who sells card data. Until recently, attackers had to be selective, because human time was the expensive part. Here, the expensive part was a few dollars of API credit per site.
That changes the question. "Am I big enough to be a target?" used to be a reasonable thing to ask. With per-target costs this low, a traffic ranking is a shopping list.
Attacks that also destroy
The detail I'd read twice: a cleanup instruction in a Hermes skill file told the agent to "wipe the source fields in batches" after pulling card data. In Magento databases, that meant the data was gone after exfiltration, causing data loss and outages at several retailers. The victims didn't only get skimmed. Some lost records they may not have backed up.
So the checklist has two halves: keeping people out, and being able to recover when someone gets in anyway.
What a solo operator can do this week
I'd keep this short and boring, because boring is what gets done.
- Inventory your checkout page's scripts. Write down every third-party script that loads on payment pages. Anything you can't explain gets removed.
- Lock checkout assets. Use a Content Security Policy that lists allowed script sources, and Subresource Integrity hashes on scripts you host or pull from a CDN.
- Lock your storage. Check that S3 buckets and CDN origins behind your site aren't writable by anything except your deploy pipeline.
- Back up and test a restore. Keep database backups somewhere the app's own credentials can't delete. A backup you have never restored is a hope.
- Move card handling off your servers. If card numbers never touch your code because a payment provider's hosted fields or checkout page handles them, there is nothing for a skimmer to harvest from your database.
- Turn on admin MFA and update the boring stuff. Custom code gets the attention, but unpatched plugins are still cheap targets.
Gambit's published coverage doesn't name the specific bugs that were exploited, so I can't tell you which patch would have saved a given store. That's part of the problem: you can't patch your way out of a campaign when the exploit is found on the fly.
Where I could be wrong
The numbers come from one security vendor's reconstruction, and the cost figures depend on an account balance and the operator's own logs. Some of the stolen-card count may overlap, and "compromised" covers a range from skimmer deployment to full access. Also, a campaign like this is aimed at sites in traffic rankings. A very small store with little traffic may still sit below the radar, at least until rankings stop being the filter.
What I'd actually do
I'd assume scanning against my sites is constant and cheap, and spend my time on the three things that limit damage: no card data on my servers, a locked-down checkout page, and a restore I've actually tested. If I only had an hour, I'd do the restore test first, because that's the one that turns a bad day into a recoverable one.
Author
Lukas
@lukcombinator