The AI agent picked the vulnerability and attempted the exploit on its own. The successful breaches were manual
7 min read
On 30 July 2026 Unit 42, Palo Alto Networks’ threat intelligence arm, published a report by Andy Piazza documenting an attack cycle carried out by an artificial intelligence: it enumerates targets, picks a vulnerability, downloads the exploit and attempts exploitation without an operator stepping in at each turn. Verbatim title: “Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks.”
Who, with what, commanded how
The actor, Chinese-speaking, operates under the aliases knaithe and KnYuan. Unit 42 places them in Zhuhai, China, based on their public GitHub activity — specifically 1DayNews, a pipeline that aggregates vulnerability disclosures from 17 sources, filters them with DeepSeek and distributes alerts via Telegram. The report describes them as an “opportunistic exploit operator and self-described binary security researcher.”
For the offensive campaign they used DeepSeek as the reasoning engine, orchestrated through the open-source Hermes Agent framework by NousResearch: terminal access, Telegram-based command and control, and custom “skills” — including godmode, for LLM jailbreaking, already bundled with the framework. Rounding out the setup was an open-source server (FofaMap) linked to FOFA, the internet asset-enumeration platform, with a natural-language-to-FOFA query translator. The actor also tested Claude Code and Codex in a limited way, but only for connectivity or proxy checks, never as the attack engine — “consistent with evaluating the AI-market to identify their preferred tool set,” per Unit 42.
What the AI did on its own — and where it stopped
From a single recovered session, dated 7 May 2026 (Unit 42 notes it was unable to recover any further operator input beyond the initial task), the report reconstructs the cycle step by step. DeepSeek downloaded a public exploit from GitHub for CVE-2026-33017 (Langflow, CVSS 9.8), enumerated 84 instances via FOFA and found one vulnerable target — but the attack never launched: a configuration prerequisite was missing. The model wrote it out itself: “All three Langflow need public flow ID but no auto_login — stuck. […] Search for larger-scale vulns.” Unprompted, it then went looking for a more promising target: a survey of ten product families, a GitHub search for the most-starred PoCs, and a choice of n8n — “looks extremely promising!” — with FOFA confirming 647,017 instances worldwide, 25,209 in China. It chained two CVEs (CVE-2026-21858, arbitrary file read, CVSS 10.0, and CVE-2025-68613, sandbox bypass to remote code execution, CVSS 9.9), sampled roughly a hundred Chinese IPs, found three vulnerable targets — and stopped again: the forms required authentication the exploit didn’t account for. “These forms have auth enabled. Let me check other targets,” it wrote, before scanning fifty more targets with no result.
This is a distinction the report itself keeps separate, and it’s worth keeping separate here too: the successful attacks — data exfiltration from three organisations via Citrix NetScaler (CVE-2026-3055, CVSS 9.8), command execution on 11 Marimo Notebook instances (CVE-2026-39987), attempted reverse shells against 9 Apache Tomcat servers and 3 IKE VPN endpoints — are logged as a manual campaign, using “conventional workflows,” not as the autonomous agent’s output. Among the manual targets, a Malaysian government entity hit “over multiple days with memory grooming parameters.” In all, across autonomous and manual techniques, the actor attempted to hit over 460 targets — and Unit 42 further warns of evidence of exploitation against an unspecified number of additional hosts, listed in a file the actor deleted before analysis: the confirmed figures are a floor, not a ceiling.
On the conclusion, Unit 42 is unambiguous: “Although these autonomous campaigns did not achieve full compromise of any of their intended targets” — the autonomous cycle breached nothing, in the observed session — “the margin of failure was narrow”: what stopped it was target-side configuration prerequisites, not a limit of the model. “Targets with weaker default configurations would have been susceptible.” The capability was fully functional end to end; the target, for once, was configured better than the attacker.
The most permissive model, and the one that held
On why the choice fell on DeepSeek, Unit 42 stays in the register of assessment, not established fact: “the actor selected a model with minimal safety controls (DeepSeek) accessed through an open-source framework with no client-side restrictions. The actor attempted to use Western models, but their provider-side controls likely limited their effectiveness for autonomous attacks. This likely led the actor to select the most permissive model for their campaign.”
On the other side, the part that completes the picture and shouldn’t be left out: “Our colleagues at OpenAI were able to confirm that their provider-side safeguards refused requests that violated their policies. They also confirmed that continued attempts led their safety systems to flag and disable an account they believe is linked to this campaign prior to our intelligence sharing with their team.”
Two vendors, two opposite outcomes, on the same intent. It’s the lesson we isolated in the lab a week ago, when CAISI measured GLM-5.2: near-total refusals on a direct chat request, zero out of ten on the same request broken into an agentic task. This is no longer a government test bench: it’s a real actor who picked the tool based on which one would offer the least resistance. Safeguards are not a property of a model’s weights: they are a layer of the system that runs it. A model reached via API carries the vendor’s layer with it — here it worked, it refused, and it got an account disabled. But that layer sits in the stack you assemble, not in the model: here the access route was the vendor’s own API — Unit 42’s table records “Direct API: api.deepseek[.]com” — and what was missing was the framework’s layer, “no built-in safety layer”, with a godmode jailbreaking skill available on top. Whoever puts model, framework and tools together builds that layer, or simply doesn’t have one. It cuts both ways: it’s what let this actor pick the most permissive model, and it’s what lets a serious organisation build its own controls — verifiable, logged — instead of depending on a vendor’s, which can change with an update you never see coming. It also remains a different measure from capability: the figures on Langflow and n8n say how much the agent can do; “no built-in safety layer” says how free it was left to do it — conflating the two is the mistake a procurement specification must rule out from the start.
What to do about it
- If you’re assessing an open-weight model for a use case with tools in hand, don’t stop at the vendor’s data sheet: check what happens when the task is broken into steps, not posed as a direct question.
- Treat FOFA, Shodan and other asset-enumeration engines as the surface an automated attacker will use first: knowing what’s visible from outside before an agent finds it is the difference between 84 instances found and zero.
- Document in writing what protection accompanies every model put into service — factory-set or built by you — before an overly permissive default becomes the door an agent opens on its own.
How we solve this
The control missing from the attacker’s side — supplied by the vendor in OpenAI’s case, by no one in DeepSeek/Hermes Agent’s — is what we test for our clients: a security layer measured in agentic configuration, not in chat, that runs before any model or agent goes live and on a set cadence afterwards, with the record to show an inspector. It already applies today to anyone inside Italy’s national cybersecurity perimeter: the decree listing the ICT categories subject to CVCN evaluation already includes AI/ML systems for network and system management; for everyone else, Italy’s NIS2 transposition (D.lgs. 138/2024) still requires a documented assessment of suppliers.
The same setup brings the organisation’s scattered data — archives, business systems, sensors, logs — into a single operating model, on which AI agents execute technical tasks with a human operator in command, at exactly the point this report shows to be most fragile: not the request, the execution. It applies to the Chinese open-weight models more and more Italian companies are assessing just as much as to American or European ones: where a model comes from matters less than who controls that point. For large enterprises, defence, government and healthcare, we do it in both delivery modes — on-premise on the client’s self-contained machines or on a dedicated cloud with a data centre in Italy — with governance run together with you, so you don’t need to already have in-house staff to administer these systems.
About to put an agent with tools in hand — not a chatbot — into production, built on an open-weight model? Let’s talk in a thirty-minute session: we test the protection layer in your real configuration, in agentic mode, before someone else does it in your place.