Attackers using Cairn to automate website break-ins left their own control panels open to the internet. NorForge’s October 19 investigation found more than 20 exposed panels it assessed as likely malicious—and checked that some reported successes were real, including an uploader webshell on a hardware vendor’s site. The same dashboards exposed credentials and information about targets, creating another route to sensitive data even where an attack had not succeeded.[1]
The revealing part is the view into the work: agents shared discoveries, changed direction when attempts failed, and sometimes found a small configuration difference that turned an ordinary upload into server access. Their operators could automate the attack pipeline while still neglecting the door to its control room.
A shopping list became a shared investigation
Cairn organizes work into projects with a starting point and a goal. Workers record what they discover on a shared blackboard and decide what to try next; a human can add hints there too. This lets later workers use earlier findings rather than restart the investigation. A project graph records the branches, including paths that did not work.
NorForge’s largest cluster, labeled AIA0001, had more than 1,100 projects across 14 associated dashboards. Its tasking selected shopping sites by traffic and said browser automation had already checked that orders could be placed. The intended destination was persistent access to e-commerce or payment infrastructure. Those project numbers count tasks, not independently confirmed breached businesses.
A small mistake helped connect the infrastructure: site names on multiple panels were missing an initial “w.” NorForge interpreted the repeated error as a faulty address-cleaning step in a common feeding pipeline. The attackers’ automation was leaving a recognizable fingerprint before the agents even started.
The uploader was real; the explanation had a different evidentiary status
One completed task claimed to have installed an uploader on a large hardware-parts vendor’s website. NorForge requested the reported URL and found the upload form there. This was a concrete check beyond trusting a success label in an AI-generated record.
An uploader provides a way to put additional files on a server. Its simple appearance does not establish what else an intruder has done or which privileges they hold. In this case, the agent described a chain involving unauthorized writes to a memcached session store, unsafe PHP object deserialization and older Zend Framework components. That explanation came from the agent’s account; NorForge’s direct check established that the uploader was being served. These are different levels of evidence.
The distinction matters for defenders. A patch can close an entry point while a previously installed webshell remains available. Our StyleSmuggler coverage explains that patch-versus-backdoor boundary in another e-commerce case. Finding an unexpected upload should trigger investigation of access and persistence, rather than end with updating one component.
One backend made an uploaded file executable
Another case in the report shows why an application can behave safely in one request and dangerously in another. NorForge says it validated a chain at a very large US retailer in which an unauthenticated upload accepted a file that combined an image signature with PHP code. The file was stored in a web-accessible location.
The decisive detail was routing. A cookie selected among backend servers, and only one backend executed the uploaded file as PHP. Others returned its contents instead. The agent found the setting that reached the vulnerable server, turning an inconsistent configuration into command execution under the web-server account.
This is a useful operational lesson, not a claim that every upload form is vulnerable. Reviewing only one node behind a load balancer can miss a different execution policy on another. Site operators investigating a suspected intrusion should examine uploaded files, request logs and backend configuration together, preserving evidence before cleanup. Successful command execution under a web-server identity also does not automatically mean root access.
Failed projects could still expose working secrets
The open panels held more than attack results. They contained findings, target details and human instructions with credentials already gathered elsewhere. NorForge reported hundreds of secrets in the collected data, with 11% verified as valid by its scanning tool. That percentage concerns the secrets the tool checked; it is not a proportion of all victims or proof that every credential was used.
The researchers also encountered apparently legitimate testing operations with exposed panels. A customer does not need to suffer a successful exploit for this to become a security incident: a tester’s notes can disclose a working key or password. The separate AgentCore memory experiment illustrates why an agent’s working context can itself become sensitive material.
For teams commissioning or running AI-assisted assessments, the immediate question is who can read project records and where secrets are retained. Restrict the dashboard, review access and copies, and revoke credentials that were exposed. Closing the panel stops that access path; it does not invalidate a key someone already copied.
What the success figures actually tell us
NorForge estimated that roughly one in ten observed tasks reached its goal, while successful projects in the largest cluster averaged a little under 23 hours from start to goal. Different operators set different goals, so those figures are not a universal AI hacking success rate. Nor do they turn all completed projects into separately verified breaches.
The stronger finding is the concrete combination: autonomous workers could pursue real access, and the systems coordinating them could leak the collected evidence and secrets. Shop owners need to investigate server-side artifacts; assessment providers need to protect the records their agents create. The control room is part of the attack surface.
References
- Fagerland, S. Inside Cairn: Open Windows into massive AI-Driven Cyber Operations. NorForge, October 19, 2026. Accessed October 20, 2026.
