<MT />
Back to Blog
cybersecurityAI agentsSaaS securityhardening checklistOWASPindie developersapp backends

AI Agents Hacked 100+ Sites for About $50 Each. A Hardening Checklist for Small SaaS and App Backends

T

Muhammad Tayyab

October 20, 2026·21 min read
Brass combination padlock and gold payment cards resting on a white keyboard — photo by Towfiqu barbhuiya via Unsplash

On October 19, 2026, Reuters and NorForge described AI agents breaking into more than 100 company sites for roughly $50 a successful hack. Here's what the reports actually say, and a practical afternoon hardening checklist for small SaaS and app backends.

You don't need a nation-state budget to get probed end-to-end anymore. On October 19, 2026, Reuters and the security firm NorForge described commercially available AI agents spending hours on their own looking for ways into websites, then reporting a successful break-in for on the order of tens of dollars in model tokens.

The story is alarming. It is also easy to overstate. This post sticks to what those sources say, flags what they don't, and turns the public findings into an afternoon checklist for a small SaaS or app backend: inventory what faces the internet, lock down the boring paths agents keep taking, and make sure you can notice and recover when something goes wrong.

Nothing here is a how-to for attacking anyone. It is defense only.

What the reports actually said

Reuters (October 19, 2026)

According to Reuters' exclusive by Raphael Satter (syndicated via Yahoo News and other partners; the Reuters.com URL was not available when I checked):

  • Over the past couple of weeks, a Chinese-speaking hacker broke into websites belonging to more than 100 companies, including farm equipment maker Deere, home appliance company SharkNinja and engine manufacturer Cummins.
  • The work was almost entirely done by AI agents that spent hours probing targets, per Snorre Fagerland, principal threat researcher at NorForge.
  • Fagerland found the activity by scanning for inadvertently exposed instances of Cairn, an open-source AI problem-solving platform. Beginning around October 2, he found about two dozen Cairn instances being used for malicious activity.
  • NorForge's report on this Chinese-speaking actor did not name victims. Reuters said it identified victims by independently reviewing the hacker's Cairn activity.
  • Reuters could not ascertain how far the breaches led to unauthorized extraction of data.
  • Company responses to Reuters:

- Deere: took "necessary remediation actions" and had "no indication that sensitive information was accessed." - SharkNinja: the hit was a standalone site with product support information only, and the threat had been contained. - Cummins: "investigating the report of a potential cyber-attack on a website operated by one of our third-party vendors." - Two smaller businesses also acknowledged being compromised. Other named victims in the Cairn data did not reply.

  • That Chinese-speaking actor was the most prolific Fagerland observed. Beginning September 25, agents went after US, Canadian, Australian and Japanese e-commerce websites.
  • Instructions were terse: preferred intrusion tactics in fewer than 100 Chinese characters.
  • As of late last week, agents had attempted more than 1,200 sites. Successful intrusions typically took around 23 hours.
  • Fagerland estimated the campaign used a mixture of China's DeepSeek and Anthropic's Claude Code, chewed up roughly $5,000 in tokens, or about $50 per successful hack.
  • In one case Fagerland described to Reuters (no company named): after the public app looked solid, the agents hunted associated infrastructure, found a public control panel, found a subtle data-processing weakness, and after hours of trial and error reported tricking the server into executing malicious commands.

Cairn's author, handle le1xia0, told Reuters via a recent X post that the platform "was not designed for hacking attacks" and that harmful use was "not my intention." The Verge separately quoted them saying misuse "is a human decision, not a feature of the engine."

NorForge's Inside Cairn (October 19, 2026)

