Executive Summary
A Palo Alto Networks Unit 42 investigation published in August 2026 documented the first confirmed attribution of a fully autonomous AI attack campaign to a named threat cluster. The actor, tracked internally as knaithe and overlapping with prior activity under the identifier KnYuan, is a Chinese-speaking group assessed to operate from or through infrastructure associated with the Zhuhai region of China.
Over approximately six weeks, knaithe ran a sustained exploitation campaign against more than 460 targets using an architecture built around DeepSeek as a reasoning backbone and Hermes Agent — a Telegram-integrated open-source agentic framework — as the orchestration layer. The campaign was not especially destructive in outcome: three of the 460+ targeted organisations yielded confirmed access. The significance is operational. knaithe reduced their own role to reviewing results and adjusting the target queue, while the AI system handled reconnaissance, exploit selection, session initiation, and persistence attempts without per-step human instruction. This is the transition from AI-assisted to AI-directed attack operations, confirmed against a real-world campaign with attribution.
The campaign’s exposure came through an operational security failure rather than defensive detection: the actor accidentally ran an unprotected Python HTTP server on their staging infrastructure, exposing tool manifests, configuration files, and Chinese-language operational notes to Unit 42 researchers.
Threat Actor Profile
Identity and Prior Activity
Unit 42 tracks this actor under two overlapping identifiers. knaithe is the designation applied to the autonomous AI campaign described in this report. KnYuan is a prior identifier assigned to what Unit 42 assessed as opportunistic scanning activity originating from Zhuhai-registered ASN space — the same autonomous system number infrastructure that anchors attribution in this campaign.
KnYuan’s prior record is consistent with a financially-motivated or intelligence-collection actor conducting broad reconnaissance of internet-facing infrastructure. Their historical activity involved scanning for known CVEs at scale, consistent with either preparation for exploitation or data gathering for sale to initial access brokers. Unit 42’s pre-campaign assessment did not classify KnYuan as a sophisticated actor — their scanning methodology was opportunistic rather than targeted, and there was no documented history of successful post-exploitation activity prior to this campaign.
The transition to AI-orchestrated operations represents either a significant capability uplift or the emergence of a more capable operator using existing infrastructure that KnYuan had already built. The Unit 42 report does not conclude which interpretation is more likely.
Attribution Confidence
Attribution to a Chinese-speaking actor is assessed with moderate-to-high confidence, grounded in three independent lines of evidence:
- Infrastructure correlation: The campaign’s staging server shared ASN space with KnYuan-attributed prior activity, originating from Zhuhai-registered infrastructure.
- Artefact language: Operational notes recovered from the exposed staging server are written in Simplified Chinese, consistent with a Mainland China operator.
- Tool configuration: The Telegram bot configuration file contained references to a Chinese-language operator interface, and API endpoint configuration pointed to DeepSeek’s commercial API — a PRC-based AI service.
Unit 42 explicitly stops short of attributing knaithe to a specific PRC state organisation. The available evidence establishes a Chinese-speaking, China-based actor, but does not distinguish between a state-directed operation, a state-tolerated contractor, or an independently operating criminal group. The targeting pattern — broad reconnaissance across AI-native infrastructure, no apparent sector-specific focus — is more consistent with opportunistic access broker activity than with the narrow intelligence collection priorities typical of PRC APT groups. This may change as the Unit 42 investigation progresses.
TTPs and Tradecraft
Agentic Attack Architecture
The technical architecture of the knaithe campaign is the most consequential element of this report for defenders and threat intelligence practitioners. The actor assembled three components into a functioning autonomous attack pipeline:
DeepSeek: Used as the reasoning backbone. DeepSeek’s API was called to process reconnaissance data, evaluate which exploits from the toolkit were applicable to a target’s observed attack surface, and plan multi-step exploitation chains. The actor chose DeepSeek over Western LLM alternatives, likely for a combination of cost (DeepSeek’s API pricing is significantly lower than comparable capability from Anthropic or OpenAI) and reduced risk of API access being flagged or suspended.
Hermes Agent: An open-source agentic framework with native Telegram integration. Hermes Agent wraps LLM API calls with tool use capabilities — allowing the model to invoke tools (exploitation scripts, reconnaissance commands, session management utilities) based on its reasoning rather than requiring the operator to select them manually. Hermes Agent’s Telegram interface was used as the operator console: successful access events appeared as notifications in the operator’s Telegram interface, and the operator could adjust the target queue or review results from a mobile device.
Target queue and toolkit: Targets were fed into the system as a structured queue with IP addresses, observed services, and pre-gathered reconnaissance data. The exploit toolkit was curated — the actor selected four CVE classes rather than deploying a broad scanner. Hermes Agent selected from this toolkit based on DeepSeek’s analysis of each target’s attack surface.
The result was an attack pipeline that the operator could initiate, leave running for hours, and return to review results. Unit 42 estimates the operator engaged with the system primarily to review successful access events and reprioritise the target queue — not to direct individual exploitation attempts.
Exploit Toolkit
knaithe targeted four vulnerability classes, all affecting internet-facing infrastructure commonly deployed by organisations running AI workflows or data tooling:
CVE-2026-33017 — Langflow Remote Code Execution: The primary initial access vector. Langflow is a visual AI workflow builder that sits directly at the intersection of internet exposure and AI-native organisations. CVE-2026-33017 is a pre-authentication RCE affecting Langflow versions prior to 1.9.0. Langflow instances are frequently deployed without authentication for internal use cases, then left internet-exposed. The exploit is reliable and the target population is large.
CVE-2026-21858 + CVE-2025-68613 — n8n Authentication Bypass and RCE Chain: A two-vulnerability chain against n8n, the workflow automation platform used widely by organisations building agentic applications. CVE-2026-21858 provides an authentication bypass; CVE-2025-68613 leverages that position to achieve remote code execution. n8n instances, like Langflow, are frequently internet-facing by design and lag on patching because they are perceived as internal tooling rather than production web infrastructure.
CVE-2026-39987 — Marimo Remote Code Execution: Marimo is a reactive Python notebook environment popular with data science teams. CVE-2026-39987, patched in version 0.23.0, allows RCE against Marimo notebook servers. This target selection is notable: Marimo is a specialist tool with a relatively small user base, which suggests the actor specifically profiled targets running AI or data science infrastructure rather than conducting purely opportunistic mass scanning.
CVE-2026-3055 — NetScaler SAML Authentication Bypass: The one non-AI-native vector in the toolkit. CVE-2026-3055 affects Citrix NetScaler gateways, which are commonly deployed as authentication fronts for corporate applications. Compromising a NetScaler gateway provides direct network access to internal resources — including AI tooling that would otherwise be unexposed. This vector allows knaithe to reach internal-only Langflow, n8n, or Marimo deployments that are not directly internet-accessible.
Operational Pattern
Unit 42’s reconstruction of the campaign timeline suggests the operator ran exploitation sessions for several hours at a time, reviewing outcomes asynchronously via Telegram. The agent’s autonomy was not unlimited — the actor intervened when the agent stalled on non-standard target configurations — but the day-to-day execution was AI-directed.
The targeting pattern reveals a curated rather than indiscriminate approach. The 460+ target queue was assembled through prior reconnaissance, not real-time internet scanning. The actor selected targets based on observed services consistent with the toolkit’s CVE coverage. This level of target profiling suggests either significant pre-campaign manual reconnaissance or use of a third-party scanning service to identify vulnerable instances.
Targeting and Victim Sectors
The victim profile is determined primarily by which software the toolkit targeted. Organisations running Langflow, n8n, Marimo, or internet-facing NetScaler gateways in combination with AI workflow tooling were the primary population.
This creates a distinctive victim profile that skews toward:
- Technology companies and startups using AI workflow automation for product development
- Data science and analytics teams in financial services, research, and enterprise technology
- AI-native organisations whose core product involves LLM orchestration or data pipeline automation
- Enterprise organisations using Citrix NetScaler for remote access combined with internal AI tooling
Three of the 460+ attempted targets yielded confirmed access. The low conversion rate — under 1% — likely reflects a combination of factors: patch coverage in the target population, targets where the toolkit’s exploits were applicable but the target was not running a vulnerable version, and cases where the agent’s automated exploitation chain failed to adapt to non-standard configurations. Whether the three successful compromises resulted in further post-exploitation activity is not confirmed in Unit 42’s disclosure.
Historical Activity and Campaign Timeline
Prior KnYuan Activity
Before the autonomous AI campaign, KnYuan’s documented activity was limited to opportunistic scanning from Zhuhai-registered ASN space. Unit 42 had previously observed the group conducting reconnaissance against internet-facing infrastructure without confirmed successful exploitation. The prior activity profile is consistent with a low-capability actor that scanned broadly but lacked the post-exploitation tools or tradecraft to convert reconnaissance into access reliably.
The shift to AI-orchestrated operations is a capability step that the available evidence does not fully explain. The Hermes Agent toolkit is publicly available — any actor with technical capability to configure it can access it. DeepSeek’s API is commercially available. The curated exploit toolkit represents the highest barrier to entry, but four CVE-class exploits is a modest toolkit requirement. The most plausible explanation is that the actor either acquired new technical capability within their operation or began working with a more skilled collaborator.
Campaign Timeline
The Unit 42 investigation reconstructs a campaign that ran for approximately six weeks before the operational security failure that exposed the infrastructure. The exposure event — the Python HTTP server on port 8888 — appears to have occurred during an active campaign run rather than during setup or maintenance, suggesting the actor was actively operating when they made the error.
The six-week campaign timeline with a 460-target queue implies a deliberate pace. If the agent processed multiple targets per day, the queue may have been periodically replenished rather than being a static list assembled at campaign start. This pacing is more consistent with an actor testing and refining the approach than with one attempting maximum-scale exploitation.
Defensive Implications
Patch Priorities
The immediate defensive action from this campaign is straightforward: organisations running affected software should verify they are on patched versions:
- Langflow: 1.9.0 or later (fixes CVE-2026-33017)
- n8n: 1.121.1 or later (fixes CVE-2026-21858 and CVE-2025-68613)
- Marimo: 0.23.0 or later (fixes CVE-2026-39987)
- Citrix NetScaler: Apply vendor patches for CVE-2026-3055
Exposure Reduction
The broader defensive lesson from knaithe’s target selection is that AI-native tooling is now a confirmed exploitation target class. Langflow, n8n, and Marimo are frequently deployed with less operational discipline than production web infrastructure. They are often internet-exposed because that is operationally convenient, and they lag on patching because developers treat them as internal tools.
Organisations should audit which AI workflow tools in their environment are reachable from the public internet. Exposure that was accepted as low-risk before this campaign needs to be re-evaluated against the demonstrated targeting by automated exploitation systems.
What the AI Architecture Changes for Detection
The most important defensive implication of the knaithe campaign is not the specific exploits used but the operational architecture they were embedded in. An AI-orchestrated attack pipeline changes the detection problem in two specific ways:
Speed: An autonomous agent processing targets continuously operates faster than a human-directed campaign. Reconnaissance, exploit selection, and initial exploitation can occur within a compressed window that traditional detection timelines are not calibrated for.
Consistency: AI-orchestrated campaigns are more consistent than human-operated ones. The exploit sequences are predictable, the reconnaissance patterns follow the agent’s configured workflow, and the HTTP request patterns may be more uniform than a human operator varying their approach. This consistency, paradoxically, may make AI-orchestrated campaigns easier to detect via behavioral baselining than adaptive human operators.
Operational Security Failures as Detection Opportunities
The exposure mechanism in this campaign — an open Python HTTP server on the staging infrastructure — is operationally simple but representative of a meaningful class of detection opportunity. Threat actors deploying commodity agentic tooling are adopting the same operational convenience that the tooling is designed to provide. That convenience often means less disciplined operational security.
Scanning for open directories and exposed infrastructure associated with Hermes Agent deployments, Telegram bot configuration files, and LLM API key references in accessible directories represents a legitimate threat intelligence collection opportunity. The actor’s self-exposure was not caught by victim-side detection — it was found by Unit 42 scanning the internet for exposed attack infrastructure. Expanding that collection posture to cover commodity agentic attack tooling is a reasonable response to this campaign.
Significance and Forward Assessment
The knaithe/KnYuan campaign is important not because of its operational impact — three confirmed compromises is a modest result — but because of what it confirms about the trajectory of threat actor capability adoption.
AI-directed attack operations were a theoretical concern six months ago. They are now confirmed in attribution. The barrier to entry is low: Hermes Agent is open-source, DeepSeek is commercially available, and a curated exploit toolkit for AI-native infrastructure can be assembled from public CVE databases. The operator’s required skill level for this campaign was primarily in initial setup and target curation, not in the exploitation itself.
The bottleneck the knaithe campaign reveals is target curation: the actor’s 460-target queue and six-week timeline suggest the limitation is not the AI’s capability to exploit but the operator’s ability to identify and prioritise vulnerable targets. That bottleneck is addressable with better integration of internet scanning data. As that integration matures, the campaign scale changes considerably.
Unit 42 has committed to publishing further findings. What this report already establishes is enough to warrant an updated threat model for any organisation deploying AI workflow infrastructure.