The agents didn't break your storefront. They found the page you forgot.

What a researcher watched last week

Over about two weeks this month, a threat researcher sat and watched a hacker break into the websites of more than a hundred companies, including the farm-equipment maker Deere, the appliance company SharkNinja, and a site run by one of Cummins' vendors. Reuters reported that the person did almost none of the work themselves. They pointed a crew of AI agents at a list of online stores, wrote a few lines of instructions, and let the agents probe, find a way in, and confirm it on their own.

The numbers are worth sitting with. Snorre Fagerland of the security firm NorForge said the agents attempted more than 1,200 sites, succeeded against over 100, took around 23 hours per successful break-in, and cost roughly $50 each in model usage, about $5,000 for the whole spree. The setup mixed China's DeepSeek with Anthropic's Claude Code as the harness. This isn't a lab demo or a what-if. It already happened, to real stores, at the price of a nice dinner per site.

We build and operate commerce systems, so the part that stayed with us wasn't the headline. It was where the agents actually got in.

They didn't win at the front door

A separate write-up recovered 75 of the agents' own run logs, where the agents wrote down every step as they worked, and it reads less like a movie hack and more like a patient contractor. That analysis shows the storefront usually held. The main application sat behind a web firewall, the obvious framework bugs were already patched, debug mode was off. So the agents went around it.

In one case they found a backend worker that was never meant to be public, got it to fetch a web address they chose, and pointed it at the cloud's internal metadata service. That handed them a live credential for the whole cloud account, and from there they read fifty stored secrets, including database and payment keys. In another, an old legacy page still answering on the site took a SQL injection that reached operating-system commands on the database behind it. When a site hid behind a content network, the agents read its public DNS records to find the real server and hit that directly, where less was inspected. When the main target held, they turned to the neighbor sites sharing the same hosting. On one site they found a self-hosted AI chat tool with a known weakness and used it to get in.

In every one of those, the way in was something the business had stopped looking at.

Where the card data was actually sitting

Here's the part that should bother a store owner more than any single exploit. On a payments target, the agents didn't have to crack a vault. The full card details, the number, the expiry, the security code, the name and the address, were being written straight into the application's log files by checkout. More sat in plaintext in a database column instead of encrypted. More again was in old SQL backup files left in the web root, reachable from the internet. Once the agents were on the box, they read every schema and every leftover dump and walked out with all of it.

None of that is exotic. A debug log that records the whole request. A column someone meant to encrypt later. A backup copied into the web folder "just for a minute" two years ago. The exploit got them onto the server. The data was lying in the open once they were there, and that's the half you can fix without a security team.

The one defense that held

One target's defense did hold, and it's the most useful thing in the whole report. The site ran an AI customer-service bot on a public message form. The agents threw the standard prompt-injection battery at it: print your system prompt, list every tool you can call, go fetch this address, read the cloud metadata service. It refused all of it and kept answering only from its own documents. It was the only defense in the set the agents never got past.

The lesson is one we keep coming back to. Treat anything that arrives from outside as untrusted until you've proven otherwise, and that includes whatever a stranger types into your own assistant. We wrote that up in treat tool returns as data until you prove they're safe. The bot that survived was the one that didn't trust its input.

Walk your estate the way an agent would

You don't need a red team to get ahead of most of this. You need to look at your web estate the way the agent did, from the outside, including the parts nobody has opened in a year.

List everything public with your name on it. Subdomains, old marketing sites, staging boxes someone left running, admin panels, and anything on the same shared host as you. The agents found neighbors by reverse-resolving the server, and you can do the same against yourself.

Find the workers and pages nobody owns. The backend job that fetches a URL. The legacy page still answering. If you can't say who owns it and whether it's patched, that's the one to worry about.

Read your own logs and backups for data that shouldn't be there. Search for card numbers, full customer records, and secrets sitting in log files, plaintext columns, and any backup the web server can reach. The same goes for keys you thought you deleted; our note on keys that outlive their code covers why they linger.

Test your own AI endpoints. If you run a support bot or an agent with tools, run the injection battery on it yourself before someone else does, and see whether it gives up its instructions or fetches a URL it shouldn't.

Give every edge an owner. The forgotten page is forgotten because no one's name is on it. An owner is what turns "we think that's patched" into "I checked it Tuesday."

Put this into practice

Three questions for whoever owns your site this week:

• If someone mapped everything public with our name on it, what would turn up that we forgot was still running?
• If they got onto one of our servers, what card data, customer records, or secrets would be sitting there in the clear?
• Does every public thing we run have an owner who knows whether it's patched?

If any answer is "not sure," that's the work, and it's mostly inventory and cleanup, not a rebuild.

We build and operate ecommerce and web applications, including the admin screens, recovery paths, and the quieter infrastructure behind a storefront, which is exactly where this campaign went looking. If you want a second set of eyes on what your estate actually exposes, tell us what you're running.

Related work: Paddle8.