CVE-2026-65590: n8n: computer-use Shell Sandbox Not Enforced on Linux and Windows

@n8n/computer-use lets an n8n agent run shell commands on a host. The tool was meant to confine those commands with a sandbox. The sandbox code ran only on macOS. On Linux and Windows the commands ran as plain processes of the computer-use agent, with full access to the host filesystem and network.

In practice the sandbox was the only guard between what the agent decides to run and the host. If a prompt-injected workflow, a malicious document the agent reads, or a user with access to the agent steers it into running a command, nothing limits that command. It can read files and secrets the agent's user can read, change files, and reach internal network services.

The CVSS 4.0 vector requires high privileges and an attacker precondition (AT:P), so exploitation needs a user or flow that can already direct the agent. The scoring puts the high impact on subsequent systems, not the n8n process itself. The CWE is OS command injection (CWE-78). The advisory says standard n8n installs, without this package, are not affected.

n8n deployments where @n8n/computer-use is explicitly installed and running on Linux or Windows hosts. Per the package data, n8n versions below 2.29.8, and 2.30.0 specifically (the range >= 2.30.0, < 2.30.1), are affected. macOS hosts already had the sandbox.

Check the n8n version and whether the package is present:

npm ls n8n
npm ls -g @n8n/computer-use

Upgrade n8n to 2.29.8 (for the 2.29 line) or 2.30.1 (for the 2.30 line), or any later release. The fix adds sandbox enforcement on Linux through bubblewrap. It also disables the shell tool entirely when a working sandbox cannot be set up, so a host without bubblewrap will lose the tool until you fix that.

For deployments that need unsandboxed shell access and accept the risk, an explicit opt-out flag, --dangerously-disable-shell-sandbox, exists.

If you cannot upgrade yet, the advisory suggests two temporary measures: do not deploy @n8n/computer-use on Linux or Windows hosts, and limit access to the n8n instance and the computer-use agent to fully trusted users. The advisory says these do not fully remove the risk.

Find hosts running the computer-use agent, then review what its shell tool ran. Look at the agent process's shell history, process tree and audit logs for commands that touch paths outside the intended working directory, read credential files, or open outbound connections to unexpected hosts. Review n8n execution logs for workflows that used the computer-use shell tool before you upgraded.

After the upgrade, a Linux host without bubblewrap will have the shell tool disabled, which shows the sandbox check works. If AI agents run on those hosts, Beam can record agent shell commands and file access and flag risky ones through its rules.

Impact

The shell tool in the @n8n/computer-use package applied its sandbox restrictions only on macOS. On Linux and Windows, shell commands executed by the tool ran 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. It does not affect standard n8n installations.

Patches

The issue has been fixed in n8n versions 2.29.8 and 2.30.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

The fix adds sandbox enforcement on Linux via bubblewrap and disables the shell tool entirely when a working sandbox cannot be established. An explicit opt-out flag (--dangerously-disable-shell-sandbox) is available for deployments that require unsandboxed shell access and accept the associated risk.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Disable or avoid deploying the @n8n/computer-use package on Linux or Windows hosts until the fix is applied.
• Restrict access to the n8n instance and the computer-use agent to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.