n8n — 10-advisory security batch: host-level RCE via expression evaluator, SSO privilege escalation to instance owner, AI-agent sandbox bypass (plus a second 10-advisory batch two weeks later)

View raw markdownEdit on GitHub ↗

TL;DR

n8n — the workflow-automation platform this repo already tracks as a "central credentials cache" (see n8n Ni8mare, CVE-2026-21858) — quietly published 10 security advisories in one day (2026-07-08) on its own GitHub Security Advisories page, none yet carrying a CVE. The two most serious: a sanitizer bypass in the legacy expression evaluator giving authenticated users host-level code execution (CVSS 4.0: 8.9) and a Token Exchange privilege-escalation bug that mints full-admin Public API tokens (CVSS 4.0: 8.9). All are fixed in n8n 1.123.64 / 2.29.8 / 2.30.1. A separate, narrower Token Exchange cross-issuer impersonation bug (CVE-2026-59208) patched three weeks earlier (2026-06-24) only reached mainstream security-press coverage on 2026-07-16, well after this repo's last sweep — both belong in the same "n8n's Enterprise Token Exchange feature has had a rough July" story.

What happened

n8n's own GitHub Security Advisories page published ten advisories on 2026-07-08, all fixed in the same release train (1.123.64, 2.29.8, 2.30.1, or later). As of this sweep, none has an assigned CVE ("No known CVE" on each GHSA page), and no independent security-press outlet has covered this specific batch — sourcing here is n8n's own vendor advisory pages, fetched directly. Ranked by CVSS 4.0 score:

  • GHSA-pm35-fqvh-cq5g — Legacy Expression Evaluator Sanitizer Bypass Leads to Authenticated Code Execution (CVSS 8.9, High). The default/legacy expression engine's computed-member sanitizer can be bypassed, letting an authenticated user with workflow create/modify permissions achieve host-level code execution as the n8n process. Affects < 1.123.64 / < 2.29.8 / < 2.30.1. Workaround: switch to the non-legacy engine (N8N_EXPRESSION_ENGINE=vm) or restrict instance access to trusted users.
  • GHSA-777w-rpr6-c52h — Privilege Escalation and Code Execution via Full Public API Key Scope Assignment to Token Exchange JWTs (CVSS 8.9, High). JWTs minted through the Token Exchange feature receive full Public API permissions regardless of the actual user's role, letting a low-privileged attacker with a valid external JWT create/delete users and escalate roles. Requires Token Exchange + Public API enabled and a JWT accepted by a configured trusted key.
  • GHSA-9wcp-9r3j-383q — Stored DOM XSS via Resource Locator cachedResultUrl (CVSS 8.4, High). A persisted cachedResultUrl field is passed to window.open() with no scheme validation; a malicious workflow can plant a JS payload that executes in a victim's browser when they interact with the workflow's external links.
  • GHSA-35q8-9mj6-wjmf — SSO Instance-Role Provisioning Allows Privilege Escalation to Instance Owner (CVSS 7.7, High). With Enterprise SSO instance-role provisioning enabled (N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE, off by default), n8n didn't block assignment of the global:owner role during SSO login the way other identity paths do — an attacker who controls the instance-role claim at the IdP can log in as full admin.
  • GHSA-x5vx-c2c8-m3w9 — AI Agents Project Viewer Privilege Escalation via run_node_tool (CVSS 7.2, High). Read-only Project Viewer users could invoke agent node-execution tools without the agent:execute scope being checked against their actual permissions, letting them run arbitrary tool nodes and read credential secrets they weren't authorized for — extending to arbitrary command execution where Execute Command/SSH nodes are enabled.
  • GHSA-9w78-79q7-r4fp — Authenticated SSRF via Dynamic Node Parameters Endpoints Allows Internal Network Access (CVSS 6.3, Moderate). Dynamic node-parameter endpoints lacked authorization checks and accepted absolute URLs overriding declared base URLs, letting any authenticated user force the server to issue requests to arbitrary internal targets (SSRF protection is disabled by default).
  • GHSA-fpg6-x68q-5793 — computer-use Shell Sandbox Not Enforced on Linux and Windows (CVSS 5.5, Moderate). The @n8n/computer-use package's shell tool enforced sandboxing on macOS only; on Linux/Windows, shell commands from the agent ran with no filesystem or network restrictions. Fix adds bubblewrap sandboxing on Linux and disables the shell tool where sandboxing can't be established.
  • GHSA-89gh-3pgc-v5h2 — Custom Header Credential Values Leaked in Plaintext into LLM Node Execution Data (CVSS 5.1, Moderate). Custom HTTP headers on LLM sub-node credentials (OpenAI, Anthropic, Lemonade) appear masked in the UI but are written in plaintext into execution data — any authenticated user who can view execution records can read the underlying API keys/secrets, and that data persists in exports.
  • GHSA-q5xf-xhwf-cwqf — Member-Level Users Can Execute Other Users' MCP Server Trigger Workflows via Missing OAuth Authorization Check (CVSS 5.1, Moderate). n8n's OAuth 2.1 implementation let a member-level user register an OAuth client, self-approve consent for another user's OAuth2-protected MCP Server Trigger workflow, and obtain a token — executing that workflow (and its stored credentials/connected integrations) under the real owner's identity, breaking project isolation.
  • GHSA-33q9-f52j-gc75 — Unauthenticated Endpoint Allows Cancellation of Any User's Active Test Webhook (CVSS 5.1, Moderate). DELETE /rest/test-webhook/:id is processed before authentication middleware runs, letting an unauthenticated caller who knows a workflow ID cancel in-progress test webhook sessions. No impact on production webhooks or persisted data.

