DeepSeek AI Agent Automates Real Cyberattack Attempts

A Chinese-speaking threat actor used DeepSeek and an open-source AI agent to research vulnerabilities, discover exposed servers and attempt attacks with limited human involvement, according to an investigation published by Palo Alto Networks Unit 42.

The autonomous attempts described by the researchers did not successfully compromise their intended Langflow or n8n targets. Authentication requirements and missing configuration conditions stopped the attacks.

That detail matters because this was not a case of an AI independently breaking into dozens of organisations. But dismissing the operation simply because the final exploits failed would also miss what actually changed.

After receiving an initial task, the agent carried out much of the work normally performed by a human attacker. It searched for vulnerabilities, downloaded public proof-of-concept code, identified internet-facing systems, checked whether the required conditions existed and moved to another target when the first attack path did not work.

The operation offers one of the clearest examples so far of how attackers can connect a language model to real tools and turn it into an active participant in a cyberattack workflow.

An operational mistake exposed the attacker’s AI setup

Unit 42 linked the activity to a Chinese-speaking actor using the names “knaithe” and “KnYuan.”

The actor had connected DeepSeek to Hermes Agent, an open-source framework capable of interacting with terminals, accessing the internet, loading reusable skills and receiving instructions through Telegram.

The setup was uncovered because the agent made a mistake.

After receiving a Telegram command, Hermes launched a Python web server from the attacker’s home directory rather than from an isolated folder intended for sharing files.

That exposed parts of the attacker’s working environment, including API keys, target lists, exploit scripts, shell histories, configuration files and logs from an autonomous attack session.

The mistake gave Unit 42 a rare view into how an AI-assisted offensive system was configured and used outside a controlled laboratory.

Researchers also found configurations for several other AI coding tools and models, including Qwen, GLM, Kimi, MiniMax, Claude Code and OpenAI Codex.

However, DeepSeek operating through Hermes appeared to be the primary system used during the autonomous attack sequence that Unit 42 reconstructed.

Evidence level

The activity should be classified as confirmed threat-actor use of an AI agent, with documented but unsuccessful autonomous exploitation attempts.

The researchers recovered logs showing the agent independently performing vulnerability research, target discovery, exploit acquisition and attack testing.

However, Unit 42 did not find evidence that the recovered autonomous sequence successfully compromised the Langflow or n8n systems it targeted.

The same actor was linked to successful attacks against Citrix NetScaler and exposed Marimo systems, but Unit 42 attributed those compromises to the actor’s conventional manual activity rather than to the autonomous DeepSeek-Hermes session.

That distinction is essential.

The report demonstrates that an attacker built and operated an autonomous offensive workflow. It does not prove that the AI independently completed a successful end-to-end intrusion.

How the attack system worked

The underlying architecture was not unusually complex.

The attacker combined several tools that are already available to developers, researchers and security professionals:

DeepSeek provided the reasoning and code-generation layer.
Hermes Agent managed tasks and interacted with the operating system.
Telegram was used to send commands.
FOFA was used to search for internet-facing systems.
Model Context Protocol integrations connected the agent to additional tools.
Public vulnerability information and exploit code supplied the technical attack material.
A local terminal allowed the agent to run commands and scanners.

The workflow can be simplified as:

Attacker instruction
→ Hermes Agent
→ DeepSeek reasoning
→ Vulnerability research
→ Internet asset discovery
→ Exploit execution
→ Target system

The model was therefore not limited to suggesting commands in a chat window.

It could reason about what to do next and then use external tools to act on that decision.

The attacker had also configured some tools to bypass normal confirmation prompts. Unit 42 found settings that permitted commands to run without repeated human approval.

This is where an AI assistant starts becoming an operational agent.

A chatbot that explains a vulnerability is useful. A system that can identify targets, download exploit code and execute commands against those targets creates a very different level of risk.

The first target: Langflow

The recovered autonomous session began with the agent investigating CVE-2026-33017, a critical vulnerability affecting Langflow.

