CVE-2026-27494 - n8n Python Code node sandbox escape

n8n disclosed a Python Code node sandbox escape that can be reached by an authenticated user who can create or modify workflows when Task Runners are enabled. The vulnerable sandbox did not sufficiently restrict access to certain Python built-in objects, allowing a workflow author to read host files and, in higher-impact runner modes, move toward remote code execution.

This is a workflow-authority and runner-isolation issue, not just a package bump. The practical risk depends on who can edit workflows, whether N8N_RUNNERS_ENABLED=true is set, whether the deployment uses internal or external Task Runners, and what credentials, mounts, internal network paths, and host privileges are available to n8n execution.

There is a public severity mismatch as of 2026-06-08. GitHub’s advisory database listing shows high severity for CVSS 4.0, NVD records a critical CVSS 3.1 score, and the n8n vendor advisory labels the issue critical with broader vulnerable-system and subsequent-system impact. Treat controlled self-hosted deployments as critical when untrusted or semi-trusted users can author workflows.

When to use it

  • A repository deploys, packages, pins, vendors, or configures self-hosted n8n server runtimes, not only workflow exports or API clients.
  • Task Runners are enabled or may be enabled through rendered manifests, environment templates, CI images, Helm values, or operator docs.
  • Users outside a fully trusted admin/operator group can create, import, restore, or edit workflows with Python Code node access.
  • You need a bounded PR or triage note that upgrades n8n and documents runner, workflow-authority, Code-node, and credential containment.

Inputs

  • Package manifests, lockfiles, Docker/Compose/Helm/K8s/Terraform/Ansible artifacts, workflow bundles, environment templates, SBOMs, generated manifests, and runbooks.
  • Resolved n8n version, N8N_RUNNERS_ENABLED, NODES_EXCLUDE, workflow role model, internal/external Task Runner topology, mounts, environment secrets, internal egress, and audit/rotation owners.
  • Available package install checks, workflow import/export checks, config lint, deployment render, image build, SBOM, and dependency/security scans.

Affected versions

  • Vulnerable package: n8n <1.123.22
  • Vulnerable package: n8n >=2.0.0, <2.9.3
  • Vulnerable package: n8n >=2.10.0, <2.10.1
  • Fixed package: n8n 1.123.22+, 2.9.3+, or 2.10.1+ on the selected release line
  • Required configuration: Task Runners enabled with N8N_RUNNERS_ENABLED=true
  • Affected surface: Python Code node execution by authenticated workflow authors

Indicator-of-exposure

  • The repository deploys, packages, forks, vendors, or pins the n8n server, not only an API client, SDK wrapper, workflow export, or documentation.
  • A controlled runtime resolves to an affected n8n version through npm, pnpm, Yarn, Docker, Helm, Kubernetes, Terraform, Ansible, Compose, generated dependency manifests, SBOMs, or release scripts.
  • N8N_RUNNERS_ENABLED=true is present in environment files, rendered manifests, Helm values, Compose files, Kubernetes manifests, process-manager config, CI runner images, or operator docs.
  • Users outside the fully trusted administrator/operator group can create, import, modify, or restore workflows.
  • The Python Code node is enabled, or NODES_EXCLUDE does not include n8n-nodes-base.code.
  • n8n internal Task Runners share the main host, container, service account, environment variables, mounted secrets, source checkout, package cache, cloud metadata reach, or internal network access.
  • External Task Runners have access to other tenants’ task execution context, shared worker credentials, queues, mounted volumes, internal services, or reusable build/runtime caches.

Quick checks:

rg -n "n8n|N8N_VERSION|n8nio/n8n|N8N_RUNNERS_ENABLED|NODES_EXCLUDE|n8n-nodes-base.code|Code node|Python|workflow|runner|Task Runner|credentials" .
npm ls n8n
pnpm why n8n
yarn why n8n
rg -n "n8n|n8nio/n8n|N8N_VERSION|N8N_RUNNERS_ENABLED|NODES_EXCLUDE|workflow|runner|credentials" Dockerfile* docker-compose*.yml compose*.yml charts k8s helm terraform ansible .github . 2>/dev/null
docker image ls | rg 'n8n|n8nio'

Windows:

rg -n "n8n|N8N_VERSION|n8nio/n8n|N8N_RUNNERS_ENABLED|NODES_EXCLUDE|n8n-nodes-base.code|Code node|Python|workflow|runner|Task Runner|credentials" .
npm ls n8n
pnpm why n8n
yarn why n8n
rg -n "n8n|n8nio/n8n|N8N_VERSION|N8N_RUNNERS_ENABLED|NODES_EXCLUDE|workflow|runner|credentials" Dockerfile* docker-compose*.yml compose*.yml charts k8s helm terraform ansible .github .
docker image ls | rg 'n8n|n8nio'

Do not test exposure by running Python sandbox-escape snippets, reading real host files, printing environment variables, executing workflows against live n8n, or dumping workflow credentials.