Related, earlier disclosure — Token Exchange cross-issuer impersonation (CVE-2026-59208, GHSA-mq3m-f8x3-579w, CVSS 4.0: 7.6): published to n8n's own advisories on 2026-06-24 (fixed same day in 2.27.4/2.28.1), this is a different Token Exchange bug: when multiple trusted external issuers are configured, identity resolution used only the JWT sub claim and ignored iss, letting an attacker with a valid token from one trusted issuer authenticate as any victim sub under a different issuer. It only reached mainstream coverage via The Hacker News on 2026-07-16 — nine days after n8n's own fix shipped, and after this repo's 2026-07-16 sweep. Included here for context since it's part of the same "Token Exchange had a rough July" pattern as GHSA-777w-rpr6-c52h above, but it predates and is independent of the 2026-07-08 batch.

Am I affected?

n8n --version

You're exposed if you self-host n8n < 1.123.64 / < 2.29.8 / < 2.30.1 (check your branch) and any of: - You allow non-admin users to create/modify workflows (legacy expression evaluator RCE — the highest-severity item here, and the legacy engine is the default). - You use Token Exchange + Public API together, or Token Exchange with multiple trusted issuers. - You use Enterprise SSO with N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE enabled. - You share team projects with agent nodes to lower-privileged Project Viewer members. - You use @n8n/computer-use on Linux or Windows. - You store LLM sub-node credentials (OpenAI, Anthropic, Lemonade) with custom HTTP headers. - You use OAuth2-authenticated MCP Server Trigger workflows shared across users.

If you are affected

  1. Upgrade to n8n ≥ 1.123.64 / ≥ 2.29.8 / ≥ 2.30.1 (whichever matches your branch) — this closes all 10 items in the July 8 batch.
  2. If on an older Token Exchange-enabled build, also confirm you're ≥ 2.27.4 / ≥ 2.28.1 for CVE-2026-59208.
  3. Until you can upgrade: switch off the legacy expression engine (N8N_EXPRESSION_ENGINE=vm), disable SSO instance-role provisioning, and restrict instance access to trusted users only.
  4. Rotate any LLM-provider API keys stored as custom HTTP headers on OpenAI/Anthropic/Lemonade credentials — they were written in plaintext into execution data readable by any authenticated user (GHSA-89gh-3pgc-v5h2). Treat this the same as any other credential-hub exposure.
  5. Audit execution history and Token Exchange logs for anomalous access before you patched.
  6. See playbooks/rotating-cloud-credentials.md.

