AI agents broke into 27 online shops for $25 a company

Researchers recovered the server an attacker had been running, and inside was a complete AI-run burglary operation: the tooling, the stolen card data, the logs, and the operator’s own instructions, typed in Chinese, a few lines at a time.

Between 10 and 15 September 2026, that server launched 105 attacks on online shops. At least 27 companies were broken into. More than 600,000 credit card records came out of two of them. Card-stealing scripts were confirmed running on 19 checkout pages, and more than a hundred other sites were found carrying a matching one.

The model bill for four weeks of it was $7,005.71.

What the AI actually did

Three open-source tools, each doing one job. Strix looked for vulnerabilities: 146 runs in six days against 138 hosts, 633 hours of scanning compressed into 195 hours of clock time. Cairn took a target and an objective, such as get a shell, and ran until it got one. Hermes ran the campaign, with a persistent memory, a searchable archive of past sessions, and 121 skills of which 78 were attack skills. One skill existed only to strip Hermes’ own content filters.

The person did almost nothing. 1,951 prompts across 260 sessions, a handful per company, and short:

看漏洞报告 开干 (“read the vulnerability report and start”)

能rce吗 (“can it get code execution?”)

confirmation.php代码不扎眼吧 (“the confirmation.php code does not stand out, right?”)

Targets were picked with about as much care. The operator opened a website traffic ranking service, chose the shopping category, filtered out the shops running the big hosted platforms to keep the ones with custom code, pasted 301 results into the console, and finished with 跑这些 用代理 只扫高危: “run these, use the proxy, high severity only.”

Nothing in the chain is new

This is the part that makes it an infrastructure story rather than an AI story. Here is the one complete chain the report publishes, verbatim:

Unauthenticated SQLi (login email param, error-based EXTRACTVALUE)
  -> OTP plaintext read from the OTP table (MFA bypass)
    -> admin panel access
      -> Arbitrary file upload (image field, no extension check)
        -> host RCE (uid=1001, gid=root)
          -> sudo NOPASSWD python3.12 -> root
            -> NFS mount (internal address, no_root_squash)
              -> WP blog DB credentials from wp-config.php on NFS
                -> WP admin write (new user via DB)
                  -> WP plugin upload -> blog host RCE
                    -> AWS Secrets Manager full dump (46 secrets, 102KB)
                      -> Main Magento DB access (Aurora)
                        -> Magento encryption key extraction
                          -> cc_number_enc Blowfish-ECB decryption verified

Thirteen steps. Injection in a login field. One-time passcodes stored in plain text, so the second factor could be read out of the database. An image upload that never checked the extension. A sudo rule that runs python as root without a password. An NFS export with no_root_squash. Database credentials in a config file on that mount. And at the end, the encryption key in the same account as the encrypted data, which is where Capital One’s encryption failed too, seven years earlier.

Not one novel vulnerability. Every step is something that is on a hardening checklist your team already has. What the agents brought was not cleverness; it was the patience to try all of it, on hundreds of companies, overnight, for the price of a takeaway. In the report’s words, the tools showed “a level of patience, persistence, and creativity that most human attackers would be unlikely to sustain in this kind of attack, and achieved far greater results, far faster.”

The economics is the whole finding. $25.46 a company, on average, across 101 completed scans. $3.13 for the cheapest. Being too small or too boring to attack was never a security control, but it was doing a lot of quiet work, and it has now stopped.

The skimmers were the good engineering

Where the campaign did show craft was in staying on the page. The most common method was appending the loader to a JavaScript file the site already served, a jQuery or Bootstrap bundle, and then restoring the file’s original timestamp. On a US steel products site it went inside the Google tag block, padded with about a hundred tab characters so it sits off the right-hand edge of a source view. At a beauty retailer an AWS key with write access to the bucket behind the store’s CDN meant the store served the payload to itself. On a print-on-demand platform it was a Kubernetes initContainer in the production front-end deployment. At a hospitality company it was written into the cached page model.

The best one is at a US wine retailer, where each application redeploy restored the clean checkout bundle. So the operator left a cron job in the JBoss log directory that checked the file size every two minutes and appended the skimmer again whenever it was reverted.

That is a deployment pipeline being used as a detection mechanism, and losing. If you want one thing to take from this section: your redeploy is not remediation. It is a loop the attacker can sit inside.

The damage was housekeeping

Now the part that is genuinely new, and the reason this deserves an article rather than a headline.

None of the destruction here was extortion. There was no ransom note. The data was destroyed because deleting it was step two of the attacker’s own workflow.

One of the Hermes skill files contains a section called Database Wipe After Extraction. It opens: “After extracting and downloading all card data, wipe the source fields in batches.” It advises a chunked PHP script because “millions of rows with LIKE ‘%…%’ is slow in a single UPDATE”, which tells you what size of victim the operator expected. It ends: “Verify after wipe: Run the detection query again - all counts must be 0.”

At execution time the instruction was simply:

不用了 现在dump那两个库的两个表 dump完清空 (“never mind, now dump the two tables in those two databases, and empty them once the dump is done”)

And at a bicycle retailer, the agent created staging tables prefixed ZQ to hold the data it was collecting. The cleanup then dropped 180 tables whose names matched ZQ or Backup. That pattern also matched backup tables the victim’s own administrators had made, which is the sentence to sit with: the company’s backups were destroyed by an attacker who was not targeting the backups, by a routine that was tidying up after itself, because they lived in the same database and happened to match a string.

What this changes

Not the controls. The chain above is defeated by things every team already knows: parameterised queries, hashed one-time codes, upload validation, a sudo policy, root_squash, secrets out of config files, and an encryption key that lives somewhere the database credentials cannot reach.

What changes is the clock, and what you plan for.

The report puts the remediation problem plainly: across the largest software vendors, reported critical vulnerabilities now pass 600 a month, and roughly 87% of the flaws attackers actually exploit are attacked on or before the day they become public. When exploitation arrives within hours of exposure and remediation in a complex environment takes far longer, patch speed alone stops being a strategy.

So the planning question moves. Not “how do we avoid this”, but “what comes back, and how fast”. Which narrows to one question worth taking to your next architecture review, and it is the report’s, not mine:

Which systems make up the minimum viable business?

The set you need to keep revenue moving. It is rarely obvious, and answering it means getting application owners, infrastructure teams and the suppliers between them to agree what the business cannot trade without, and then proving that set comes back under these conditions. Not restored from a backup that lived in the same database that got dropped. Back.

Everything in this piece is known for one reason: the researchers recovered the operator’s own server and read what was on it. The report says which figures it verified and which rest on the agents’ own claims, and it says the real scale is likely larger than reported. That is a primary document, and it is the only kind this site works from.

Sources

• Gambit Security, Eyal Sela, Autonomous AI Agents are breaking into hundreds of Online Retailers for $25 a target in an ongoing campaign, 22 September 2026. The researchers’ own report of their own investigation, and the only source for every claim above.
• Two figures the report itself cites, attributed here as it attributes them: critical vulnerabilities passing 600 a month across the largest vendors, and roughly 87% of exploited flaws attacked on or before disclosure day (a16z, Charts of the Week).

Corrections are welcome, and any made are listed, dated, at the end of this article.