Remediation strategy

  • Upgrade every controlled n8n runtime to 1.123.22+, 2.9.3+, or 2.10.1+ on its existing release line.
  • Pin explicit patched image tags or digests instead of floating tags that can drift between deploy, scan, and review.
  • Regenerate lockfiles, rendered deployment manifests, image tags or digests, generated dependency reports, SBOMs, and operator documentation so the resolved runtime is visibly patched.
  • Until the upgrade is deployed, restrict workflow creation, import, restore, and editing to fully trusted administrators. Treat this as containment only.
  • If upgrade is blocked and this repository controls node availability, disable the Code node with NODES_EXCLUDE=n8n-nodes-base.code. Document residual risk because the vendor explicitly treats node exclusion and author restriction as temporary workarounds, not full remediation.
  • Harden Task Runners separately from the package upgrade: remove unnecessary mounts, drop OS privileges, isolate tenant work, restrict internal egress, block cloud metadata, separate queues or worker pools where needed, and avoid passing unrelated deployment, package, source-control, cloud, database, or model-provider credentials into workflow execution.
  • Review workflow edit history, execution logs, runner logs, and unusual file access indicators if untrusted authors had access to vulnerable runtimes. Rotate n8n, database, SSH, Git, cloud, package, OAuth, and model-provider credentials that may have been reachable from vulnerable Task Runners.
  • Add safe policy checks that prove resolved n8n versions are patched, Task Runner exposure is documented, Code-node containment is explicit if used, and broad roles cannot edit workflows during rollout.

The prompt

You are remediating CVE-2026-27494 / GHSA-mmgg-m5j7-f83h, an n8n Python Code
node sandbox escape that can let authenticated workflow authors read host files
or achieve remote code execution when Task Runners are enabled. Produce exactly
one output:

- A reviewer-ready PR/change request that upgrades every controlled n8n
  runtime, preserves the intended release line, adds safe deployment or policy
  checks, and documents workflow-author, Code-node, Task Runner, and credential
  containment, or
- TRIAGE.md if this repository does not own an affected n8n server runtime,
  Task Runner deployment, workflow-author control, or safe patch path.

## Rules

- Scope only CVE-2026-27494 / GHSA-mmgg-m5j7-f83h and directly related n8n
  Python Code node, Task Runner, workflow-authority, runner-isolation, and
  credential-exposure controls.
- Distinguish n8n server/runtime deployments from n8n API clients, SDK
  wrappers, workflow exports, sample docs, and externally owned n8n services.
- Treat workflow credentials, n8n encryption keys, environment variables,
  mounted secrets, OAuth tokens, webhook URLs, SSH keys, Git credentials, cloud
  credentials, database credentials, package tokens, model-provider keys,
  execution data, runner logs, and host files as sensitive.
- Do not execute Python sandbox-escape payloads, read real host files through
  n8n, print environment variables, run live workflow probes, dump execution
  data, or use shell/Git/SSH/file-system nodes for validation.
- Do not remove workflow authorization, audit logging, credential scoping,
  worker isolation, deployment checks, or tests just to silence the advisory.
- Do not auto-merge.

## Steps

1. Inventory all controlled n8n runtime references in package manifests,
   lockfiles, Dockerfiles, Compose files, Helm values, Kubernetes manifests,
   Terraform, Ansible, release scripts, CI images, generated dependency
   manifests, SBOMs, workflow bundles, and deployment runbooks.
2. Determine every resolved n8n version. A target is vulnerable if it resolves
   to `n8n <1.123.22`, `n8n >=2.0.0, <2.9.3`, or
   `n8n >=2.10.0, <2.10.1`.
3. Determine whether Task Runners are enabled by searching for
   `N8N_RUNNERS_ENABLED=true` in runtime config, rendered manifests, env files,
   charts, process managers, CI images, and operator docs.
4. Search for Python Code node exposure and workflow-author authority:
   `n8n-nodes-base.code`, Code node configuration, Python node usage, workflow
   imports, seeded workflows, restore paths, editor roles, broad tenant roles,
   admin groups, SSO mappings, audit settings, and workflow execution modes.
5. If the repository only integrates with an externally owned n8n service,
   stores workflow exports, or cannot change the n8n runtime, stop with
   `TRIAGE.md` naming the owner, evidence checked, Task Runner questions, and
   required fixed versions.
6. Upgrade vulnerable runtimes on their existing release line:
   - `1.x` deployments to `1.123.22+`;
   - `2.9.x` deployments to `2.9.3+`;
   - `2.10.x` deployments to `2.10.1+`;
   - other `2.x` deployments to a fixed release at or above the nearest
     compatible patched version;
   - floating image tags to explicit patched tags or digests.
7. Refresh the repository's normal generated artifacts: lockfiles, rendered
   deployment manifests, image digests, container metadata, generated
   dependency reports, SBOMs, release notes, and operator docs.
8. Apply temporary containment when rollout is delayed:
   - restrict workflow creation, import, restore, and editing to fully trusted
     administrators;
   - disable the Code node with `NODES_EXCLUDE=n8n-nodes-base.code` where this
     repository controls node availability;
   - quarantine high-risk workflow templates that rely on Python Code until
     the fixed runtime is deployed;
   - document residual risk because these workarounds do not fully remediate
     the vulnerable runtime.