The agent downloaded public proof-of-concept code and used FOFA to search for exposed Langflow systems.

According to Unit 42, it identified 84 internet-facing instances and tested them to determine whether they appeared vulnerable.

One system was running a potentially affected version, but the exploit required additional conditions. Either automatic login needed to be enabled or a public flow identifier had to be exposed.

The agent could not find those conditions on the systems it tested.

The attack therefore failed.

What happened next is more interesting than the failure itself.

The agent did not stop and wait for the operator to provide another target. It began searching for a different opportunity.

The agent selected a new target by itself

After abandoning the Langflow attack path, the agent compared several product families and searched GitHub for recently published vulnerability proofs of concept.

It assessed potential targets based on factors such as severity, apparent deployment numbers and the availability of exploit code.

The agent then selected n8n, a widely used workflow-automation platform.

FOFA results showed a far larger number of internet-visible n8n systems, giving the agent a broader target pool.

It downloaded public exploit code that chained two vulnerabilities:

CVE-2026-21858, involving arbitrary file reading
CVE-2025-68613, involving a sandbox bypass that could lead to remote code execution

The agent checked affected versions, searched for exposed n8n instances and tested whether the required attack conditions were present.

The exploit chain depended on finding an unauthenticated form that allowed file uploads.

The forms discovered by the agent required authentication.

Once again, the attack failed.

But the system had already completed vulnerability research, product selection, target discovery, exploit acquisition and prerequisite testing without visible human guidance after the initial instruction.

The bigger story is not whether the exploit succeeded

It would be easy to look at this campaign, notice that the autonomous attacks failed and conclude that AI-driven hacking remains more demonstration than threat.

That would be too simplistic.

The agent failed because the real target environments did not match the assumptions in the available exploit code. Authentication was enabled, required configurations were absent and the necessary attack conditions were not exposed.

But the system still completed a large part of the attacker’s workload.

It searched for public exploits, identified potential victims, checked versions, tested prerequisites, rejected unsuitable targets and moved to a new vulnerability.

The agent was not behaving like an elite exploit developer capable of discovering previously unknown vulnerabilities.

It was behaving more like a persistent junior operator that could research, test and repeat tasks without becoming tired or losing focus.

That alone can change the economics of opportunistic attacks.

An attacker does not need the AI to complete every compromise independently. The system only needs to reduce the amount of manual work required to find promising targets.

A human operator can step in when the agent identifies a system with the right conditions.

Existing weaknesses become easier to exploit repeatedly

The operation did not rely on an AI-discovered zero-day.

It relied on weaknesses security teams already understand:

Internet-facing services
Public exploit code
Missing or optional authentication
Delayed patching
Exposed administrative interfaces
Vulnerable workflow platforms
Weakly controlled development environments

AI makes these problems more dangerous because it can continuously search for combinations that may lead to exploitation.

Traditional scanners can already perform many of these tasks, but an agent can reason across the results.

It can decide that one vulnerability is unlikely to work, compare other products, obtain new exploit code and change direction.

That does not make the system intelligent in the human sense. It makes the attack process more flexible.

The difference is important.

Fixed automation follows a predefined sequence. An agent can choose a different sequence when the original plan fails.

The attacker built a reusable offensive system

Unit 42 found custom skills used for exploitation and FOFA searches.

This suggests that the actor was not treating the AI as a one-time experiment. The surrounding framework was being developed into a reusable attack environment.

Skills allow procedures to be stored and called again during future sessions.

Over time, an attacker could build a library covering:

Asset discovery
Vulnerability research
Exploit selection
Product-specific scanning
Credential testing
Data collection
Post-exploitation activity

The language model does not need to remember every technical detail. The surrounding system can provide the tools and instructions when needed.

This is similar to how legitimate organisations are building internal AI agents. The difference lies in the purpose, permissions and target.

The same autonomy that helped the attacker also exposed them

The campaign also showed that autonomous agents create new operational risks for attackers.

