CVE-2026-25115 is a critical flaw (CVSS 9.9) in n8n, the workflow automation platform. An authenticated user can break out of the sandbox around the Python Code node and run code outside the intended boundary. n8n 2.4.8 fixes it. Upgrade, and consider external task runners to reduce what an escape can reach.
What's affected
- Affected: n8n before 2.4.8.
- Fixed in: 2.4.8 and later.
The advisory says the issue affects deployments where all of these hold:
- Task runners are enabled, with the setting N8N_RUNNERS_ENABLED set to true. The default is false.
- Python is enabled, with N8N_PYTHON_ENABLED set to true.
- The Code node is enabled. This is the default.
The advisory adds that only authenticated users can run code through task runners. If the runner mode is external, which is not the default, the escape is limited to the sidecar container. The advisory says a lower high severity fits that case better.
How to check if you're exposed
Check the three settings on your deployment, along with the version.
docker exec <container> env | grep N8N_
Replace the container name with your own. Look for N8N_RUNNERS_ENABLED, N8N_PYTHON_ENABLED and N8N_RUNNERS_MODE. If runners or Python are off, you are outside the described condition, though you should still upgrade. Then count the users with permission to create workflows, because each is a possible author of malicious code.
What to do now
- Upgrade n8n to 2.4.8 or later.
- If you cannot upgrade, disable the Code node by adding n8n-nodes-base.code to the NODES_EXCLUDE environment variable. This is the advisory's first workaround.
- Run task runners in external mode, so untrusted code runs in a separate sidecar container rather than inside the main n8n process. This is the advisory's second workaround.
- Keep the sidecar container small, with no extra secrets and tight network rules.
- Review who can create and edit workflows, and remove access that is not needed.
Why it matters
Sandboxes are a promise that code can run without touching the host. The class is CWE-693 (Protection Mechanism Failure), protection mechanism failure. When the protection fails, the code runs with whatever rights the process has. That is why the advisory pushes external mode. If the escape happens in a sidecar, the blast radius is that sidecar.
The design lesson is to keep two boundaries. A language sandbox is one. A separate process or container is the other. Treat the first as a convenience and the second as the real wall.
Quick check
Am I affected if I never turned on task runners?
The advisory describes the affected deployments as ones with task runners and Python enabled, plus the Code node. Upgrade anyway so a settings change later does not reopen the hole.
Is it exploited in the wild?
The record does not mark it as a CISA Known Exploited Vulnerability, and the advisory does not report exploitation.
Sources
Last reviewed: 19 October 2026.
