CVE-2026-25049 - n8n expression escape RCE

n8n disclosed a critical expression-evaluation escape that lets an authenticated user with workflow create or edit permission place crafted expressions in workflow parameters and trigger unintended command execution on the n8n host.

This is not the same exposure as the later XML prototype-pollution n8n CVEs. The risky boundary is workflow expression evaluation itself, especially in multi-user n8n deployments where semi-trusted users can author workflows and where workers run with broad file-system, network, credential, or shell access.

When to use it

Use this recipe when a repository deploys n8n, pins n8n images, ships workflow templates, or manages multi-user workflow automation where semi-trusted authors can create or edit expressions. It is designed for source-code and deployment remediation, workflow-author trust review, worker hardening, credential hygiene, and evidence that crafted expressions cannot escape into host command execution.

Inputs

  • n8n version, package/image/chart/manifest pins, workflow exports/templates, worker mode, expression settings, node allow/deny lists, and generated dependency or SBOM reports.
  • Source/config paths that deploy n8n, seed/import workflows, grant workflow edit permissions, mount credentials, enable shell-capable nodes, or run workers with broad filesystem/network access.
  • Regression fixtures or safe checks for fixed versions, restricted workflow authors, disabled risky nodes, least-privilege worker environment, and expression validation without executing exploit payloads.
  • Boundary evidence: workflow author roles, credential store access, internal service reachability, secrets mounted into workers, logs, image owners, and rollout owner.

Affected versions

  • Vulnerable: n8n <1.123.17
  • Vulnerable: n8n >=2.0.0, <2.5.2
  • Fixed: n8n 1.123.17, 2.5.2, or later on the selected release line

Indicator-of-exposure

  • The repository builds, deploys, or pins the n8n server/runtime, not only an API client, SDK wrapper, workflow export, or documentation.
  • A deployable n8n runtime resolves to an affected version through npm, Docker images, Helm charts, compose files, Kubernetes manifests, Terraform, Ansible, runner images, or release scripts.
  • Users outside the core administrator/operator group can create, import, or modify workflows.
  • Stored workflow exports, seeded templates, or customer-managed workflows use n8n expressions in node parameters.
  • n8n workers can reach sensitive file paths, internal services, metadata endpoints, source-control credentials, deployment secrets, or shell-capable nodes.

Quick checks:

rg -n "n8n|N8N_VERSION|n8nio/n8n|EXECUTIONS_PROCESS|NODES_EXCLUDE|workflow|={{|expression|code node|execute command|shell|credentials" .
npm ls n8n
pnpm why n8n
yarn why n8n
docker image ls | rg 'n8n|n8nio'

Windows:

rg -n "n8n|N8N_VERSION|n8nio/n8n|EXECUTIONS_PROCESS|NODES_EXCLUDE|workflow|={{|expression|code node|execute command|shell|credentials" .
npm ls n8n
pnpm why n8n
yarn why n8n
docker image ls | rg 'n8n|n8nio'

Do not run crafted expression payloads, print workflow credentials, or export production execution data during triage.

Remediation strategy

  • Upgrade every controlled n8n runtime to 1.123.17+ on the 1.x line or 2.5.2+ on the 2.x line.
  • Pin explicit patched image tags or digests instead of floating tags that can drift between deploy and review.
  • Regenerate lockfiles, image references, rendered deployment manifests, SBOMs, dependency reports, and release metadata so reviewers can see the resolved runtime is patched.
  • Until the upgrade is deployed, restrict workflow creation, import, and editing to fully trusted administrators only. Treat this as containment, not a fix.
  • Harden n8n workers by reducing OS privileges, file-system mounts, metadata service access, outbound network reach, and long-lived credentials available to workflow execution.
  • Review workflow edit history and execution logs for suspicious expression changes. Rotate credentials exposed to vulnerable workers if suspicious activity is found.

The prompt

You are remediating CVE-2026-25049 / GHSA-6cqr-8cfr-67f8, a critical n8n
expression-evaluation escape that can lead to command execution by an
authenticated workflow author. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades every repository-controlled
  n8n runtime, preserves the intended release line, adds deployment checks, and
  documents short-term containment and operator cleanup, or
- TRIAGE.md if this repository does not own an affected n8n runtime or cannot
  safely patch the affected deployment.

## Rules

- Scope only CVE-2026-25049 / GHSA-6cqr-8cfr-67f8 and directly related n8n
  runtime hardening.
- Distinguish n8n server/runtime deployments from n8n API clients, SDK
  wrappers, workflow exports, and documentation.
- Do not run proof-of-concept expressions, shell commands through n8n, live
  workflow probes, or exploit-like payloads.
- Do not print, snapshot, or commit n8n credentials, execution data, workflow
  secrets, OAuth tokens, webhook URLs, cookies, SSH keys, source-control
  credentials, customer data, or environment secrets.
