n8n: sandbox escape bugs lead to full RCE in self-hosted instances

• Category: Security

  • What happened: Researchers reported two sandbox-escape vulnerabilities in n8n that can result in remote code execution (RCE) on the main n8n node in affected self-hosted deployments.
  • CVE-2026-1470 (critical): A JavaScript AST sandbox escape involving unsafe handling of the with statement, allowing an attacker to reach Function and execute arbitrary JS outside the intended sandbox.
  • CVE-2026-0863: A Python AST sandbox escape that can regain access to restricted builtins/imports via Python runtime behavior, enabling OS command execution.
  • Preconditions: Exploitation requires authentication (ability to create/modify workflows), but the impact is still “full instance compromise” once a low-privileged user can reach the workflow editor.
  • Scope: n8n Cloud is reported as already addressed; the practical risk is on self-hosted instances running vulnerable versions.
  • Patching: Vendor patch versions were published; upgrade is the fastest path to reducing risk.
  • Bigger theme: “Sandboxing” dynamic languages is hard—assume clever escapes exist and build layered defenses (authz, isolation, monitoring), not just AST filters.

Why it matters

  • n8n sits at the center of automation: it often holds API tokens, can call SaaS apps, and can run code (JS/Python nodes). RCE here typically means credential theft + lateral movement.
  • Even if only “internal users” have access, many orgs treat workflow builders as semi-trusted. These CVEs show that a “non-admin builder” can become “infrastructure owner” if the sandbox boundary breaks.
  • Attackers increasingly hunt exposed automation/orchestration services (and they patch slowly). If your n8n is internet-reachable, the clock is not in your favor.

What to do

  1. Find exposure: locate all n8n instances (prod/staging/dev). Prioritize any reachable from the internet.
  2. Patch now: upgrade to a fixed n8n release (see vendor guidance / release notes). If you can’t patch immediately, restrict access to trusted IP ranges/VPN.
  3. Lock down workflow creation: minimize who can create/modify workflows; treat it as privileged access.
  4. Rotate secrets: if you suspect exposure, rotate tokens/credentials stored in n8n and review recent workflow changes.
  5. Add detection: alert on unusual workflow edits, new “code” nodes, and outbound connections from the n8n host.

Sources