NorForge's own paper, by the same researcher, is the technical primary source. Key points that matter for defenders:

  • Cairn is a state-based problem-solving engine (origin → goal via facts and intents). It can be pointed at pentesting goals; it is not only a hacker tool.
  • More than 20 exposed Cairn panels were assessed as likely malicious, all appearing financially motivated. A considerable number of apparently legitimate red-team panels were also left open, which can expose client secrets.
  • The largest Chinese-language cluster (AIA0001) spanned 14 panels and over 1,100 attack projects, mostly targeting organizations in the US, Japan and Australia, with the apparent aim of persistent access to e-commerce and payment infrastructure.
  • Typical AIA0001 tasking (NorForge's translation): find unauthenticated RCE paths such as command execution, code injection, deserialization, file-upload webshells, SQLi leading to RCE, SSTI or SSRF leading to RCE. Priorities included login SQLi, unauthenticated endpoints, file uploads, deserialization, auth bypass and account takeover. The preferred landing payload was an uploader shell, not a command-executing webshell.
  • Target selection was automated: traffic-ranked shopping sites in US/CA/JP/AU, with Playwright used to confirm orders could be placed before exploitation.
  • Worker tooling observed on one open agent folder included common recon and web-testing tools (Amass, Nmap, ffuf, dnsrecon, Playwright), PHP unserialize gadget tooling, and Magento-related research artifacts. Treat that as a map of what agents try, not as something to recreate.
  • Worker label seen: claudecode_deepseek-v4.1-flash (Claude Code-style harness with DeepSeek 4.1 Flash). NorForge's average cost per task estimate is about $5 including failed/early-ending projects; long runs could exceed $100. That is a different figure from Reuters' ~$50 per successful hack for the prolific campaign.
  • Average success rate ~10% across the harnesses they saw. For AIA0001 tasks that reached their goal, average time start-to-goal was a little under 23 hours, with about 140 facts per project.
  • NorForge ran TruffleHog over panel data and found hundreds of secrets, with 11% verified valid. Exposed panels also appeared to expose full admin controls of the harness.
  • Case studies (redacted targets) describe chains involving session-store issues, unsafe PHP deserialization, file uploads, admin-panel access and webshells. One Magento-related research CVE name appears in their tooling list; Magento's own advisory is the place to check status if you run Magento. NorForge says it cooperated with Reuters on victim notification and is pursuing panel takedowns.

Earlier context: Gambit Security (September 22, 2026)

NorForge's opening cites Gambit's interim report on a related financially motivated campaign against online retailers using Strix (vuln search), Cairn (exploitation) and Hermes (orchestration). Gambit reported, among other findings: activity dating to July 2026; 105 attack projects in five days in mid-September with at least 27 companies compromised to varying degrees; 600,000+ unexpired card records from two companies; card-skimming scripts; and a mean operator cost of about $25.46 over 101 completed scans. Gambit also warned that agent "cleanup" steps after theft can wipe or drop victim data, including backup-named tables. That is a separate investigation from NorForge's October 19 panels, but it is the same family of threat and the reason backups and restore drills sit on this checklist.

Corrections to the shortlist claim

The title's headline numbers are close, with these precision fixes:

  • "Hacked 100+ sites": Reuters says websites of more than 100 companies. NorForge reports over 1,100 projects for the main cluster and an average success rate around 10%.
  • "About $50 each": Reuters/Fagerland estimate ~$50 per successful hack on that prolific campaign (roughly $5,000 total). NorForge separately estimates ~$5 average per task including failures.
  • "NorForge reported Deere, SharkNinja, Cummins": NorForge did not name those victims. Reuters named them after reviewing Cairn activity. Treat company statements as their responses to Reuters.
  • "23 hours per breach": Both sources put typical successful intrusion / start-to-goal time around 23 hours.
  • "Probed 1,200+ sites": Reuters says agents attempted more than 1,200 sites.
  • "Minimal human input": Reuters describes terse instructions (under 100 Chinese characters). Fagerland said commercially available agents could complete complex intrusions without human intervention. Humans still chose targets and objectives.
  • "Cairn platform": An open-source problem-solving / multi-agent harness. Its author says it was not designed for hacking. Misuse is documented.

Why small SaaS and app backends should care

You are not Deere. You are also not invisible. The public tasking language is blunt: e-commerce and payment-adjacent sites with custom code, traffic worth monetizing, and weaknesses that sit in every stack indie teams ship: login endpoints, uploads, deserialization, forgotten admin panels and secrets that leak into agent blackboards when someone else's panel is left open.

Agents also hunt associated infrastructure when the main app looks clean. Staging sites, vendor portals, support microsites and "temporary" admin tools are in scope whether your marketing site is.

Afternoon hardening checklist

Aim for progress, not perfection. Each item maps to something the reports show agents looking for or stumbling into. Where I add a command or config, it is an example for a typical Node/Next or PHP-ish SaaS on a common host. Adapt to your stack.

1. Inventory what faces the internet (30–45 minutes)

Agents spend hours mapping related infrastructure. You should know yours in one sitting.

  • List every public hostname: production, staging, preview, docs, status, support, admin, vendor portals, old marketing sites.
  • Note who owns DNS and TLS for each, and whether each is still needed.
  • Check open ports and admin-ish paths on each host (/admin, /wp-admin, /phpmyadmin, /graphql, /actuator, /_debug, panel ports).
  • Prefer a managed scanner or your CDN's inventory features if you have them. OWASP's Attack Surface Analysis Cheat Sheet is a good structure.

If a host exists only because "we might need it," turn it off or put it behind SSO.

2. Shut the boring front doors: admin panels and default creds (30 minutes)

Reuters' control-panel example and NorForge's admin-access goals point at the same failure mode: something administrative left on the public internet.

  • Put admin UIs behind SSO or an identity-aware proxy (for example Cloudflare Access), not just a password.
  • Disable or rename default admin accounts. Rotate any shared passwords.
  • Block admin paths at the edge for the public internet, allow only office VPN or Access policies.
  • Turn off debug consoles, stack traces and verbose error pages in production.

3. Hunt leaked secrets in repos, client bundles and mobile apps (45–60 minutes)

NorForge found hundreds of secrets on exposed Cairn panels, 11% still valid. Gambit's chain descriptions also show keys and config files as jackpot steps after initial access. Your job is to make sure your keys aren't sitting in git history, JS bundles or app packages waiting for the first foothold.

  • Enable GitHub secret scanning and push protection (or the equivalent on GitLab).
  • Run a local history scan. Example with TruffleHog (the same class of tool NorForge used on attacker panels):
# Example only: scan local git history, verify live secrets
docker run --rm -v "$PWD:/pwd" trufflesecurity/trufflehog:latest \
  git file:///pwd --results=verified,unknown
  • Or Gitleaks in CI on every PR.
  • Search built web assets for sk_live, AKIA, BEGIN PRIVATE KEY, api_key, Firebase configs with overly broad rules, and Stripe/webhook secrets.
  • For mobile apps, treat the IPA/APK as public. Follow OWASP MASVS guidance: no long-lived secrets in the client; use backend-minted short-lived tokens.
  • If anything verified-valid turns up: rotate first, then remove from history. Rotation beats a clever git rewrite.

See OWASP's Secrets Management Cheat Sheet.

4. Patch what agents actually grind on (45 minutes)

NorForge's AIA0001 priorities and tooling list map to a short patch list: SQLi, file upload, deserialization, Magento/PHP stacks, outdated frameworks.

  • Turn on Dependabot (or Renovate) security updates and merge criticals the same day when you can.
  • Subscribe your stack to vendor advisories (Next.js, Rails, Laravel, Magento, WordPress, Django, Spring).
  • Watch CISA's Known Exploited Vulnerabilities Catalog for anything you run.
  • If you still use PHP object serialization across a trust boundary, read OWASP's Deserialization Cheat Sheet and prefer safe formats (JSON with strict schemas).
  • Lock down uploads: allowlists for extensions and content types, store outside the web root, never execute user content, scan where you can. See OWASP's File Upload Cheat Sheet.

Agents have patience measured in hours. A week-old critical on an internet-facing plugin is an invitation.

5. Rate limits and bot protection (20–30 minutes)

These campaigns are automated, multi-hour and multi-project. Slow, noisy probing should be expensive for them and loud for you.

  • Put production behind a CDN/WAF with bot management. Cloudflare documents rate limiting and Bot Fight Mode; Vercel documents its Firewall and WAF rate limiting.
  • Rate-limit login, password reset, OTP issue, file upload and expensive search endpoints per IP and per account.
  • Alert on sustained 4xx/5xx spikes and on bursts of 401/403 to admin paths.

This won't stop a clever low-and-slow chain by itself. It raises cost and buys detection time.

6. Auth hardening: MFA, sessions, keys (30 minutes)

NorForge tasking explicitly lists authentication bypass and account takeover. Gambit describes OTP/MFA bypass via backend data access once SQLi worked. Defense in depth still matters.

  • Require MFA for every human admin and for cloud consoles (AWS, GCP, Vercel, GitHub, Stripe, DNS). CISA's baseline is blunt: require multifactor authentication. Prefer phishing-resistant factors where you can; see OWASP's MFA Cheat Sheet.
  • Invalidate sessions on password change; set short idle timeouts for admin sessions.
  • Rotate API keys and DB passwords on a calendar, and immediately after any suspected exposure.
  • Separate "app can read" roles from "app can admin" roles in cloud IAM. Least privilege is how a stolen web key stops being a company-ending event.
  • Review password-reset and invite flows for account takeover bugs; add step-up auth for email/password changes.

7. Backups you have actually restored (30 minutes + a restore drill)

Gambit's report is the wake-up here: agent cleanup after card theft included wiping source fields, and one cleanup dropped 180 tables whose names matched staging/backup patterns, including real backup tables operators had made.

  • Confirm automated backups exist for primary DB, object storage and critical config.
  • Keep at least one backup copy that the production app role cannot delete (immutable / separate account).
  • Run a restore to a scratch environment this quarter and time it. A backup you've never restored is a rumor.
  • Know your "minimum viable business" systems (login, billing, core API) and the restore order for them. Gambit's remediation framing matches CISA-style resilience thinking in the ransomware guide: assume disruption, prove recovery.

8. Logging and alerts that a human will see (30 minutes)

If an agent spends ~23 hours on you, something in that window should page a person.

  • Centralize request logs, auth logs and admin-action logs (OWASP Logging Cheat Sheet).
  • Alert on: new admin user creation, privilege changes, mass download endpoints, sudden outbound traffic, webshell-like paths returning 200, and WAF rule hits on SQLi/upload/RCE signatures.
  • Keep an on-call path that works at 2 a.m.: a channel, a roster, a one-page incident card (who to call at DNS, host, payments).

9. Payment and PII specifics if you take cards

Even if you use Stripe Elements or a hosted checkout, skim-style and admin-panel paths still show up in these campaigns.

  • Prefer hosted payment fields so raw cards never touch your server.
  • Monitor for unexpected script tags on checkout pages and unexpected theme/plugin edits.
  • Restrict who can install store plugins or change CDN origin contents (Gambit notes S3/CDN write keys turned into skimmer delivery).

10. Close with a 15-minute tabletop

Write five sentences and stick them in your eng channel:

  1. How we know something is wrong (which alert).
  2. Who gets paged.
  3. How we take a surface offline without killing all revenue.
  4. How we rotate the top five secrets.
  5. How we restore the primary database.

That document is more valuable than another unread PDF.

Example: edge rate limit for login (sketch)

This is an illustrative Cloudflare WAF rate-limit shape, not a copy-paste for every app. Check current Cloudflare docs for the exact UI or Terraform resources:

Rule: Login brute / spray shield
If: http.request.uri.path contains "/api/auth/login"
Then: rate limit 10 requests / minute / IP
Action: managed challenge, then block
Notify: webhook to on-call

Pair it with per-account limits in app code so a distributed spray still hits a wall.

What this checklist is not

  • It is not a guarantee. Patient agents and novel chains will still land.
  • It is not permission to run scanners against anyone else's systems.
  • It does not replace a real pen test or bug bounty if you handle serious money or health data.
  • It does not claim Deere, SharkNinja or Cummins failed any specific control. Public statements only go as far as remediation, containment and investigation of a vendor site.

Quick checklist

  • Inventory every public hostname and admin path; turn off leftovers.
  • Put admin panels behind SSO/Access; kill default creds.
  • Scan git history and client bundles for secrets; rotate anything live.
  • Patch criticals; harden uploads and deserialization.
  • Turn on WAF rate limits and bot protection; alert on auth abuse.
  • MFA everywhere admins live; least-privilege cloud keys.
  • Immutable backups + a restore drill; protect backup-named data from reckless deletes.
  • Central logs and a one-page incident card.
  • If you take payments, lock down scripts, plugins and CDN write access.

If you're hardening a small SaaS or mobile-app backend and want a second pair of eyes on the attack surface list, get in touch.

About the author: Muhammad Tayyab is a full stack and mobile developer based in Lahore. He builds DripScore, an AI outfit rating app live on the App Store, under dawnapps.co. Find him on GitHub, LinkedIn, and X, or say hello at /#contact.

Sources

Back to all posts
Thanks for reading 🙏