- Do not remove workflow validation, audit logging, provenance checks, or
  credential protections to make the finding disappear.
- Do not auto-merge.

## Steps

1. Inventory every n8n runtime reference controlled by this repository:
   package manifests, lockfiles, Dockerfiles, compose files, Helm values,
   Kubernetes manifests, Terraform, Ansible, runner images, release scripts,
   SBOMs, generated dependency manifests, workflow bundles, and runbooks.
2. Determine whether any deployable n8n runtime resolves to:
   - `n8n <1.123.17`;
   - `n8n >=2.0.0, <2.5.2`.
3. If the repository only calls an externally owned n8n service or stores
   workflow exports for another platform team, stop with `TRIAGE.md` naming the
   owner, checked evidence, and required fixed versions.
4. Upgrade vulnerable runtimes on their existing release line:
   - `1.x` deployments to `1.123.17+`;
   - `2.x` deployments to `2.5.2+`;
   - floating image tags to explicit patched tags or digests.
5. Regenerate the repository's normal generated artifacts: lockfiles, rendered
   deployment manifests, container metadata, image digests, SBOMs, dependency
   reports, and release documentation.
6. Search configuration and workflow assets for exposure evidence:
   - users or roles that can create, import, or edit workflows;
   - seeded workflow templates and stored workflow exports with expression
     parameters;
   - code, execute-command, shell, Git, SSH, file-system, HTTP, database, cloud,
     or credentialed integration nodes reachable from workflow authors;
   - worker service accounts, mounted secrets, metadata endpoints, and internal
     network routes available to n8n execution.
7. Add a repository-owned guard where practical:
   - a deployment-render test, policy check, or CI assertion that rejects n8n
     versions below `1.123.17` or in `2.0.0` through `2.5.1`;
   - a non-secret check that workflow-author restriction settings render
     correctly when temporary containment is enabled;
   - documentation for the exact fixed version or digest reviewers should see.
8. Add a PR body section named `CVE-2026-25049 operator actions` that states:
   - n8n versions before and after;
   - whether workflow creation/import/editing is restricted to trusted users
     until rollout completes;
   - whether expression-heavy workflows, code/command-capable nodes, or
     host-interacting nodes exist;
   - which worker privileges, file-system mounts, metadata access, and outbound
     network paths were reduced or must be reduced outside this repo;
   - whether credential rotation or incident review is required;
   - which validation commands and dependency scans passed.
9. If immediate upgrade is blocked, add temporary containment where this repo
   controls it:
   - restrict workflow creation, import, and editing to trusted administrators;
   - disable or quarantine high-risk workflow templates;
   - reduce n8n worker OS privileges, file-system mounts, internal network
     access, metadata service access, and long-lived credentials;
   - document residual risk because containment does not fully remediate the
     expression escape.
10. Run available validation: package-manager install check, lockfile
    integrity, unit tests, workflow import/export checks, lint/typecheck,
    container build, deployment rendering, SBOM refresh, and dependency/security
    scans.
11. Use PR title:
    `fix(sec): remediate CVE-2026-25049 in n8n`.

## Stop conditions

- The repository does not deploy or package n8n.
- The n8n runtime is owned by another team or vendor and cannot be patched here.
- A fixed version cannot be consumed without a broader n8n migration.
- Validating exposure would require executing exploit-like expressions,
  workflow command execution, production webhook calls, or live credentialed
  probes.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades n8n, refreshes deployment artifacts, restricts workflow authoring during rollout, hardens workers, and documents credential/operator review.
  • Or a TRIAGE.md file that lists inspected packages/images/manifests, workflows, owner, observed version, expression-author boundary, required fix, and residual risk.
  • The output must include exact validation commands and must not run crafted expression payloads, print workflow credentials, export production execution data, or weaken worker isolation.

Verification - what the reviewer looks for

  • No deployable n8n runtime remains below 1.123.17 or in 2.0.0 through 2.5.1.
  • Package manifests, lockfiles, image tags/digests, SBOMs, and rendered deployment manifests all resolve to a patched n8n release.
  • The PR states who can create, import, and edit workflows during rollout.
  • Runtime hardening is addressed separately from version upgrade, especially worker privileges, mounted secrets, metadata access, and internal egress.
  • The change avoids exploit execution and does not expose workflow secrets, execution data, or credentials in logs.
  • Tests, builds, deployment rendering, and dependency scans pass or unrelated failures are documented.

Watch for

  • Repositories that pin n8n in several places, such as chart values, Docker images, compose files, and lockfiles.
  • Treating workflow-author restrictions as a permanent fix.
  • Assuming an internal n8n instance is safe while semi-trusted users can edit workflows.
  • Leaving high-privilege worker containers, broad mounts, or metadata-service egress untouched after upgrading.
  • Workflow fixtures or exports that keep expression-heavy high-risk paths hidden from dependency scanners.

References