Hermes exposed the attacker’s environment because it launched a web server from the wrong directory.

A careful human operator may have noticed the mistake before sensitive files became publicly accessible.

The AI did not.

That error exposed the evidence Unit 42 later used to reconstruct the campaign.

Autonomous systems can therefore increase attack speed while also creating unexpected mistakes.

They may run commands from the wrong location, expose credentials, modify unintended files or generate logs that reveal more than the operator expected.

This does not eliminate the threat, but it shows that attackers are also accepting new risks when they delegate actions to AI systems.

Who should be concerned

The organisations most directly exposed are those operating vulnerable services on the public internet.

The report specifically describes attempts against Langflow and n8n, but the broader workflow is not limited to those products.

The same approach can be applied to any technology where attackers can combine:

A known vulnerability
Public exploit code
Internet-search results
Detectable product versions
Exposed attack prerequisites

This includes workflow platforms, low-code systems, AI-development tools, notebooks, remote-access products, edge devices and administrative services.

Organisations are less likely to be affected by the specific attack paths when:

The systems are not internet-facing
Supported and patched versions are in use
Strong authentication is required
Vulnerable functionality has been disabled
Network access is restricted
Exploit behaviour is monitored

It is also important not to misinterpret the report as a general security issue affecting ordinary DeepSeek users.

The risk came from the attacker’s integration of the model with an offensive agent framework and command-execution tools.

What enterprises should do now

The defensive priorities are not radically new. They are becoming more urgent because attackers can automate more of the discovery and testing process.

Know what is visible from the internet

Security teams need an accurate inventory of public-facing systems.

That inventory should record:

Product and version
Business owner
Internet exposure
Authentication requirements
Data sensitivity
Patch status
Expected use
Connected internal systems

Forgotten development tools and workflow platforms are especially risky because they may sit outside normal asset-management and patching processes.

Prioritise vulnerabilities using real attack conditions

CVSS scores alone do not show whether an attacker can realistically exploit a system.

Prioritisation should also consider:

Whether the service is internet-facing
Whether public exploit code exists
Whether authentication is required
Whether the vulnerable feature is enabled
What data or privileges the service can access
Whether active scanning has been observed
Whether compensating controls are present

The autonomous agent itself used this kind of logic when deciding whether to continue or abandon an attack.

Defenders should do the same.

Remove unnecessary exposure

Administrative interfaces, workflow platforms, notebooks and AI-development environments should not be public unless there is a clear business requirement.

Where possible, place them behind:

Private network access
Zero-trust access gateways
VPNs
IP restrictions
Strong identity controls
Dedicated management networks

Internet exposure should be a deliberate decision, not the default result of a deployment.

Make authentication mandatory

The recovered n8n attack failed because the forms the agent found required authentication.

That is a basic control, but it worked.

Sensitive workflows, file uploads, APIs, debugging features and administrative functions should never rely on optional authentication settings.

Authentication must also be combined with proper authorisation. A valid user should not automatically receive access to every workflow, credential or administrative capability.

Patch exposed systems quickly

Once a vulnerability has public exploit code, internet-facing systems should move into an accelerated remediation process.

The response should include:

Confirming whether the product is exposed
Identifying affected versions
Applying the vendor update
Restricting access if immediate patching is impossible
Checking for signs of exploitation
Confirming that the fix is effective

AI agents can reduce the time between public disclosure and large-scale testing.

Organisations cannot assume they have several quiet weeks before attackers begin scanning.

Logging and monitoring requirements

Security teams may not be able to determine whether an exploit request was generated by a human, a script or an AI agent.

The network traffic may look identical.

Detection should therefore focus on what the attacker does rather than trying to identify whether AI produced the request.

External exposure monitoring

Track:

Newly exposed services
New public IP addresses
Unexpected DNS records
Product-version changes
Authentication changes
Newly exposed administrative pages
Public forms and upload functions
Debug or development interfaces

Changes in exposure should trigger review before the system becomes part of an attacker’s target pool.

Web and network telemetry

