Security researchers just got a rare, accidental look inside a live AI-powered attack operation. On July 30, Palo Alto Networks' Unit 42 published findings on a threat actor who connected DeepSeek to an open-source hacking framework and ran real attacks against 460+ internet-facing systems, most of it triggered by a single Telegram message.
Quick Answer
- A Chinese-speaking actor known as knaithe (aka KnYuan) wired DeepSeek into an open-source agentic framework called Hermes Agent, using it as the "reasoning brain" for autonomous attacks
- The fully autonomous, AI-driven attacks failed against every target they tried
- The same actor's manual, conventional attacks succeeded, compromising three organizations through a real, patchable Citrix vulnerability
- Researchers only found this because the attacker's own tooling accidentally exposed itself on the open internet
- The actor also tested Claude Code and OpenAI Codex, but Western safety controls blocked offensive use DeepSeek and the open-source framework had no such guardrail
How This Was Discovered
Unit 42 didn't find this through a tip or a breach report. Hermes Agent, the framework the attacker was using, accidentally spun up a public web server from its own home directory.
That exposed:
- API keys
- Exploit scripts
- Target lists
- Shell command history
- Full AI attack session logs
That mistake gave researchers a rare, complete view of an AI-driven attack operation while it was still running.
The Attack Stack
- DeepSeek - used as the reasoning engine, generating search queries, evaluating which CVEs to use, and adapting exploit logic on the fly
- Hermes Agent - an open-source agentic framework providing terminal access, tool orchestration, and Model Context Protocol (MCP) integrations
- Three custom offensive skills - a jailbreaking module, a WebSocket exploitation skill, and a FOFA cyberspace-search procedure, wired directly to FOFA's internet asset index via MCP
- "Yolo" mode - lets the agent execute risky commands autonomously, with no operator confirmation required
- Telegram - the actor's remote control channel; one instruction could trigger enumeration, vulnerability selection, exploit downloading, and attack attempts with no further human input
What Actually Worked (And What Didn't)
This is the part worth sitting with: the fully autonomous AI attacks didn't work.
- DeepSeek-led attacks against Langflow and n8n instances failed the exposed systems didn't meet the exploits' configuration requirements
- Across roughly 460 attempted targets, Unit 42 confirmed zero successful compromises from the autonomous workflow
But the same operator's manual, hands-on attacks old-fashioned scanning and exploitation, no AI involved succeeded:
| System | CVE | Outcome |
|---|---|---|
| Citrix NetScaler | CVE-2026-3055 | 3 confirmed compromises, memory exfiltrated |
| Marimo Notebook | CVE-2026-39987 | Command execution on 11 instances |
The Citrix NetScaler compromises are the ones that matter most. The actor extracted memory from the affected appliances and specifically searched it for authentication cookies a clear sign of session-hijacking intent, not just data collection. Unit 42 flagged a suspected session-hijacking attempt against a Malaysian government entity as part of this activity.
The Detail Your Security Team Shouldn't Skip
The actor didn't only use DeepSeek. Logs showed testing of Qwen, GLM, Kimi, and MiniMax, plus limited trials of Claude Code and OpenAI's Codex.
- The Western tools were used rarely, and Unit 42's reporting lines up with a simple explanation: built-in safety controls got in the way of offensive use
- DeepSeek, running inside an open-source framework with no equivalent guardrail, didn't have that problem
That gap not the specific CVEs is the real story for anyone building or securing AI-agent infrastructure. Provider-side safety training only helps if your stack is actually using a provider that enforces it.
What to Do This Week
- Patch Citrix NetScaler now. Check appliance configuration for add authentication samlIdPProfile .* and install Citrix's fixed builds for CVE-2026-3055 if your ADC or Gateway is configured as a SAML identity provider
- Audit internet-facing Langflow, n8n, Marimo, and Tomcat instances. These were all active exploit targets in this campaign, whether or not the AI-led attempts succeeded
- Inventory any AI agent framework running in an unattended or "autonomous" mode inside your own environment, and confirm it can't reach the open internet, execute shell commands, or hold API keys without review
- Don't treat "the autonomous attack failed" as reassurance. Unit 42's own conclusion was blunt: the workflow proved a functional, end-to-end autonomous offensive capability, even with limited real-world impact so far
- Review MCP server permissions on any internal AI tooling. This attacker used an MCP connection to hand an LLM direct access to an internet-wide asset index the same integration pattern legitimate teams use for productivity is exactly what made this attack chain possible
The Honest Verdict
This wasn't an AI apocalypse story, and it wasn't nothing either. The autonomous attacks failed every single time they were tried. But the same actor, same day, same target list, succeeded the old-fashioned way and the AI layer clearly sped up reconnaissance and target selection even where it couldn't finish the job. The gap between "AI-led attacks don't work yet" and "AI-led attacks don't work reliably yet" is not a gap security teams should plan around.
Sources & References
- Unit 42 (Palo Alto Networks), original research report: unit42.paloaltonetworks.com
- The Hacker News, on the Telegram-directed attack chain and CVE breakdown: thehackernews.com
- BleepingComputer, on the discovery and actor attribution: bleepingcomputer.com
- GBHackers, on the Hermes Agent tool stack and MCP integration: gbhackers.com
- Infosecurity Magazine, quoting Unit 42's Andy Piazza: infosecurity-magazine.com
This article is written for general security awareness and does not include exploit code, working payloads, or step-by-step reproduction details. If you manage Citrix NetScaler, Langflow, n8n, Marimo, or Apache Tomcat infrastructure, consult your vendor's official security bulletins directly before making configuration changes.