CVE-2026-0863 is a sandbox escape in the n8n Python task runner. An authenticated user with basic permissions can run unrestricted Python through the Code node. NVD scores it 8.5, high severity. Upgrade n8n to a build outside the affected ranges below, and review who can edit workflows.
What's affected
JFrog, which found the flaw, lists these affected n8n versions:
- Everything before 1.123.14.
- 2.0.0 up to but not including 2.3.5.
- 2.4.0 up to but not including 2.4.2.
Those ranges imply that 1.123.14, 2.3.5 and 2.4.2 are the first builds outside them. The advisory does not say that in words, so confirm against the n8n release notes and the fix commit before you pin a version.
How bad it is depends on the execution mode. In "Internal" mode, the flaw can lead to full takeover of the n8n instance. In "External" mode, which is what the official Docker image uses, the code runs in a separate sidecar container rather than on the main node, and JFrog says that reduces the impact significantly.
NVD records CVSS 8.5, vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H. It is not on the CISA KEV list, and neither advisory says it is exploited in the wild.
How to check if you're exposed
Check the n8n version first.
n8n --version
# Docker, example
docker exec YOUR_CONTAINER n8n --version
# npm install, example
npm ls n8n
Then check how task runners are configured. If your deployment runs Code node tasks inside the main n8n process (internal mode), the impact is larger than if it uses an external runner in a sidecar container. Your n8n configuration or compose file shows which one you have.
Next, find out who can create or edit workflows. The flaw needs an authenticated user, and the advisory says basic permissions are enough, so the real exposure is the number of accounts that can add a Python Code node.
If you use the free scan at gold.safeguard.sh/scan, upload your lockfile and look for n8n; the Gold directory page for this CVE lists what is known about affected builds.
What to do now
- Upgrade n8n to a version outside the affected ranges. For the 2.4 line that means 2.4.2 or later; for 2.0 to 2.3 it means 2.3.5 or later; for 1.x it means 1.123.14 or later. Confirm in the release notes.
- Prefer external task runners. The sandbox escape is far less damaging when code runs in a sidecar container instead of the main node.
- Review the user list. Remove accounts that do not need to build workflows, and treat any editor account as able to run code.
- Run n8n with the least privilege you can: a non-root user, a read-only file system where practical, and only the credentials the workflows need.
- Check recent workflow changes for Code nodes you do not recognise, and rotate the secrets stored in n8n if you find any.
Why it matters
The weaknesses are CWE-94 (improper control of generation of code, also called code injection) and CWE-95 (improper neutralization of directives in dynamically evaluated code). The Code node is meant to run user-written Python inside a restricted environment. JFrog says that string formatting and exception handling can be combined to get around the restrictions, so code that should have been boxed in runs without limits.
Sandboxes for dynamic languages are hard. Python exposes a great deal about itself at runtime, and each feature that reveals an internal object is a possible way out. Blocking the obvious paths is not enough. That is why the n8n design of running tasks in a separate runner matters: even when a sandbox fails, the failure is contained in a different process or container.
The CVSS scope is rated as changed, which signals that the impact reaches beyond the component itself. In practice, an n8n server often holds API keys, database passwords and OAuth tokens for many other systems, because that is what a workflow tool is for. Whoever controls the host can reach all of them. The attack complexity is rated high and the account must be authenticated, so this is not an anonymous internet bug, but any workflow editor is in scope.
The JFrog advisory shows a proof of concept. I have not reproduced it here, and you should not need it: the version check and upgrade above are the whole defensive task.
Try it yourself
A sandbox escape needs an account, a specific configuration and a reachable feature. This demo shows how an exploitability check weighs those conditions instead of treating every high score the same.
Click through it at your own pace, or open it full screen.
Quick check
Does the official n8n Docker image have the same impact?
JFrog says that in External mode, which the official Docker image uses, the code runs in a sidecar container and not on the main node, so the impact is significantly lower. It is still worth upgrading.
Who can use this flaw?
An authenticated user with basic permissions who can use the Code node, per the advisory. Limit who can build workflows.
Sources
Last reviewed: 19 October 2026.