Collect enough detail to identify:

Repeated product-version checks
Requests to unusual product-specific paths
High-frequency probing from the same source
Exploit-related request sequences
File-upload abuse
Attempts to read sensitive files
Outbound connections following suspicious requests

Web-server, reverse-proxy, firewall and network-detection logs should be correlated rather than reviewed separately.

Identity telemetry

Monitor for:

Repeated failed logins after vulnerability scanning
Successful authentication from unusual infrastructure
New API tokens or sessions
Privilege changes
Authentication bypass attempts
Unusual service-account use
Token or cookie use from unexpected locations

Reconnaissance followed by a successful login is often more meaningful than either event viewed alone.

Endpoint and application telemetry

Public-facing applications should be monitored for:

Unexpected shell execution
New child processes
Scripting engines launched by application services
Package installations
File writes in unusual locations
Access to credentials or tokens
Configuration changes
New scheduled tasks
Unusual outbound network connections

A workflow platform may legitimately execute scripts, so detections must account for normal behaviour.

The important question is whether the process, command, user and destination fit the expected workload.

Useful detection opportunities

Product enumeration followed by exploit testing

A source first checks the product or version and then sends requests matching a known exploit path.

This sequence is more suspicious than a simple version request on its own.

Required telemetry includes web-access logs, reverse-proxy logs and product audit logs.

False positives may include authorised vulnerability scanners, search engines and penetration tests.

Approved scanners should be identified, but security teams should avoid allowlisting them so broadly that compromised scanning infrastructure becomes invisible.

Rapid switching between unrelated technologies

The same source infrastructure probes one product and then quickly moves to another unrelated platform.

This may reflect an automated system comparing attack opportunities.

Broad vulnerability scanners can create similar behaviour, so detection should include timing, request sequence and exploit-specific details.

The signal is more valuable when the same infrastructure performs version discovery, prerequisite checks and exploit attempts across several products.

Application services launching unusual commands

An exposed workflow or development platform starts a shell, scripting interpreter or network utility that is not part of its normal execution pattern.

Endpoint telemetry is essential here.

The parent process, service account, command line, destination and timing should all be considered.

Legitimate automation may also execute commands, which means baselining is critical.

Credential access after suspicious web requests

A public-facing service accesses token files, session data or credentials shortly after exploit-like requests.

This can indicate progression from initial access to credential theft.

The strongest detection will correlate web, endpoint, file-access and identity telemetry.

Securing enterprise AI agents

The attacker’s architecture also offers a warning for organisations building their own agents.

Enterprise AI agents should not receive broad combinations of:

Shell access
Internet access
Cloud permissions
Secrets
Software-installation rights
External messaging
Unreviewed MCP servers
Access to sensitive internal data

The model’s reasoning should never be treated as an authorisation decision.

Every sensitive tool call should pass through an independent policy layer that checks:

Who requested the action
Which agent is acting
What data is involved
Which tool is being used
What destination will receive the data
Whether human approval is required
Whether the action can be reversed

An agent may conclude that an action is useful. That does not mean the action should be permitted.

A practical implementation plan

Phase 1: Discover

Start by identifying:

Public-facing applications
Workflow and automation platforms
AI-development systems
Software versions
Data sources
System owners
Authentication requirements
Service-account permissions

External attack-surface results should be compared with the internal inventory. Differences usually reveal forgotten or unmanaged systems.

Phase 2: Control

Apply the basic controls first:

Patch vulnerable systems
Remove unnecessary public access
Require strong authentication
Restrict administrative interfaces
Limit service-account privileges
Segment development and workflow environments
Restrict outbound connectivity
Protect credentials and API keys

Phase 3: Monitor

Centralise:

Web logs
Identity logs
Endpoint telemetry
Cloud events
Application audit logs
Network alerts

Build correlations that connect reconnaissance, exploit attempts, process execution and identity activity.

Phase 4: Test

Conduct authorised testing against realistic conditions.

Check whether:

