AI agent cyberattacks have reached a troubling new scale after a security investigation documented how a Chinese-speaking threat actor used autonomous software agents to target more than 1,200 websites, reportedly gaining access to sites belonging to over 100 companies for an estimated $5,000 in AI usage costs.
The operation relied on Cairn, an AI-driven problem-solving platform that can coordinate agents through long-running technical tasks. Rather than manually investigating every website, the operator supplied targets and objectives while the agents searched for weaknesses and attempted to establish access.
The findings come from cybersecurity company NorForge, whose researcher Snorre Fagerland examined publicly exposed Cairn control panels. Reuters independently investigated the activity and identified affected organizations, including Deere, SharkNinja and Cummins.
But the reported company impacts differed significantly. The public evidence does not establish that every targeted website was breached, that all reported intrusions involved data theft, or that the attacker was acting on behalf of the Chinese government.
What the investigation does show is how commercially available AI tools can help a single operator sustain complex intrusion attempts against large numbers of internet-facing applications.
The campaign adds a real-world example to the broader risks explored in our AI Cyber Threats and Agentic Security Guide, particularly the security implications of systems capable of selecting tools and pursuing objectives across multiple steps.
Key Findings From the AI Agent Cyberattacks
- Reported scope: More than 1,200 websites were targeted, with over 100 company website intrusions reported.
- Researcher: Snorre Fagerland, principal threat researcher at NorForge.
- Framework: Cairn, a state-based AI problem-solving and agent coordination platform.
- Activity cluster: NorForge tracked the most active Chinese-language operation as AIA0001.
- Exposed infrastructure: AIA0001 was associated with 14 Cairn dashboards containing more than 1,100 attack projects.
- Target sectors: The operation concentrated on shopping, e-commerce and payment-related websites.
- Estimated cost: Approximately $5,000 in AI token usage for the main campaign, according to the researcher’s estimate reported by Reuters.
- Attack duration: Successful AIA0001 projects took slightly less than 23 hours on average, with some projects running much longer.
- Observed techniques: The tasks directed agents toward application vulnerabilities, authentication weaknesses and methods of placing uploader webshells.
- Confirmed technical outcome: NorForge independently validated selected intrusion claims, including an accessible uploader webshell on a targeted website.
How One Hacker Used AI Agents to Attack More Than 1,200 Websites
The campaign began around September 25, 2026, according to Reuters’ account of the investigation.
Instead of repeatedly performing every reconnaissance and exploitation step by hand, the operator used an automated workflow to supply targets to Cairn.
NorForge identified an activity cluster called AIA0001, associated with 14 exposed dashboards and more than 1,100 attack projects. These projects focused heavily on commercially active websites in the United States, Japan, Australia and Canada.
The task pipeline included Microsoft Playwright, a browser automation framework, to check whether selected e-commerce sites appeared operational and could accept orders.
That mattered to the apparent objective. The operator was not simply collecting random vulnerable domains; the instructions indicated interest in shopping and payment systems that could potentially be monetized after compromise.
Once targets were selected, the operator provided Cairn with an objective. The system could then organize investigations, retain findings and direct agent workers toward potential ways of reaching the goal.
According to NorForge, the instructions prioritized weaknesses such as unauthenticated application endpoints, SQL injection, insecure file uploads, deserialization problems and authentication bypasses.
Those instructions reflected attacker intent. They do not establish that every listed technique succeeded or that every target contained those weaknesses.
What Is Cairn and How Did It Automate the Intrusions?
Cairn is a general-purpose state-based problem-solving platform. NorForge explained that it is not exclusively designed for offensive security, although the observed actors were using it for intrusion activity.
Its architecture helps explain how the reported attacks could continue for hours with limited human intervention.
Each Cairn project begins with an origin and a desired end state.
Between those points, the system records discoveries as facts and potential next actions as intents. A project-internal blackboard makes those findings available to other workers participating in the same task.
That gives the workflow a way to preserve context rather than treating each technical test as an isolated interaction.
When a particular path fails, the system can use earlier observations to explore other approaches toward the same objective.
A human operator can also add instructions or hints to the shared project state.
For legitimate security teams, this type of coordination can support complex authorized testing. For an attacker, the same architecture can reduce the amount of manual interaction needed to investigate a large target set.
NorForge’s evidence shows why the distinction matters. A goal-driven agent may continue investigating related infrastructure even when the first application it examines does not provide a usable entry point.
Cairn AI Hacking Campaign: What Researchers Actually Observed
NorForge’s technical report provides a closer view of the AIA0001 operation than a typical post-incident summary.
The researchers encountered publicly accessible Cairn panels containing project histories, task instructions, discoveries and information about targeted organizations.
Some entries documented attempts to identify exploitable web application weaknesses. Others described workflows intended to place an uploader webshell on a target server.
An uploader webshell is a server-side component that can permit files to be uploaded to an affected system. Its presence may provide a foothold for additional unauthorized activity, depending on its capabilities and the server’s permissions.
In one case, NorForge examined a completed project against a hardware parts vendor. The researchers checked the reported shell location and confirmed that an uploader webshell was accessible.
The agent’s own account described an attack path involving unauthorized write access to a Memcached-backed session store, unsafe PHP object deserialization and legacy Zend Framework components.
That explanation came from the agent’s recorded output. Although NorForge verified the resulting uploader, the complete exploit sequence should not be treated as independently reproduced merely because the agent described it.
Other documented cases involved e-commerce systems and application behavior that allowed the agents to move toward server access.
The important point is that the agents were not limited to producing vulnerability descriptions. Some completed tasks were associated with observable changes on real target systems.
How Long Did the Autonomous Attacks Run?
The investigation challenges the assumption that AI-assisted intrusion attempts are necessarily short, single-prompt operations.
For AIA0001 projects that achieved their stated goals, NorForge reported an average duration of slightly under 23 hours.
Those successful projects generated approximately 140 recorded facts on average. At least one project continued for more than five days.
This long-running behavior allowed the agents to accumulate technical observations, pursue alternate hypotheses and maintain progress without requiring the operator to personally conduct every step.
NorForge estimated that the observed frameworks achieved roughly a 10% success rate across the campaigns examined.
However, that percentage requires caution.
Different operators used different definitions of success. One project might be considered complete after establishing a vulnerability, while another required demonstrable access to the target server.
The figure should therefore not be interpreted as a measured success rate for every AI model, website category or future campaign.
Even unsuccessful projects could produce useful reconnaissance information that an attacker might reuse.
How Much Did the AI-Driven Hacking Operation Cost?
One of the most significant findings is the relatively low estimated operating cost.
Fagerland estimated that the main campaign consumed approximately $5,000 worth of AI tokens, according to Reuters.
That works out to roughly $50 for each reported successful intrusion when the estimated total is compared with the approximate number of successful compromises.
NorForge separately estimated an average task cost of around $5 when unsuccessful and early-ending projects were included.
These are not contradictory figures. They describe different denominators: all observed tasks versus reported successful compromises.
More importantly, they are estimates rather than confirmed billing records.
The true cost depends on model pricing, token usage, caching, infrastructure and other operating expenses that were not fully established in the public evidence.
The larger implication is not a precise dollar amount. It is that an individual operator may be able to keep many investigation workflows active without employing a large human team.
That changes the economics of sustained application probing.
Were Claude Code and DeepSeek Used in the Attacks?
NorForge observed agent workers with a name resembling claudecode_deepseek-v4.1-flash.
The naming suggests a possible configuration combining a Claude Code-style agent harness with a DeepSeek model.
But researchers could not conclusively establish every component of the underlying model configuration from the available evidence.
It would therefore be inaccurate to present the campaign as proof that Anthropic’s hosted Claude model independently hacked the companies.
Claude Code is a coding-agent environment, while an underlying language model is the system that generates responses or tool-use instructions. Depending on configuration, an agent framework may be connected to different model providers.
NorForge also found indications that part of the tooling had been adapted from an earlier capture-the-flag environment.
That does not establish that the original software provider or the organization associated with the earlier environment participated in the malicious campaign.
Likewise, Chinese-language prompts do not establish the operator’s citizenship, physical location or government affiliation.
What Happened to Deere, SharkNinja and Cummins?
Reuters independently examined the exposed Cairn activity to identify organizations associated with reported intrusions.
Among the companies discussed were agricultural equipment manufacturer Deere, consumer appliance company SharkNinja and engine manufacturer Cummins.
The responses from those organizations differed.
Deere
Deere told Reuters that it had taken remediation measures following the incident and had no indication that sensitive information was accessed.
That statement does not mean every aspect of the investigation has been publicly documented, but it does limit what can responsibly be claimed about data exposure.
SharkNinja
SharkNinja said the affected system was a standalone website containing product-support information, and that the threat had been contained.
The available statement does not support a claim that the company’s wider corporate infrastructure or customer payment systems were compromised.
Cummins
Cummins told Reuters it was investigating a potential cyberattack involving a website operated by a third-party vendor.
A possible incident involving a vendor-operated website should not be described as a confirmed compromise of the company’s core enterprise network.
Reuters could not establish the full extent of unauthorized data extraction across the campaign.
These distinctions matter because a website intrusion, a vendor-hosted application incident and confirmed sensitive-data theft are different security outcomes.
Exposed AI Agent Dashboards Created Another Security Risk
The investigation revealed a second problem beyond the attacks themselves: many Cairn control panels were accessible from the public internet.
NorForge found more than 20 exposed panels associated with suspected malicious activity, alongside apparently legitimate security-testing environments that had also been left accessible.
The dashboards contained information about targeted systems, discovered weaknesses, credentials and API keys.
The researchers ran TruffleHog against data collected from the exposed environments and reported hundreds of secrets, approximately 11% of which were validated as active.
That creates risk even when the underlying testing activity is authorized.
An exposed security-testing dashboard may reveal customer infrastructure details, unpatched vulnerabilities or credentials to anyone who can reach it.
For malicious operators, exposing their own panels can also compromise operational secrecy.
NorForge said the interfaces appeared to expose administrative controls for managing projects, but the researchers did not attempt to exercise those controls without authorization.
As a result, the apparent administrative exposure should not be confused with independently demonstrated takeover of every exposed agent.
Still, the finding illustrates a broader problem: powerful AI-enabled tools can increase risk when their management interfaces and stored secrets are not properly protected.
How Security Teams Can Detect AI-Driven Website Intrusions
There is no single signature that identifies every AI agent cyberattack.
The tools and models used to plan an intrusion do not necessarily leave a distinct fingerprint in the target application’s logs.
Defenders should focus on observable attacker behavior and the security weaknesses being exploited.
1. Investigate Repeated Application Probing
Review reverse-proxy, web-server, WAF and application logs for unusual sequences of requests against authentication routes, administrative functions, upload handlers and other sensitive endpoints.
Long-running requests against related paths or hosts may warrant investigation, particularly when they correlate with failed authorization checks or application errors.
Automated traffic can also be generated by legitimate testing and monitoring systems, so decisions should rely on context rather than request volume alone.
2. Review File Uploads and Unexpected Web Files
Monitor web-accessible directories for unfamiliar server-side scripts, recently created executable files and changes to application assets that are inconsistent with authorized deployments.
Investigate suspicious file creation together with the associated HTTP requests, process activity and user identities.
Do not assume every unfamiliar PHP file is a webshell. Verify its origin and function.
3. Monitor Authentication and Session Integrity
Unexpected session modifications, unusual privileged logins and changes to account access may reveal activity that occurred before a visible webshell was placed.
For applications using shared session stores, assess who can read or modify session data and whether application-level trust boundaries are enforced.
Unsafe deserialization and insecure session handling are particularly important to review when application telemetry or incident evidence points toward them.
4. Investigate Publicly Reachable Management Panels
Inventory internet-accessible AI-agent dashboards, development consoles, automation platforms and security-testing interfaces.
Require strong authentication and restrict management access to approved users and networks wherever possible.
Review whether project histories or shared workspaces contain production credentials, customer data or sensitive infrastructure details.
5. Correlate Findings Across Systems
A single WAF event rarely explains the full intrusion.
Correlate web logs with application telemetry, deployment histories, filesystem changes, authentication events, database activity and endpoint alerts.
The objective is to reconstruct whether suspicious requests produced a real security impact rather than simply generating noise.
Remediation Verification for Potentially Compromised Websites
Organizations that identify suspicious application activity should first determine whether unauthorized access occurred.
If a webshell or similar unauthorized file is found, preserve evidence and activate the appropriate incident-response procedure before making destructive changes.
Response teams should:
- Identify affected applications, hosts, accounts and externally exposed interfaces.
- Preserve relevant web, application, system and authentication logs.
- Determine whether unauthorized files or server-side components were introduced.
- Review session stores, authentication controls, file-upload handling and deserialization paths for weaknesses supported by the evidence.
- Restrict attacker access and remove confirmed unauthorized components through an approved remediation process.
- Patch the affected application or configuration weakness once the root cause is established.
- Rotate credentials and tokens where compromise or exposure is credible.
- Review for data access, lateral movement and additional persistence before returning systems to normal operation.
- Verify that the vulnerability is no longer exploitable and that suspicious access has not resumed.
For third-party-operated websites, both the service owner and vendor may need to coordinate investigation and remediation.
Organizations running Cairn or similar agent platforms should also protect their own dashboards, audit stored secrets and limit worker permissions.
The investigation does not establish a single CVE or universal patch for this campaign. Defensive actions must be based on the weaknesses identified in each environment.
Confirmed vs Unknown: What the Investigation Establishes
Confirmed or Supported by Published Evidence
- NorForge identified more than 20 publicly exposed Cairn panels apparently associated with malicious activity.
- The AIA0001 cluster used Chinese-language instructions and was associated with 14 dashboards.
- AIA0001 contained more than 1,100 attack projects focusing heavily on e-commerce targets.
- Researchers directly validated selected intrusion outcomes, including an accessible uploader webshell.
- Successful AIA0001 projects averaged slightly less than 23 hours from start to recorded goal completion.
- Reuters reported over 100 company website intrusions and obtained responses from named organizations.
- Exposed dashboards contained numerous secrets, including some that NorForge verified as active.
Unknown, Estimated or Not Established
- The attacker’s confirmed nationality, identity or government affiliation.
- The exact number of successful compromises across every targeted website.
- The complete quantity and type of data stolen, if any, from each victim.
- The exact AI model configuration behind every worker.
- The operator’s complete financial expenditure.
- Whether each agent-reported exploit chain occurred exactly as described.
- The final remediation status of all affected sites.
- Whether the approximate 10% success estimate applies beyond the observed campaigns.
NorForge did not identify obvious state-sponsored activity in the exposed panels. The operation should therefore be described as Chinese-language or Chinese-speaking activity, not a confirmed Chinese government cyberattack.
CyberUpdates365 Analysis
This investigation is significant because it shows how AI-assisted intrusion activity can become a sustained workflow rather than a series of isolated prompts.
A single operator could supply a target and objective, then rely on an agent framework to preserve findings, select follow-up actions and continue technical investigations over extended periods.
The agents did not require every attempted path to succeed. Failed tests could still contribute information that shaped later decisions.
For defenders, that creates a familiar security challenge at a different operating scale.
Internet-facing applications still need vulnerabilities, authentication weaknesses or insecure configurations for an attacker to exploit. AI does not eliminate those prerequisites.
What changes is the effort required to search for viable paths and maintain attention across many targets.
The reported cost estimates also suggest that financial barriers may be lower than organizations previously assumed when assessing persistent, multi-target intrusion activity.
At the same time, the exposed Cairn dashboards highlight a weakness in the attackers’ own setup.
The infrastructure used to coordinate powerful agents can become another high-value security target when it contains credentials, findings and administrative controls.
This reinforces the argument discussed in our AI agent security enforcement analysis: knowing that an agent exists is not sufficient. Organizations also need to control its permissions, protect its management interfaces and understand the actions it can perform.
The central lesson is not that every AI assistant is an autonomous hacker.
It is that adaptable agents, ordinary security tools and inadequate application defenses can combine to make sustained attacks more accessible to individual operators.
Security teams should focus on reducing exploitable exposure and enforcing agent boundaries, rather than expecting AI-driven intrusions to have a unique and easily recognizable signature.
Research Evidence
- Original investigation: NorForge, October 19, 2026.
- Lead researcher: Snorre Fagerland.
- Agent platform: Cairn.
- Principal activity cluster: AIA0001.
- AIA0001 dashboards: 14.
- AIA0001 projects: More than 1,100.
- Broader malicious panel exposure: More than 20 Cairn installations.
- Reported campaign targets: More than 1,200 websites.
- Reported intrusions: More than 100 company websites.
- Typical successful AIA0001 duration: Slightly under 23 hours.
- Estimated observed framework success rate: Approximately 10%, depending on project goals.
- Estimated main campaign AI spending: Around $5,000.
- Reported affected organizations: Deere, SharkNinja and Cummins, with differing confirmed impacts.
- Observed technical evidence: Agent project histories, exposed dashboards, validation of selected webshell outcomes and exposed secrets.
- Confirmed state sponsorship: None established.
- Universal campaign CVE: None established.
Frequently Asked Questions
Did one hacker really use AI agents to breach more than 100 websites?
Reuters reported over 100 company website intrusions associated with a Chinese-speaking operator using AI agents. NorForge documented the underlying Cairn activity and directly validated selected intrusion outcomes, but not every reported breach was independently examined in the published research.
How many websites did the AI agents target?
The campaign reportedly attempted to compromise more than 1,200 websites. The number of targets is not the same as the number of confirmed successful breaches.
What is Cairn AI?
Cairn is a state-based problem-solving platform that coordinates agent workers through shared findings, objectives and follow-up actions. It can be used for legitimate technical tasks, although NorForge found multiple deployments involved in suspected malicious activity.
Did the attacks really cost only $5,000?
The $5,000 figure is a researcher’s estimate of AI token spending for the principal campaign. It is not a verified bill and does not necessarily include every infrastructure or operational cost.
Were Claude Code and DeepSeek responsible for the campaign?
NorForge observed worker naming that suggested a Claude Code-style harness connected to a DeepSeek model. The complete configuration was not conclusively verified, and the evidence does not establish that either vendor directed the attacks.
Was the Chinese government behind the campaign?
No such attribution has been established. The activity used Chinese-language instructions, but language alone cannot determine nationality or state sponsorship. NorForge found no obvious state-backed activity in the exposed panels.
Did the attackers steal customer data from Deere, SharkNinja and Cummins?
Publicly reported responses do not establish sensitive-data theft at all three organizations. Deere reported no indication of sensitive information access, SharkNinja described a contained incident involving a support site, and Cummins was investigating a potential incident affecting a vendor-operated website.
How can companies defend against autonomous AI-driven attacks?
Reduce vulnerabilities in internet-facing applications, monitor suspicious behavior, protect management interfaces, secure credentials and verify remediation after confirmed compromise. AI-assisted attacks still depend on observable activity and exploitable weaknesses.
Final Takeaway
NorForge’s investigation exposed how a Chinese-speaking operator used Cairn to coordinate long-running intrusion attempts against large numbers of company websites.
Reuters reported more than 100 website intrusions, while the estimated AI cost of the main campaign was approximately $5,000.
The findings do not establish a government-backed operation or prove that every target suffered a successful compromise. They do, however, demonstrate how AI coordination can reduce the manual work required to sustain complex technical attacks.
For defenders, the immediate priorities remain familiar: reduce internet-facing vulnerabilities, protect authentication and management systems, monitor for real compromise and verify that remediation is complete.
AI may change how attackers organize their work, but strong security controls still determine whether an attempted intrusion becomes a successful compromise.
If AI agents can pursue attack objectives for hours, who controls what those agents are allowed to do?
The Cairn investigation reveals the consequences of powerful automation without adequate boundaries. Learn why discovering AI agents is only the first step toward securing them.
Read: AI Agent Security — Why Visibility Alone Won’t Protect You →