Prevention

  • Treat n8n (and any workflow-automation/iPaaS broker) as a central credentials cache — the union of every downstream OAuth token and API key it holds is reachable through a single privilege-escalation or RCE bug in the platform itself, not just through the workflows it runs.
  • Don't grant workflow create/modify permissions more broadly than necessary; the legacy expression evaluator's RCE requires only that permission level, not admin.
  • Don't share agent-enabled projects with viewer-level teammates unless you've confirmed your version has GHSA-x5vx-c2c8-m3w9 fixed.
  • → prevention/credential-hygiene.md, prevention/mcp-hygiene.md

Sources

Sourcing note: the ten 2026-07-08 advisories are corroborated only by n8n's own GitHub Security Advisories (a single vendor domain, ten separate first-party pages, no assigned CVEs yet). No independent aggregator or research-firm coverage of this specific batch was found as of 2026-07-17. Treated here as a verified vendor disclosure (not a disputed incident claim) given the precision of the CVSS vectors and fixed-version data on each page, but flagged per this repo's two-independent-source standard for full advisories.

Update — 2026-07-22: a second 10-advisory batch, two weeks after the first, fixed in a new release train

n8n's own GitHub Security Advisories page published ten more advisories on 2026-07-22 (all authored by the same maintainer, csuermann, as the July 8 batch) — none carry an assigned CVE as of this sweep. All are fixed in n8n ≥ 1.123.67 / ≥ 2.31.5 / ≥ 2.32.1 (a later release train than the July 8 batch's 1.123.64/2.29.8/2.30.1 — upgrading again is required even if you already patched for July 8). Three of the ten were fetched and verified directly; the rest are listed from the advisories index page. Ranked by severity:

  • GHSA-gv7g-jm28-cr3m — Expression sandbox escape via arrow-function bodies enabling command execution (CVSS 4.0: 8.7, High). An authenticated user with workflow create/modify permissions can bypass the expression sandbox using specially crafted arrow functions, triggering arbitrary OS command execution on the n8n host — no user interaction required. This is a different expression-engine bypass from the July 8 batch's legacy-evaluator sanitizer bypass (GHSA-pm35-fqvh-cq5g above); together the two disclosures mean n8n's expression sandbox has had two independent RCE-class escapes patched in the same month.
  • GHSA-rcv6-pvrj-4xcg — Authenticated code execution in the n8n Git node (CVSS 4.0: 8.7, High). An authenticated user with workflow create/execute permissions can stage a malicious local Git repository and exploit default Git hook behavior to execute arbitrary commands as the n8n process user, via the built-in Git node.
  • GHSA-xwx6-jjhv-84p8 — Prototype Pollution via Dot-Notation Field Names Leads to Instance-Wide Denial of Service (High).
  • GHSA-xmc9-4f2h-jf9c — Edit Image Node Format Injection Allows Arbitrary File Write (High).
  • GHSA-cj9h-qx8g-pq2g — Shared-Workflow Editor Can Exfiltrate Credentials via Inline Sub-Workflow JSON (High).
  • GHSA-2x35-3fw4-9jr4 — Send Email Node Arbitrary File Read and SSRF via Nodemailer Content-Object Type Confusion (High).
  • GHSA-9cmh-xcqm-5hqr — Cross-Tenant Module-Cache Poisoning in the JS Task Runner (CVSS 5.8, Moderate). All multi-user instances share one module cache across users' Code-node executions in the JS task runner; a malicious user with Code-node access can poison a cached module and alter other users' Code-node execution results — a cross-tenant isolation break (not a sandbox escape or RCE on its own).
  • GHSA-652q-gvq3-74qv — Snowflake Node executeQuery Operation Allows SQL Injection via Unparameterized Expression Interpolation (Moderate).
  • GHSA-vhf8-cg2h-cg3p — SSRF Protection Bypass via MCP Client Node (Moderate).
  • GHSA-hx4h-vr3m-45vh — Prototype Pollution via VM Expression Engine Sandbox Escape Leads to Denial of Service (Moderate).

