A financially motivated attacker used AI agents to probe more than 1,200 websites and compromise sites belonging to more than 100 companies, according to a new investigation that offers an unusually detailed view of autonomous hacking in the wild.
The campaign began on September 25 and targeted e-commerce sites in the United States, Canada, Japan and Australia. Reuters independently reviewed the attacker’s activity and identified sites associated with Deere, SharkNinja and Cummins among the apparent victims. Deere reported taking remediation steps and found no indication that sensitive information was accessed. SharkNinja said the affected property was a standalone product-support site and that the incident had been contained. Cummins was investigating a website operated by a third-party vendor.
The attacker did not compromise every target. The distinction matters: more than 1,200 sites were attempted, while Reuters connected more than 100 organizations to successful intrusions. The reporting did not establish that data was stolen from every compromised site.
The operation ran through Cairn, an open-source framework that coordinates multiple AI workers toward a defined goal. Cybersecurity firm NorForge found the campaign after discovering unsecured Cairn dashboards on the public internet. Its October 19 report documents more than 20 panels likely tied to malicious activity, along with exposed systems used by legitimate red teams.
How Cairn turned one instruction into a day-long intrusion
Cairn does not use a fixed sequence of reconnaissance and exploitation steps. An operator supplies an origin, such as a target domain, and a goal. Workers add verified findings, called facts, and proposed next steps, called intents, to a shared blackboard. Each worker can read that accumulated state and choose another branch to explore. A human can inject hints, but the system is designed to keep moving without constant supervision.
That architecture helps explain how a short request became a long-running attack. NorForge found that the most active cluster, labeled AIA0001, contained more than 1,100 projects across 14 panels. Its instructions prioritized unauthenticated remote code execution, injection, unsafe deserialization, file uploads, server-side request forgery and account takeover. The surrounding pipeline had already ranked shopping sites by traffic and used Microsoft Playwright to confirm that customers could place orders before passing a target to Cairn.
Successful AIA0001 projects took just under 23 hours on average and generated about 140 facts. Some ran for days. The agents could abandon an unproductive path, preserve useful reconnaissance and continue elsewhere without asking the operator to direct every move.
The workers had a conventional offensive toolkit rather than a novel AI-only exploit. NorForge observed Chromium and Playwright for browser automation, Amass and dnsrecon for discovery, ffuf for web fuzzing, Nmap for service scanning, PHPGGC for testing PHP deserialization chains, and code or lab artifacts related to Magento and Odoo. The significant change was how cheaply and persistently the framework could combine those tools across many targets.
The $5,000 figure is an estimate, not an invoice
Reuters reported NorForge researcher Snorre Fagerland’s estimate that the prolific campaign consumed roughly $5,000 in model tokens, or about $50 for each successful intrusion. The estimate should be read as an order-of-magnitude indicator. NorForge did not have the attacker’s billing records, and its own report warns that model pricing, caching and project length create substantial uncertainty.
The underlying pattern is still consequential. NorForge estimated that tasks averaged about $5 when failed and short-lived projects were included, while complex projects with more than 1,000 facts and intents could exceed $100. A campaign can therefore tolerate a low hit rate if agents can test large numbers of sites without tying up a human operator.
NorForge estimated an average success rate around 10% across the observed harnesses, although the three activity clusters pursued different goals and cannot be compared cleanly. One English-language cluster focused directly on payment-card and cryptocurrency theft. Another mixed small e-commerce targets with large commercial platforms and sometimes described its work as authorized testing before shifting toward shell, database or administrator access.
What researchers verified on victim systems
The strongest evidence went beyond a dashboard claiming success. NorForge visited a shell URL recorded in a completed task against a hardware-parts vendor and found that the uploader was still live. The agent’s notes described unauthorized write access to a memcached session store, unsafe PHP object deserialization and a gadget chain in legacy Zend Framework components.
In another case, researchers validated a compromise in which the agent found a particular cookie setting that routed requests to a vulnerable backend. Other case studies covered an Australian retailer, a restaurant point-of-sale system, a Japanese retailer and U.S. web applications. NorForge redacted victim identities and most panel addresses because some systems remained exposed.
The dashboards created a second breach surface. NorForge ran TruffleHog over captured panel data and found hundreds of secrets; 11% were verified as valid by the scanner. The unauthenticated interfaces appeared to expose controls for starting and stopping projects, inserting hints, redirecting agents and restarting completed work. NorForge did not test those administrative controls.
That finding applies to authorized security teams as well as criminals. A red-team platform can contain client credentials, discovered vulnerabilities, working payload locations and detailed maps of customer infrastructure. Leaving its control plane online without access controls may expose more sensitive information than an ordinary monitoring dashboard.
What defenders should check now
There is no single Cairn vulnerability or universal patch behind this campaign. The agents found different weaknesses at different sites. Defenders need to inspect both their public application estate and any AI security tooling operating inside it.
- Inventory public agent panels. Search cloud accounts, VPS inventories, DNS records and external attack-surface data for Cairn or other agent dashboards. NorForge found affected Cairn services on port 8000, but teams should not treat one port as a complete detection rule.
- Restrict the control plane. Put authorized assessment platforms behind identity-aware access, a VPN or a tightly controlled management network. Require strong authentication and log every project creation, hint, target change and worker action.
- Review execution privileges. Cairn supports containerized workers and a local mode that can run coding-agent command-line tools with the host user’s permissions. Audit Docker socket access, mounted directories, cloud credentials, SSH material and any path that lets a worker reach production systems.
- Assume exposed secrets were copied. If an agent panel, project store or staging host was reachable without authorization, rotate credentials rather than relying on dashboard removal. Check API gateways and identity logs for use of old tokens before and after rotation.
- Hunt for persistence, not only initial access. Review newly created PHP files, upload directories, scheduled tasks, administrator accounts, modified application packages and outbound callbacks. Compare web roots with known-good releases and investigate uploaders even when they do not expose a command shell.
- Isolate session infrastructure. Memcached, Redis and similar session stores should not be internet-reachable or writable from broad network segments. Review PHP deserialization paths and remove legacy framework components that make object-injection chains possible.
- Correlate slow automated probing. A successful run could last nearly a day. Join WAF, reverse-proxy, application, DNS and endpoint telemetry so low-volume discovery, browser automation, fuzzing, unusual cookies and later file creation are not treated as unrelated events.
- Include forgotten sites and vendors. Product-support portals, campaign microsites, old stores and third-party-hosted properties still carry a company’s name and can provide infrastructure clues or persistent access. SharkNinja and Cummins’ responses show why inventories must include externally operated sites.
NorForge is working with Reuters to notify victims and seek takedowns of the exposed panels. Its public indicators include two AIA0002 staging addresses, 199.247.25.25 and 199.247.27.2, but the company redacted most panel addresses. Organizations should treat those indicators as starting points, not as proof that an environment is clear when no match appears.
Autonomy changes the economics more than the exploits
The observed agents mostly used recognizable web-application techniques and widely available tools. They did not need a breakthrough zero-day to change the risk calculation. A single operator could feed validated targets into a system that worked for hours, preserved state across many branches and accepted failure as a routine cost.
That makes neglected applications more attractive. A site that was previously too small to justify a skilled attacker’s time can still be profitable when automated workers scan, test and revisit it cheaply. The defensive response remains familiar—complete asset inventories, smaller public attack surfaces, current software, segmented secrets and telemetry that spans the full application stack—but the time available to correct gaps is getting shorter.
