On October 19, Reuters reported that one hacker had broken into the websites of more than 100 companies, including Deere, SharkNinja, and Cummins. The hacker did almost none of the work. AI agents did the poking and prodding, often for close to a full day per site, and the researcher who caught it estimated the AI bill for the whole spree at about $5,000.

That's the headline. The details are more useful and a little less dramatic, and they point to a handful of boring fixes that work the same whether you're a national brand or a storefront in Kingsport. I'll get to those, including the ones you can do yourself this week without calling anybody.

What actually happened

The researcher is Snorre Fagerland at NorForge, a security firm. He found the operation because the hackers left their control panels open on the internet. More than 20 of them, running an open-source AI tool called Cairn, turned up in the same kind of search engines security people use to find exposed servers. Some of those panels even exposed the hackers' own logins.

So the people breaking into websites had trouble locking their own. NorForge seemed to enjoy that part, and honestly, so did I.

The busiest group ran 14 panels with 1,139 attack projects, and NorForge's own chart counts 96 of them as reported successes. Reuters, reviewing the activity on its own, put it at more than 1,200 sites tried and more than 100 companies breached.

The targets weren't random. They were working online stores in the US, Canada, Japan, and Australia, ranked by traffic, and a script had already confirmed each one could take an order before the AI agents ever touched it. The goal was to get in and leave behind a small hidden upload page, a way back in for later. Another group's instructions to its agents were, more or less, "fetch credit cards."

Their automation also had a bug that chopped the first "w" off some site names, so "wholesale" became "holesale." That's partly how NorForge connected the panels to each other. The machines, it turns out, still need proofreading.

One operation, 1,139 tries, 96 reported successes Bar chart. NorForge counted 1,139 attack projects in the busiest cluster and 96 reported successes, about 1 in 12. One operation, by the numbers Busiest cluster in the NorForge report Attack projects 1,139 Reported successes 96 About 1 in 12 tries got in (8.4%) Source: NorForge, "Inside Cairn," Oct. 19, 2026
NorForge counts these as successes the agents reported. It confirmed one break-in firsthand. Reuters' separate review found 100+ companies breached.

Was it really "autonomous"?

Mostly automated, still human-steered. NorForge describes the agents as autonomous and semi-autonomous, and notes that the operators could drop in hints as the agents worked. A separate case from September makes the human part even clearer.

That one comes from Gambit Security. An attacker using several AI agent tools, Cairn among them, compromised at least 27 companies over five days and stole more than 600,000 credit card records, all from just two of them. Gambit confirmed card skimmers on 19 victim sites and found related skimmers on more than 100 other sites. The human behind it typed 1,951 prompts across 260 sessions and, in at least one case, already had a working admin password before the AI started. Gambit calls its report interim and says some of what the agents logged about themselves may be wrong.

The costs need one sentence of explanation, because two different numbers are floating around. The $50 figure is Fagerland's estimate of the total bill divided by successful break-ins. NorForge's written estimate is about $5 per attempt, failures included, and it calls that a rough guess. Gambit's attacker averaged about $25 per site scanned. However you slice it, it's cheap.

Why a small business should care

For a long time, breaking into a website took a skilled person's time, and time costs money. So attackers picked targets worth the effort, and small sites were mostly safe by being boring. AI agents changed the price of trying. P.K. Sharma, a security consultant, summed up the Gambit report in two sentences. "The AI did not bring scale. It brought affordability."

My read is that when an attempt costs about what lunch does, the math that kept small sites off the list stops working. That's an inference, not a finding. The Cairn targets were mid-size stores, not corner shops, and nobody has confirmed a Tri-Cities victim.

Not every expert is worried, either. Omri Segev Moyal, who runs the incident response firm Profero, wrote that his cases show a change in the mix of attacks rather than more of them, and that the AI threat is being oversold. I'd take that seriously. Both camps end up recommending the same fixes, which is the part that matters here.

The other side of the ledger is what it costs when one of these lands. Verizon's 2026 Breach Impact Study put the typical insured loss for a business under $25 million in revenue at about $38,000, deductible included. That doesn't count the damage insurance never sees, and the worst 2.5% of cases ran past 7% of a year's revenue.

What it costs them versus what it costs you Bar chart on a scale where each gridline is ten times the last. About 5 dollars per attempt and 50 dollars per success for the attacker, versus about 38,000 dollars for a typical insured small business loss. What it costs them vs. you Each gridline is 10 times the one before it $1 $10 $100 $1K $10K $100K Attacker, per attempt ~$5 Attacker, per success ~$50 Typical small-business loss ~$38,000 Sources: NorForge and Reuters estimates, Oct. 2026; Verizon 2026 Breach Impact Study (under $25M revenue)
Attacker figures are rough estimates of AI usage fees only. The loss figure is the median insured loss, including the deductible.

