One person, a few thousand dollars of AI tokens, and more than a hundred company websites broken into. The agents in this campaign weren't magic. They went after the same weak spots a patient human tester would check: login forms, file uploads, unsafe deserialization, auth bypasses and an unpatched e-commerce platform. That's good news for defenders, because every one of those can be closed. Below is the door-by-door version for your own site, then how to tell whether something already got in, and what to do if you run AI agents yourself.
What happened, briefly
On October 19, Reuters reported that a Chinese-speaking attacker used AI agents, run through the open-source Cairn platform, against more than 1,200 websites and broke into websites belonging to more than 100 companies, including Deere, SharkNinja and Cummins. Per Reuters, the campaign started September 25 against e-commerce sites in the US, Canada, Australia and Japan. Reuters puts successful intrusions at roughly 23 hours each, and Fagerland estimated the campaign used about $5,000 in tokens overall, around $50 per successful hack (per Reuters). Deere said it took "necessary remediation actions" and had no indication sensitive information was accessed; SharkNinja said a standalone support site was affected and contained; Cummins said it was investigating a vendor-operated site. Reuters could not establish how much data was taken.
The source is NorForge researcher Snorre Fagerland, who found about two dozen exposed Cairn panels being used for malicious work. NorForge's report (also October 19) groups them into clusters; the most active, which it labels AIA0001, ran 14 panels and 1,100+ projects. NorForge puts the average success rate at around 10%. Cairn itself is a general-purpose open-source platform; nothing here suggests its developers are involved.
Why "too small to target" stopped being true
A careful, multi-hour probe of one site used to cost a skilled person a day of work. Per Reuters' figures, it now costs tens of dollars. NorForge reports the targets were ranked by traffic and pre-checked with browser automation to confirm orders could actually be placed — in other words, ordinary working shops, not just big brands. If your site takes payments or holds accounts, assume it's on someone's list.
What the agents were told to hunt
NorForge translated the actor's task list. I'm not going to reproduce it as instructions, but the shape is what matters for defenders. Agents were told to prioritise unauthenticated remote code execution, looking for:
- SQL injection on login forms
- Unauthenticated endpoints that should require a session
- File upload features
- Unsafe deserialization
- Authentication bypass and account takeover
- Server-side template injection (SSTI) and server-side request forgery (SSRF)
The goal was a small uploader shell for later access. NorForge also found a proof of concept for an Adobe Commerce / Magento flaw, CVE-2026-75650, in one agent's toolkit. Every item on that list is a well-documented class — the OWASP Top 10 guide covers injection, broken authentication and SSRF in context. So here is each door, from the defender's side.
Close each door
1. Patch the platform first
If you run Adobe Commerce or Magento, check CVE-2026-75650 today. NVD describes it as a template-engine injection flaw that can lead to arbitrary code execution without user interaction; Adobe scored it CVSS 10.0 in bulletin APSB26-146, and CISA added it to the Known Exploited Vulnerabilities catalog on September 8, 2026. Apply Adobe's fix.
The general rule outlives this one CVE: anything in KEV that touches your stack gets patched this week, not next quarter. Agents read the same advisories you do, faster.
2. Login and query paths
Use parameterized queries (prepared statements) everywhere user input meets the database, starting with login and search. Input never changes the query's structure, so the classic login bypass simply has nowhere to go. Give the app's database account the least privilege it needs, so one bad query can't read every table. The full playbook is in the SQL injection prevention guide.
3. File uploads
This is the door that matters most here, because an uploader shell was the goal. The OWASP File Upload Cheat Sheet lays out the controls:
- Allowlist the extensions you actually need; don't blocklist.
- Check the real file type, not just the name or the Content-Type header. Magic bytes are a far better signal than the name, though crafted polyglot files can still pass, so keep the other controls too; see file signatures explained and check a sample with the file signature identifier.
- Rename files on save with a server-generated name.
- Store uploads outside the web root, or on a separate storage domain, and make sure that location can never execute scripts.
- Set size limits, and require authentication for upload features wherever you can.
4. Deserialization and session stores
Never deserialize untrusted data with a native object deserializer; use a data-only format such as JSON with a strict schema (OWASP Deserialization Cheat Sheet). NorForge confirmed one intrusion by finding its uploader shell live; according to the agent's own explanation, it combined write access to an exposed memcached session store with unsafe PHP object deserialization in legacy Zend components. Two fixes follow directly:
- Bind memcached, Redis and similar caches to localhost or a private network, put them behind a firewall, and require authentication.
- Find and retire legacy framework components that still unserialize session or cookie data.
5. Errors, auth and forgotten infrastructure
Reuters describes one case where the agents, finding no weakness in a big company's main application, dug up associated infrastructure, found a public-facing control panel and exploited a subtle flaw in how it processed data. Turn off verbose errors and stack traces in production. Put MFA and rate limits on every admin login. Then inventory what you've forgotten: old subdomains, staging sites, vendor-run pages and admin panels reachable from the internet. Cummins' case was a vendor-operated site — your attack surface includes what partners run under your name.
Before an agent tests your site, test it yourself on scope you own; the web application security testing guide walks through the method.
Find out if one already got in
Assume a missed door and look for what the agents were trying to leave behind:
- New script files where none belong. Look for recently added PHP files in upload, media, cache or deeply nested directories. NorForge says one actor told agents to hide a shell in a deep directory under an ordinary-looking name such as
confirm.php, so a boring filename is not reassurance. - Upload handlers that aren't yours. Search your web root for files calling
move_uploaded_filethat don't belong to your codebase. - Accounts you didn't create. Review admin users and API keys for recent additions.
- Drift from a clean baseline. Compare the live file tree to a known-good deploy or a file-integrity baseline. Anything unexplained gets quarantined and investigated, not just deleted.
If you find a shell, treat it as an incident: preserve copies and logs, rotate credentials the server could reach, and patch the door before you rebuild.
Spot the probe in your logs
An agent run can last a day or more; NorForge says one project ran for more than five days. That patience leaves a pattern:
- Long, steady sessions from VPS and hosting networks rather than consumer ISPs. Check a source with IP address info and reverse DNS lookup.
- Headless browsers and automation frameworks. User-agent strings are easy to fake, so treat them as a hint, not proof; see what a user-agent string is and decode one with the user-agent parser.
- Hours of 4xx and 5xx responses on login, upload and API endpoints from the same source.
Rate-limit login and upload endpoints, and layer IP/ASN reputation, behavioural signals and challenges as the OWASP Bot Management cheat sheet recommends. No single signal catches a patient agent; several weak ones together usually do.
If you run AI agents yourself, lock them down
The attackers' own operation is the warning here. NorForge found these malicious panels because they were exposed to the internet. It also found legitimate red-team engagements on open panels, leaking client work. Scanning the exposed data with Trufflehog turned up hundreds of secrets, 11% verified as valid, and the panels appeared to expose full admin controls to start, stop and redirect agents.
If your team runs agents, coding assistants or AI pentest tooling:
- Never expose an agent dashboard or control panel to the internet. Put it behind SSO and a private network.
- Keep secrets out of agent context and logs; AI API key security for agents and MCP covers scoping and rotation.
- Scope tools tightly; MCP tool permissions and least privilege shows how.
- Vet an MCP server before you connect it, using the Andrax MCP scanner (39 checks, scanner 1.4.0).
Then put a policy gate between the agent and its tools. SentinelAgent Guard enforces policy on agent tool calls at runtime, with 22 controls (mcpgrade-2.0.0). The scanner's 39 checks and Guard's 22 controls are separate rubrics for different jobs; they aren't comparable scores. A grade finds risk; a gate enforces policy.
This-week checklist
- Patch CVE-2026-75650 if you run Adobe Commerce or Magento (APSB26-146)
- Check every KEV entry that touches your stack
- Parameterized queries on login, search and every other database path
- Upload allowlist, magic-byte check, rename on save, stored outside the web root, no execution
- No native deserialization of untrusted data; retire legacy components that do it
- memcached and Redis bound to localhost or a private network, with auth
- Verbose errors off; MFA and rate limits on admin logins
- Inventory subdomains, staging, vendor sites and exposed panels
- Hunt for new PHP files, unknown upload handlers and new admin accounts
- Run a quick security header check, and keep agent dashboards off the internet
Sources
- NorForge, "Inside Cairn" (October 19, 2026): https://norforge.com/blog/inside_cairn
- Reuters exclusive (via Yahoo): https://www.yahoo.com/news/us/articles/exclusive-one-hacker-used-ai-100625247.html
- The Verge: https://www.theverge.com/ai-artificial-intelligence/1013643/ai-agents-hack-john-deere-shark-ninja-cummins
- NVD, CVE-2026-75650: https://nvd.nist.gov/vuln/detail/CVE-2026-75650
- Adobe security bulletin APSB26-146: https://helpx.adobe.com/security/products/magento/apsb26-146.html
- CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-75650
- OWASP File Upload, Deserialization, and Bot Management cheat sheets (linked above)