Google Cancels AI Studio App for Gemini

A Chinese-speaking threat actor built a working, largely autonomous AI cyberattack pipeline — and got caught because the AI agent accidentally exposed its own operator’s files to the internet. Palo Alto Networks’ Unit 42 published the findings this week: an operator tracked as “knaithe” (also “KnYuan”) wired DeepSeek into the open-source Hermes Agent framework and directed it, largely hands-off, against more than 460 internet-facing targets.

Quick facts

• Unit 42 attributes the campaign to a China-based actor known as “knaithe” / “KnYuan,” assessed to be operating from Zhuhai, China.
• DeepSeek served as the “reasoning” engine inside the Hermes Agent framework, targeting more than 460 systems across seven exploit paths and eight CVEs.
• Confirmed impact: data exfiltration from three organizations via a Citrix NetScaler flaw (CVE-2026-3055) and command execution on 11 Marimo notebook instances (CVE-2026-39987).
• The operation was discovered only because Hermes Agent accidentally launched a public web server from its own working directory, exposing the operator’s tools and logs.
• OpenAI’s server-side safeguards reportedly flagged and disabled an account linked to the campaign before Unit 42 even shared its findings — DeepSeek’s model-only guardrails did not.

How the attack worked

According to Unit 42’s report, the operator gave Hermes Agent instructions over Telegram, and the agent handled the rest with little further input: enumerating internet-facing targets, evaluating which CVEs applied, sourcing public exploit code, and adapting its approach when an attempt failed. DeepSeek acted as the decision-making layer behind that process, while Hermes supplied terminal access and tool orchestration through the Model Context Protocol. In parallel, Unit 42 found the same operator had configured — but rarely used — other models including Qwen, GLM, Kimi, MiniMax, Claude Code, and OpenAI’s Codex, suggesting an ongoing evaluation of which AI systems would actually cooperate with offensive tasks.

Most of the autonomous attempts failed outright — target systems weren’t actually vulnerable, or didn’t match the exploit’s assumptions. But Unit 42 confirmed real impact in a handful of cases: memory read access and exfiltration from three organizations through a Citrix NetScaler vulnerability, and command execution against 11 exposed Marimo notebook instances. One of the Citrix compromises appears to have targeted a Malaysian government entity.

The detail that actually matters: guardrails that catch misuse vs. guardrails that don’t

The most consequential finding in the report isn’t the attack itself — it’s what separated the AI providers the operator tried to use. Unit 42 says OpenAI’s own safety systems detected and disabled an account connected to this campaign on their own, flagging misuse patterns over time and revoking access before Unit 42 had even disclosed anything. DeepSeek, whose safeguards live primarily in the model itself rather than in server-side monitoring, didn’t catch the same behavior — which is part of why the operator settled on it as the primary tool.

That’s a specific, testable distinction for anyone thinking about AI agent safety: a model-only guardrail can potentially be prompted around, and once it’s bypassed there’s no account, no usage pattern, and no audit trail for anyone to catch. A server-side system that watches behavior over time can catch exactly the kind of persistent, repeated misuse this campaign involved — even without inspecting any single request in isolation.

What defenders should actually do

If you run any of the affected systems, the practical response is ordinary patch hygiene, not panic: Citrix has confirmed CVE-2026-3055 affects customer-managed NetScaler ADC and Gateway appliances configured as SAML identity providers, and has published fixed builds. Unit 42’s report also lists Apache Tomcat (CVE-2026-34486), Marimo Notebook (CVE-2026-39987), and Windows IKE VPN (CVE-2026-33824) among the exploit paths the operator used or attempted. None of these are novel zero-days — they’re known, patchable vulnerabilities that an AI agent turned out to be quite good at finding unpatched instances of at scale.

What is Hermes Agent, and who is “knaithe”?

Hermes Agent is an open-source AI agent framework that gives a language model terminal access, task orchestration, and the ability to call external tools through the Model Context Protocol — the same kind of plumbing legitimate developer tools use to let an AI agent actually take actions instead of just generating text. That’s precisely why it made a capable offensive tool once someone pointed it at attack tasks instead of coding tasks: the underlying capability is neutral, and the operator supplied the malicious intent, targeting, and offensive skills on top of it.

Unit 42 attributes the campaign to a persona going by “knaithe” and “KnYuan,” who describes themselves as a “binary security researcher” and is assessed to be operating out of Zhuhai, China, based on publicly available data. The attribution came directly from the operator’s own exposed environment — the accidental web server leaked API keys, exploit scripts, target lists, shell history, and the AI system’s own attack logs, giving researchers an unusually complete view into how the operation was actually run.

Why this is a bigger deal than one failed campaign

Taken on its own, this campaign was a limited success for the attacker — three confirmed compromises out of 460+ attempts. But Unit 42’s own framing is the one worth sitting with: the workflow confirms a functional, end-to-end autonomous offensive capability exists today, running on a widely available open-weight model, orchestrated over a consumer chat app. That’s a different threat model than a skilled human operator working exploits by hand, and it lands the same week regulators in the EU and California began enforcing new AI transparency rules — a reminder that transparency requirements and safety guardrails are solving related but distinct problems.

Key takeaway

An open-weight model with only in-model safeguards was, by Unit 42’s own account, the deciding factor in why this campaign ran on DeepSeek instead of a frontier lab’s model with server-side monitoring. For anyone building or deploying AI agents, that’s the operational lesson: guardrails that only live inside the model are a weaker line of defense than systems that can watch behavior over time and revoke access.