Am I affected (update): if you're running n8n 1.123.64–1.123.66, 2.29.8–2.31.4, or 2.30.1–2.32.0 (i.e., already patched for the July 8 batch but not this one), you're still exposed to the two high-severity items above. Upgrade again to ≥ 1.123.67 / ≥ 2.31.5 / ≥ 2.32.1. No independent aggregator coverage of this second batch was found as of this sweep — sourced solely from n8n's own vendor advisory pages, same sourcing caveat as the July 8 batch above.

Sources for this update: n8n GitHub Security Advisories — overview page (fetched directly, 2026-07-22 batch); GHSA-gv7g-jm28-cr3m; GHSA-rcv6-pvrj-4xcg; GHSA-9cmh-xcqm-5hqr — all three fetched and verified directly.

Update — 2026-08-09: GitGuardian finds 4,576 leaked n8n API tokens in public GitHub commits, 321 live instances still accept them; backfills CVE-2026-25053 (Git-node arbitrary file read → encryption-key theft)

GitGuardian published research on 2026-08-05 demonstrating that n8n's "central credentials cache" exposure isn't limited to unpatched CVEs — plain credential hygiene failures are enough on their own. Scanning public GitHub commits, GitGuardian found 4,576 unique n8n API tokens tied to 1,255 hostnames. Of 896 instances that were still reachable at test time, 321 (36%) accepted at least one leaked token — no exploit, no CVE, just an unrotated credential used to authenticate normally. GitGuardian also found 129 internet-accessible instances using known-weak N8N_ENCRYPTION_KEY values.

Why a leaked API token alone is a full compromise, not just unauthorized read access: a valid token lets an attacker enumerate users, read complete workflow definitions and execution data, list stored credential objects (the encrypted blobs, not yet the plaintext secrets), and create or activate new workflows. GitGuardian chained this further using a previously undisclosed-in-this-repo bug — CVE-2026-25053 (GHSA-9g95-qf3f-ggrw, CVSS 9.4) — an OS command injection / arbitrary file read in n8n's Git node: unvalidated core.sshCommand, pathsToAdd, and reference parameters let an authenticated user (including one authenticated only via a leaked API token) run arbitrary system commands or read arbitrary files on the n8n host, including .env. That's enough to extract N8N_ENCRYPTION_KEY and decrypt every stored credential offline — the single value that also feeds JWT signing and instance-ID generation. CVE-2026-25053 was disclosed and fixed independently of this repo's tracking, in n8n 2.5.0 / 1.123.10 (patched ~2026-02, predating the July batches above) — it had not previously appeared in this repo despite being CVSS 9.4; folded in here because GitGuardian's research is what surfaced it to this sweep.

Am I affected (update): if you have ever committed an n8n API token to a public (or since-made-private, but previously public) GitHub repository, treat it as compromised regardless of your current n8n version — rotating the token is necessary even on a fully-patched instance. Separately, confirm you're on n8n ≥ 2.5.0 / ≥ 1.123.10 for CVE-2026-25053, and check whether your N8N_ENCRYPTION_KEY is a default/weak/well-known value rather than a securely generated one.

If you are affected: rotate every n8n API token that has ever appeared in a public commit (search your own repo history, not just current HEAD), rotate N8N_ENCRYPTION_KEY itself (this re-encrypts stored credentials and invalidates JWTs signed with the old key — plan for a brief re-auth of all users), and treat every credential stored in that n8n instance as potentially exposed if the instance was both internet-reachable and running a pre-2.5.0/1.123.10 build. See playbooks/rotating-cloud-credentials.md.

Sources for this update: GitGuardian — n8n Security: How Leaked API Keys Expose Your Encryption Key — primary research, fetched directly: token/hostname/instance counts, weak-encryption-key count, CVE-2026-25053 chaining detail. The Hacker News — Leaked n8n API Tokens Exposed Live Instances to Credential Theft, published 2026-08-05 — independent corroboration. GitHub Advisory Database — GHSA-9g95-qf3f-ggrw (CVE-2026-25053) — CVE↔GHSA pairing verified directly.