n8n Expression Engine Sandbox Escape via Prototype Pollution (DoS)

Technical Analysis

The n8n workflow expression engine runs in a VM-based sandbox intended to isolate user-supplied expressions from the host Node.js process. By exploiting how array-element access resolves references, an attacker with workflow edit permissions can obtain a reference to a built-in object outside the sandbox boundary and mutate its prototype (prototype pollution), corrupting shared object behavior across the main process. Because n8n executes workflows as an orchestrating agent-like automation engine handling multiple tenants/workflows, this crosses a trust boundary from 'sandboxed user expression' to 'host process global state,' causing crashes or instability affecting all workflows running on the instance, not just the attacker's own. The attacker gains disruptive capability (DoS) rather than direct data exfiltration or RCE, but the sandbox escape primitive is notable since similar pollution paths have historically been chained toward RCE in other engines.

Affected Systems

n8n

Detection Signatures

• Unusual n8n workflow expressions using nested array indexing or bracket-notation chains targeting constructor/prototype properties
• Unexpected n8n process crashes or restarts correlated with workflow saves/executions
• Workflow definitions containing patterns like [].constructor.prototype or similar prototype-chain traversal via array element access
• Spike in error logs referencing corrupted built-in object properties after workflow execution
• Monitor for repeated instance-wide instability tied to a single user/workflow ID

Remediation Steps

1. 1

   Upgrade n8n

   Update to n8n 1.123.67, 2.31.5, 2.32.1, or later, which contain the fix for this sandbox escape/prototype pollution issue.

2. 2

   Restrict workflow editing access

   Until upgraded, limit ability to create or edit workflow expressions to fully trusted, vetted users only.

3. 3

   Disable VM expression engine

   If an alternative expression evaluation mode is available, disable the VM-based engine as a temporary mitigation.

4. 4

   Monitor for instability

   Watch for unexpected process crashes or anomalous behavior correlated with workflow expression changes, and audit workflow edit logs for suspicious patterns.

5. 5

   Isolate multi-tenant instances

   For shared/multi-tenant n8n deployments, consider per-tenant isolation (separate containers/instances) to limit blast radius of a single malicious workflow.