9. Harden Task Runners and workflow execution:
   - separate runner privileges from the main n8n service where practical;
   - remove unrelated environment secrets from runner processes;
   - minimize file-system mounts and make necessary mounts read-only;
   - block cloud metadata, internal admin services, source-control systems,
     package registries, databases, and queues unless explicitly required;
   - isolate tenant or workspace execution where the platform supports it;
   - ensure runner logs do not capture workflow credentials or secret-bearing
     output.
10. Add safe regression or policy checks that do not exploit the issue:
    - resolved n8n versions are not in the vulnerable ranges;
    - rendered manifests use patched image tags or digests;
    - broad roles cannot create, restore, import, or edit workflows during
      containment;
    - `NODES_EXCLUDE` includes `n8n-nodes-base.code` when node exclusion is the
      documented temporary workaround;
    - Task Runner config omits unrelated secret mounts and environment
      variables in repository-controlled deployments.
11. Add a PR body section named `CVE-2026-27494 operator actions` that states:
    - n8n versions before and after;
    - whether `N8N_RUNNERS_ENABLED=true` was present;
    - whether internal or external Task Runners are used;
    - who can create, import, restore, or edit workflows after the change;
    - whether the Python Code node is enabled, disabled, or temporarily
      excluded;
    - which credentials, mounts, internal network paths, or runner queues may
      have been reachable by workflow authors;
    - whether workflow audit, runner log review, credential rotation, or
      incident review is required;
    - how the high-versus-critical public severity mismatch was handled;
    - which validation commands passed.
12. Run available validation: package-manager install check, lockfile
    integrity, unit tests, workflow import/export checks, config lint,
    deployment rendering, image build, SBOM refresh, dependency/security scans,
    and non-secret smoke checks.
13. Use PR title:
    `fix(sec): remediate CVE-2026-27494 in n8n Python Code`

## Stop conditions

- No affected n8n server runtime, Task Runner deployment, image, lockfile, or
  workflow-author control is owned by this repository.
- The affected n8n service is owned by another team or vendor; name the owner
  and required fixed version in `TRIAGE.md`.
- Task Runners are not enabled and all controlled n8n versions are outside the
  vulnerable ranges; document that evidence in `TRIAGE.md` instead of patching
  unrelated code.
- A fixed n8n version cannot be consumed without a broader platform migration
  or maintenance window.
- Verification would require Python sandbox-escape payloads, live workflow
  execution, real host-file reads, environment-variable disclosure, credential
  access, or printing secret material.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • Every controlled n8n runtime resolves to 1.123.22+, 2.9.3+, or 2.10.1+ on the chosen release line.
  • Package locks, image tags or digests, rendered manifests, SBOMs, generated dependency reports, and docs agree on the patched version.
  • The PR states whether N8N_RUNNERS_ENABLED=true exists and whether internal or external Task Runners are used.
  • Workflow creation, import, restore, and editing are limited to intended trusted roles until the patched runtime is deployed.
  • Temporary Code-node exclusion uses NODES_EXCLUDE=n8n-nodes-base.code and is documented as containment, not represented as full remediation.
  • Runner hardening is addressed separately from upgrade: OS privileges, mounts, environment secrets, internal egress, metadata access, queues, and tenant isolation.
  • The PR does not execute sandbox escapes, read real host files, print environment variables, expose workflow credentials, or leak execution data.
  • Tests, builds, deployment rendering, and dependency scans pass or unrelated failures are documented.

Output contract

  • Reviewer-ready PR upgrading every controlled n8n runtime to a patched release on its existing line with aligned locks, images, manifests, SBOMs, reports, and docs.
  • Explicit statement of Task Runner state, Python Code node containment, workflow-author roles, runner isolation, and temporary NODES_EXCLUDE behavior when used.
  • Safe policy checks proving patched versions, rendered image tags/digests, restricted workflow authorship during rollout, and secret-minimized runner config without executing sandbox escapes.
  • TRIAGE.md when the n8n server runtime, Task Runner deployment, workflow authorization, or incident follow-up is owned outside this repository.

Watch for

  • Updating package.json while Docker tags, Helm values, Compose files, generated manifests, lockfiles, or SBOMs still deploy vulnerable n8n.
  • Assuming the finding is irrelevant because the attacker needs workflow edit permission, while tenants, developers, automations, or support users can author workflows.
  • Treating NODES_EXCLUDE or workflow-author restriction as a permanent fix instead of temporary containment.
  • Leaving internal Task Runners with broad mounts, secrets, metadata access, or internal-service egress after the version upgrade.
  • External Task Runners that share queues, caches, credentials, or execution context between tenants.
  • Validation scripts that run exploit-like Python, inspect production host files, or capture secret-bearing workflow output.
  • Logs that include workflow credential material, environment variables, or runner response bodies during failed validation.

References