Rough math on rough estimates says $38,000 would pay for about 760 successful break-ins at Fagerland's number. That isn't a statistic. It's just a way to see how lopsided the trade has gotten.

You may have seen the claim that 60% of small businesses close within six months of a cyberattack. The group it usually gets credited to, the National Cybersecurity Alliance, has said it never produced that number and asked people to stop using it. Scary numbers have a way of outliving their sources. The real ones are bad enough.

They didn't come through the front door

Look at where the big names actually got hit. SharkNinja said the breach was a standalone site that only carried product support information. Cummins said it was looking into a site run by one of its vendors. Deere said it had no sign that sensitive information was accessed. Reuters couldn't determine how much data, if any, was taken.

In one case Reuters described, the agents couldn't find a weakness in a big company's main website, so they went digging through records for related systems, found a control panel sitting on the public internet, and after hours of trial and error reported getting in through it. Nick Percoco, the chief security officer at Kraken, pointed out that forgotten admin panels and vendor-hosted sites are exactly where these agents went looking.

The one break-in NorForge checked for itself fits the pattern. According to the agent's own write-up, it got in through a data store that could be written to from the internet, unsafe code on the site, and an old software component that should have been retired. Nothing new or clever was involved. The AI didn't invent a way in. It had the patience to try every old one.

Small businesses have their own versions of these side doors. They show up as an old promo site from 2019, a shop page a vendor set up and nobody logs into anymore, a "test" or "dev" copy of the website, or a booking page on its own web address. Attackers have hijacked forgotten web addresses belonging to the CDC and Deloitte, among others. Verizon's 2026 Data Breach Investigations Report found 48% of breaches involved a third party, up from 30% the year before.

The clock

A lot of small business sites run on WordPress, and WordPress itself is in decent shape. The add-ons are another story. Patchstack, which tracks WordPress security, counted 11,334 new security flaws in 2025, up 42%. Plugins accounted for 91% of them. WordPress core had six, all low risk.

Two more numbers from Patchstack matter more for a small business. 46% of those flaws were made public before the plugin's developer had a fix out, up from 33% the year before. And about a quarter of the flaws in Patchstack's database have never been fixed at all, usually because the plugin was abandoned. An abandoned plugin is like a lock the manufacturer stopped making keys for. It still looks like a lock.

Then there's speed. For the heavily targeted WordPress flaws, Patchstack says mass attacks start a median of five hours after the flaw goes public. Verizon found that organizations take a median of 43 days to fully fix a flaw already known to be under attack, and only about a quarter of those flaws get fully fixed.

5 hours versus 43 days Bar chart on a scale of days. Attacks start a median of 5 hours after a heavily targeted WordPress flaw goes public, a sliver of a bar. Organizations take a median of 43 days to fully fix known-exploited flaws, a long bar. 5 hours vs. 43 days Median time, in days 0 10 20 30 40 Attackers start mass attacks 5 hours Organizations finish fixing 43 days Sources: Patchstack 2026 (heavily targeted WordPress flaws); Verizon 2026 DBIR (known-exploited flaws, all industries)
The two numbers come from different datasets, but they describe the same race. The short bar is drawn slightly wider than scale so you can see it.

This isn't only a WordPress problem. Gambit found one of its attacker's targeting methods actually favored custom-coded shops and skipped the big commerce platforms. The common thread is a site nobody is maintaining, whatever it happens to be built on.

Backups, and the bicycle shop

One detail from the Gambit report stuck with me. At a bicycle retailer, the attacker's cleanup routine deleted 180 database tables, including backup copies the store's own administrators had made. The backups lived in the same place as the live site, so they went down with it.

A backup stored next to the thing it's backing up is really just a second copy waiting to share the same fate. CISA recommends keeping at least one copy off-site and testing that you can actually restore from it. The Tennessee Comptroller's Cyber Aware tips say much the same. Worth knowing, Gambit sells recovery tools, so it has a horse in this race. The advice still matches the government's.

The same report has one more detail I can't leave out. Gambit's director of threat intelligence, Eyal Sela, wrote that an AI agent found another criminal's card skimmer already sitting on a victim's site, took it over, and fixed the hole it had come in through. The burglar locked up on his way out. That's more maintenance than some of those sites were getting.

If you take cards online

Card skimmers are small bits of hidden code slipped into a checkout page. The sale goes through like normal, and a copy of the card number quietly goes somewhere else. Recorded Future counted 2,951 skimmer-infected websites in June 2025 and 3,341 in July. That's thousands a month, and those are just the ones it saw.

The most useful question here is a simple one. Where does your customer actually type their card number? The payment card industry's rules, which got stricter in March 2025, depend heavily on that answer.

