Summary
The @n8n/computer-use package on Linux and Windows runs shell commands without sandboxing, giving the tool unrestricted access to the host filesystem and network.
In deployments where this package is explicitly installed and active, a compromised or malicious agent workflow can lead to full host compromise under the account running n8n.
The @n8n/computer-use package on Linux and Windows runs shell commands without sandboxing, giving the tool unrestricted access to the host filesystem and network.
In deployments where this package is explicitly installed and active, a compromised or malicious agent workflow can lead to full host compromise under the account running n8n.
Affected context
This vulnerability appears in n8n deployments that explicitly install and run the @n8n/computer-use package on Linux or Windows hosts.
In these environments, shell commands invoked by the computer-use agent process execute directly on the underlying OS without filesystem or network restrictions.
Standard n8n installations that do not use the computer-use package, or those running on macOS with enforced sandboxing, are generally not exposed to this issue.
This vulnerability appears in n8n deployments that explicitly install and run the @n8n/computer-use package on Linux or Windows hosts.
In these environments, shell commands invoked by the computer-use agent process execute directly on the underlying OS without filesystem or network restrictions.
Standard n8n installations that do not use the computer-use package, or those running on macOS with enforced sandboxing, are generally not exposed to this issue.
Exploit preconditions
- Attack surface: Workflows, tasks, or integrations that trigger the
@n8n/computer-useshell capabilities. - Required access: Ability to define, modify, or influence workflows, prompts, or tool invocations that the computer-use agent executes.
- Trigger point: Execution of shell commands by the computer-use tool on Linux or Windows, where restrictions are not enforced.
- Why exploitation is possible: The tool executes shell commands in an unsandboxed environment, granting direct access to filesystem and network resources under the agent's OS privileges.
- Attack surface: Workflows, tasks, or integrations that trigger the
@n8n/computer-useshell capabilities. - Required access: Ability to define, modify, or influence workflows, prompts, or tool invocations that the computer-use agent executes.
- Trigger point: Execution of shell commands by the computer-use tool on Linux or Windows, where restrictions are not enforced.
- Why exploitation is possible: The tool executes shell commands in an unsandboxed environment, granting direct access to filesystem and network resources under the agent's OS privileges.
Why this happens
The underlying bug aligns with CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), but in this case the primary issue is a lack of sandboxing rather than direct string injection.
Shell execution is treated as fully trusted and is not constrained by operating system-level or application-level sandboxes on Linux and Windows.
This design assumes that the computer-use tool will behave safely, but in practice any untrusted or dynamically generated command can execute with broad privileges, creating a high-risk command execution environment.
The underlying bug aligns with CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), but in this case the primary issue is a lack of sandboxing rather than direct string injection.
Shell execution is treated as fully trusted and is not constrained by operating system-level or application-level sandboxes on Linux and Windows.
This design assumes that the computer-use tool will behave safely, but in practice any untrusted or dynamically generated command can execute with broad privileges, creating a high-risk command execution environment.
Potential impact
- An attacker may read, modify, or delete files accessible to the n8n process on the host system.
- An attacker could establish outbound network connections, exfiltrating data or interacting with internal services.
- Malicious commands can install additional tooling or malware on the host.
- The n8n instance could be used as a pivot point for lateral movement across the network.
- System stability can be affected by resource exhaustion, process termination, or destructive actions.
- An attacker may read, modify, or delete files accessible to the n8n process on the host system.
- An attacker could establish outbound network connections, exfiltrating data or interacting with internal services.
- Malicious commands can install additional tooling or malware on the host.
- The n8n instance could be used as a pivot point for lateral movement across the network.
- System stability can be affected by resource exhaustion, process termination, or destructive actions.
General mitigation guidance
Mitigation centers on constraining shell execution and clarifying trust boundaries for automation tools.
Common patterns include:
- Running automation agents and shell-capable tools inside tightly scoped containers or VMs with restricted filesystem and network access.
- Applying OS-level sandboxing, such as mandatory access controls or jailed environments, around processes that can execute arbitrary commands.
- Designing workflows so that user- or model-generated instructions are not executed directly as shell commands without review or filtering.
- Applying least-privilege principles to the n8n process, limiting its OS permissions and reachable paths.
- Separating high-risk automation capabilities into isolated infrastructure, distinct from core application services and sensitive data.
Mitigation centers on constraining shell execution and clarifying trust boundaries for automation tools.
Common patterns include:
- Running automation agents and shell-capable tools inside tightly scoped containers or VMs with restricted filesystem and network access.
- Applying OS-level sandboxing, such as mandatory access controls or jailed environments, around processes that can execute arbitrary commands.
- Designing workflows so that user- or model-generated instructions are not executed directly as shell commands without review or filtering.
- Applying least-privilege principles to the n8n process, limiting its OS permissions and reachable paths.
- Separating high-risk automation capabilities into isolated infrastructure, distinct from core application services and sensitive data.
How teams detect issues like this
Detection typically focuses on identifying risky shell execution patterns and monitoring host behavior:
- Static review of workflow definitions and automation scripts to flag steps that invoke shell commands from the computer-use tool.
- Code and configuration review to ensure that shell-capable agents run within sandboxed environments or containers.
- Host-based monitoring for unusual filesystem access, process creation patterns, or outbound network activity originating from the n8n/computer-use process.
- Security policies that require approvals or checks for workflows which include arbitrary command execution capabilities.
Detection typically focuses on identifying risky shell execution patterns and monitoring host behavior:
- Static review of workflow definitions and automation scripts to flag steps that invoke shell commands from the computer-use tool.
- Code and configuration review to ensure that shell-capable agents run within sandboxed environments or containers.
- Host-based monitoring for unusual filesystem access, process creation patterns, or outbound network activity originating from the n8n/computer-use process.
- Security policies that require approvals or checks for workflows which include arbitrary command execution capabilities.
