CVE-2026-65590: n8n unsandboxed shell on

CISO Take

n8n's optional @n8n/computer-use package lets an AI agent execute shell commands on the host, but a sandboxing bug — patched in 2.29.8 and 2.30.1 — meant that restriction was only ever enforced on macOS: on Linux and Windows, every shell command the agent issues runs with full filesystem and network access. This matters for any deployment that has explicitly enabled computer-use automation, since a manipulated or compromised agent task translates directly into unrestricted host access rather than a contained failure; the package sits in n8n's dependency tree alongside 150 other recorded CVEs and 16 downstream dependents, so blast radius scales with adoption. There is no CVSS score, no EPSS percentile, no CISA KEV listing, and no known public exploit or Nuclei template yet, so this is not an actively-exploited or scanner-ready bug — but the fix is trivial: upgrade to n8n >=2.29.8 or >=2.30.1 immediately if computer-use is enabled on Linux or Windows hosts. Until patched, treat any such host as unsandboxed and compensate with container-level isolation, egress firewalling, and audit logging of shell commands issued by the agent.

Sources: NVD GitHub Advisory OpenSSF ATLAS vulncheck.com

What is the risk?

Low-to-moderate near-term risk given the absence of a CVSS score, EPSS data, CISA KEV listing, or public exploit/scanner coverage — but high potential severity wherever applicable, since the bug removes the only isolation layer for an agent explicitly designed to run arbitrary shell commands. Exposure is scoped to the subset of n8n deployments that explicitly install and run @n8n/computer-use (standard n8n installs are unaffected), which limits the attack surface but does not eliminate it, especially as computer-use / browser-operator agent patterns gain adoption in agentic automation stacks.

How does the attack unfold?

Agent tool invocation

A workflow or manipulated task input directs the n8n computer-use agent to execute a shell command through its command-execution tool.

AML.T0053

Sandbox bypass

On Linux/Windows hosts the shell command runs without the sandbox restrictions applied on macOS, exposing full filesystem and network access.

AML.T0105

Host and network access

The unrestricted process reads and writes arbitrary files, harvests credentials, and reaches other hosts on the container's network.

AML.T0112.000

Impact — persistence and data exposure

The attacker exfiltrates sensitive data or establishes persistence on the compromised host, achieving full machine compromise from what should have been a contained agent action.

Agent tool invocation

A workflow or manipulated task input directs the n8n computer-use agent to execute a shell command through its command-execution tool.

AML.T0053

Sandbox bypass

On Linux/Windows hosts the shell command runs without the sandbox restrictions applied on macOS, exposing full filesystem and network access.

AML.T0105

Host and network access

The unrestricted process reads and writes arbitrary files, harvests credentials, and reaches other hosts on the container's network.

AML.T0112.000

Impact — persistence and data exposure

The attacker exfiltrates sensitive data or establishes persistence on the compromised host, achieving full machine compromise from what should have been a contained agent action.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.30.0, < 2.30.1	`2.30.1`
204.1K OpenSSF 6.6 16 dependents Pushed 7d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 25% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade n8n to >=2.29.8 (2.29.x branch) or >=2.30.1 (2.30.x branch) immediately on any instance where @n8n/computer-use is installed and in use. Until patched, disable or avoid running the computer-use node on Linux/Windows hosts, or wrap the process in independent OS-level isolation (Docker with seccomp/AppArmor, gVisor, a locked-down VM, or a network-namespaced container with strict egress rules) since the package's own sandboxing cannot be trusted on those platforms. Audit which workflows have computer-use nodes enabled and confirm whether they run on Linux/Windows hosts in production. For detection, review shell command logs emitted by the computer-use tool for filesystem paths or network destinations outside expected task scope, and monitor for unexpected outbound connections from n8n worker containers.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Data Leakage Agent Plugin AML.T0050 - Command and Scripting Interpreter AML.T0053 - AI Agent Tool Invocation AML.T0105 - Escape to Host AML.T0112.000 - Local AI Agent

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6 - AI system operation and monitoring

NIST AI RMF

MEASURE-2.7 - AI system security and resilience evaluated and documented

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-65590?

n8n's optional @n8n/computer-use package lets an AI agent execute shell commands on the host, but a sandboxing bug — patched in 2.29.8 and 2.30.1 — meant that restriction was only ever enforced on macOS: on Linux and Windows, every shell command the agent issues runs with full filesystem and network access. This matters for any deployment that has explicitly enabled computer-use automation, since a manipulated or compromised agent task translates directly into unrestricted host access rather than a contained failure; the package sits in n8n's dependency tree alongside 150 other recorded CVEs and 16 downstream dependents, so blast radius scales with adoption. There is no CVSS score, no EPSS percentile, no CISA KEV listing, and no known public exploit or Nuclei template yet, so this is not an actively-exploited or scanner-ready bug — but the fix is trivial: upgrade to n8n >=2.29.8 or >=2.30.1 immediately if computer-use is enabled on Linux or Windows hosts. Until patched, treat any such host as unsandboxed and compensate with container-level isolation, egress firewalling, and audit logging of shell commands issued by the agent.

Is CVE-2026-65590 actively exploited?

No confirmed active exploitation of CVE-2026-65590 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-65590?

Upgrade n8n to >=2.29.8 (2.29.x branch) or >=2.30.1 (2.30.x branch) immediately on any instance where @n8n/computer-use is installed and in use. Until patched, disable or avoid running the computer-use node on Linux/Windows hosts, or wrap the process in independent OS-level isolation (Docker with seccomp/AppArmor, gVisor, a locked-down VM, or a network-namespaced container with strict egress rules) since the package's own sandboxing cannot be trusted on those platforms. Audit which workflows have computer-use nodes enabled and confirm whether they run on Linux/Windows hosts in production. For detection, review shell command logs emitted by the computer-use tool for filesystem paths or network destinations outside expected task scope, and monitor for unexpected outbound connections from n8n worker containers.

What systems are affected by CVE-2026-65590?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, computer-use / browser-operator agents, workflow automation pipelines.

What is the CVSS score for CVE-2026-65590?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworkscomputer-use / browser-operator agentsworkflow automation pipelines

MITRE ATLAS Techniques

AML.T0050 Command and Scripting Interpreter

AML.T0053 AI Agent Tool Invocation

AML.T0105 Escape to Host

AML.T0112.000 Local AI Agent

Compliance Controls Affected

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE-2.7

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

n8n before 2.29.8 and 2.30.x before 2.30.1 does not enforce shell sandbox restrictions on Linux and Windows in the @n8n/computer-use package (sandboxing was applied only on macOS). Shell commands executed by the tool run without any filesystem or network restrictions, allowing unrestricted access to the host filesystem and network from within the computer-use agent process. This issue only affects deployments where the @n8n/computer-use package is explicitly installed and running; standard n8n installations are not affected.

Exploitation Scenario

An organization runs a self-hosted n8n instance on a Linux server with @n8n/computer-use enabled to let an AI agent operate a virtual browser for research or RPA tasks. An attacker who can influence the agent's task — for example via a prompt-injected instruction embedded in a webpage the agent visits, or a malicious workflow trigger — causes the agent to issue a shell command through its computer-use tool. Because sandbox restrictions never applied on Linux, that command executes with the full privileges of the n8n process: the attacker reads credentials and environment variables from the filesystem, pivots to other services reachable on the container's network, and establishes persistence, turning what should have been a contained agent action into full host compromise.

Weaknesses (CWE)

CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Primary CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Primary CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.

[Architecture and Design] If at all possible, use library calls rather than external processes to recreate the desired functionality.
[Architecture and Design, Operation] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.