How checkout works What it looks like What to ask
Sent to the processor's page The customer leaves your site and pays on a Stripe, PayPal, or Square page. The processor carries most of the skimmer risk on its own page. Your site still needs care, since a hacked site can send customers to a fake payment page.
Processor's form inside your page The card box looks like part of your site but is delivered by the processor. Ask your processor and your web person to confirm your page is protected against script tampering. You still share responsibility.
Card fields built into your site Your own site collects the card number and passes it along. The full payment-page rules apply to you. Someone needs to track every script on that page and watch it for changes.

If you're not sure which one you have, buy something from your own store and watch the address bar when you get to the card number. It's a five-minute test, and you get whatever you ordered.

One more thing for card-takers. If a breach does expose customer card or account information, Tennessee requires notice within 45 days, and Virginia requires notice without unreasonable delay, including to the state Attorney General. Neither one exempts small businesses, and since the Tri-Cities sits on both sides of the line, it's where your customers live that counts. That's general information, not legal advice. Talk to your attorney if it ever comes up.

About the AI part

I run a business with "AI" in the name, and one of the tools in this story, Claude Code, is one I use in my own work. So it's worth being straight about it.

Reuters reported the attacker used a mix of DeepSeek and Claude Code. NorForge's reading of the setup is that Anthropic's coding tool was running DeepSeek's model underneath, which DeepSeek publishes instructions for. NorForge calls that interpretation tentative. As of this writing, neither Anthropic nor DeepSeek has commented on the Cairn report. In the Gambit case, the attacker used an older Claude model after newer models refused, and Anthropic told Forbes it banned the account.

So the safeguards caught some of it and missed some of it. That's the honest version. These are general-purpose tools, the same kind I use to save clients time on paperwork, and they'll work for whoever points them. What stopped them in this story wasn't a smarter AI. It was a site that was patched, a panel that wasn't public, or a backup kept somewhere else.

What you can do this week

None of these need a developer. Most take less time than finding the password you need to do them.

  1. Make a list of every web address you own. Log into your domain registrar, the company you pay for your web address, and write down every domain on the account. Then think back. Old promo sites, a second domain you bought "just in case," a booking or shop page on its own address. If you're done with one, have it shut down properly rather than left to expire quietly.
  2. Search for yourself the way an attacker would. Type site:yourbusiness.com into Google. Every page that shows up is something you're responsible for. If you see a "test," "dev," or "old" page you forgot about, that's a side door.
  3. Turn on two-step login everywhere that matters. Start with your website's admin login, your hosting account, your domain registrar, and your email. CISA says to put website administrators first. If someone gets into your domain registrar, they can take your whole website and email with it.
  4. Clean out old logins. If a former employee, an old web designer, or a nephew who "helped with the site that one summer" still has an admin account, remove it.
  5. On WordPress, open Site Health. It's under Tools, then Site Health, in your dashboard. It flags inactive plugins and themes to remove and warns you if the server's PHP version is out of date. You don't have to fix those yourself, but now you know what to ask about.
  6. Check when your plugins were last updated. Look up each one on WordPress.org. If the page says it hasn't been updated in a couple of years, or warns that it hasn't been tested with recent versions of WordPress, ask about a replacement. Abandoned plugins don't get fixed.
  7. Set up Google Search Console. It's free, and Google will email you if it detects hacked content or malware on your site. It's not a security system, but it's a smoke detector you don't have to install on the ceiling.
  8. Ask for a test restore. Don't ask whether you have backups. Everybody says yes. Ask when someone last restored one, and how long it took.
  9. Write down who to call. Put your hosting company, domain registrar, web person, and payment processor on one page, along with where the logins are kept. The middle of a problem is a bad time to go looking.

Five questions for your web person

If someone else builds or maintains your site, these come straight from FTC, CISA, and NIST small business guidance. A good answer to each should be short and specific.

  1. Who updates our website software, including plugins and themes, and how often? "When something breaks" is not a schedule.
  2. Does every admin and hosting login require two-step verification? Including yours.
  3. Where are our backups kept, and when were they last test-restored? The answer should include a place that isn't the live site.
  4. Can you give me a list of everything we have online? Every site, subdomain, admin page, and plugin, and who owns each one.
  5. If something looks wrong, who do I call, and is that in our agreement? The FTC also suggests asking whether your provider has had any recent breaches. It's a fair question, and the answer tells you a lot.

The takeaway

The experts are still arguing over whether this is a new era or the same old break-ins at a lower price. Either way, the sites that got hit had the same thing in common. Somebody stopped maintaining something, or forgot it existed.

So here's the one question to leave with. Can you name the person who updates your website, and when they last did it? If you can't, start there.

If that person happens to be me, ask me all five questions above. I'd rather you ask.

Sources