Public exploit prerequisites are present
Authentication can be bypassed
Sensitive version details are exposed
Applications can spawn dangerous processes
Outbound communication is restricted
Detection controls observe the full attack sequence

Internal AI agents should also be tested for prompt injection, unrestricted tool access, data leakage and unsafe command execution.

Phase 5: Respond

An AI-related incident response process should still begin with familiar actions:

Isolate the affected service
Preserve logs and process evidence
Revoke exposed credentials and tokens
Search for persistence
Review connected systems
Patch or disable vulnerable functionality
Identify similar exposed deployments

The investigation should describe AI involvement carefully.

Unless there is direct evidence, teams should not claim that an attack was autonomous or AI-generated merely because the behaviour was fast or automated.

How this will affect different organisations

Small organisations

Smaller teams should focus first on visibility, authentication and patching.

They may not have advanced threat-hunting platforms, but they can still remove unnecessary public exposure, enable multifactor authentication, update internet-facing services and deploy reliable endpoint protection.

Their biggest challenge will often be software installed outside the security team’s knowledge.

Mid-sized enterprises

Mid-sized organisations should connect vulnerability management with external exposure data.

A vulnerable public workflow platform should be prioritised differently from an identical system isolated inside a development network.

SOC teams should also correlate network, identity and endpoint events instead of relying only on exploit signatures.

Mature enterprises

Larger organisations can automate parts of the defensive process.

They can continuously discover public assets, validate exploit prerequisites, accelerate patching and isolate unexpectedly exposed development systems.

Purple-team exercises should increasingly test attackers that change direction when one exploit path fails.

Regulated organisations

Detailed AI and application logging can create privacy and retention concerns.

Prompts, files, workflow inputs and tool outputs may contain personal data, customer information or credentials.

Logging must therefore include encryption, restricted access, defined retention periods and clear legal ownership.

AI-native companies

Companies building AI products should pay particular attention to model interfaces, orchestration platforms, notebooks, agent frameworks, vector databases and workflow engines.

These systems often change faster than traditional asset-management processes can follow.

Security checks for authentication, public exposure, tool permissions and outbound access should be built into deployment pipelines.

The architecture lesson

The most important lesson from this campaign is that the model was only one part of the attack system.

DeepSeek alone did not create the capability.

The risk emerged from combining:

Model reasoning
Agent orchestration
Terminal access
Internet connectivity
Vulnerability data
MCP integrations
Public exploit code
Permission to act without approval

The same principle applies inside an enterprise.

An AI agent should be treated as a privileged non-human identity, not as a smarter chatbot.

Its effective risk is determined by what it can access, which tools it can use, what actions it can execute and whether anyone can reconstruct those actions afterwards.

What remains unknown

Several details are still unclear.

Unit 42 recovered only part of the actor’s autonomous activity, so the total number of AI-driven sessions is unknown.

It is also unclear whether other sessions produced successful autonomous compromises.

The researchers did not publish the complete initial instruction given to Hermes, and human involvement outside the recovered session cannot be ruled out entirely.

Some target information had already been deleted before the investigation.

Unit 42 also found configurations related to several other AI tools, but the extent of their use could not always be verified from the available evidence.

There is no indication that the agent independently discovered a new vulnerability.

It also remains unclear how reliably this workflow would perform against patched, authenticated and well-monitored enterprise environments.

Most importantly, the report does not show that autonomous agents currently outperform experienced attackers.

It shows that they can automate enough of the repetitive work to become useful.

Final takeaway

The immediate lesson is not that fully autonomous AI hackers have arrived and can compromise anything they choose.

The stronger conclusion is more practical.

Attackers can now connect language models to search engines, terminals, exploit repositories and reusable tools to automate a growing share of vulnerability research and target testing.

That makes forgotten infrastructure more dangerous.

Organisations should assume that exposed services, weak authentication and delayed patching will be discovered faster and tested more frequently.

The AI agent in this campaign did not succeed.

But it did not need to succeed to show where cyberattacks are heading.