n8n, a widely deployed workflow-automation platform, carries three CVEs that trace to the same underlying weak point: its expression engine, which evaluates user-authored code inline in workflow steps, didn’t reliably keep that code contained. One of the three is actively exploited and KEV-listed with a near-maximum CVSS score; the other two are sandbox-escape bugs in the same legacy expression engine, patched in the same release wave.
CVE-2025-68613: actively exploited RCE via improper control of dynamically-managed code resources
Present from n8n 0.211.0 onward. Per the National Vulnerability Database record, workflow expressions supplied by an authenticated user during configuration could be evaluated in a runtime context that was not sufficiently isolated from the underlying n8n process, rather than in a properly sandboxed evaluator. CWE-913 (Improper Control of Dynamically-Managed Code Resources). CVSS base 9.9 (critical; vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Impact: an authenticated attacker able to configure a workflow could execute arbitrary code with the privileges of the n8n process, up to full instance compromise, data exposure, and workflow tampering. This CVE is confirmed actively exploited — it’s listed in both the CISA KEV catalog and VulnCheck KEV (added 2026-01-09), and carries an EPSS score of 0.991, indicating near-certain observed or imminent exploitation. Fixed in 1.120.4, 1.121.1, and 1.122.0. Confidence: high — NVD’s technical analysis and two independent KEV catalogs’ exploitation confirmation corroborate each other.
CVE-2026-86076: expression sandbox escape via class-field sanitizer rebinding
Per the GitHub Advisory Database record, the legacy expression compiler’s sanitizer (a PrototypeSanitizer hook) resolved through a dynamically-scoped this reference and did not reject reserved class-member names. Defining a class field with a specific reserved name could rebind the sanitizer itself and reach the underlying Function constructor. CWE-94 (Code Injection). CVSS base 8.8 (high; vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Impact: an expression author could execute code in the backend n8n process, and in some contexts run script in the browser session of whoever opened the affected workflow in the editor — a broader blast radius than a backend-only escape. Fixed in 1.123.76, 2.37.7, and 2.38.2. Confidence: medium — NVD’s description closely mirrors the GitHub Advisory Database’s CNA-supplied text rather than reflecting independent analysis, so this is treated as effectively single-sourced despite appearing under two source IDs.
CVE-2026-86083: expression sandbox escape via shared builtin tampering and code-printer injection
Per the GitHub Advisory Database record, two stages of the legacy expression engine’s code generation called the mutable global JSON.stringify at generation time — once when printing string literals, once when interpolating timezone data into generated source. An expression that replaced this shared global could cause later-generated source text to include attacker-controlled, executable code instead of literal data. The record notes the default vm expression engine on patched releases is not affected — this is specific to instances still running the legacy engine. CWE-94 (Code Injection). CVSS base 8.8 (high; vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Impact: on instances still using the legacy expression engine, an expression author could achieve code execution in the backend n8n process. Fixed in 1.123.76, 2.37.7, and 2.38.2. Confidence: medium — same single-effective-source caveat as above.
Confidence and evidence gaps
CVE-2025-68613 reaches high confidence because NVD’s technical write-up and two independently maintained KEV catalogs (CISA’s and VulnCheck’s) corroborate both the mechanism and the fact of active exploitation. The other two CVEs each carry an NVD description row in the ledger alongside a GitHub Advisory Database row, but comparing the actual text shows NVD closely restating the same GitHub-Advisory-CNA-supplied analysis rather than an independent write-up — so per our own confidence standard (corroboration means two assessments that could have caught different errors, not the same text relayed twice), we’re scoring both medium, not high, despite the ledger technically showing two source IDs.
Why this matters
All three CVEs sit in the same failure category we’ve flagged repeatedly across this batch of AI/automation-tooling coverage: a component that evaluates user-supplied code assumed its own sandbox held, and it didn’t. n8n’s expression engine is exposed to anyone who can author or edit a workflow — in many deployments, that’s a broad set of internal users, not just administrators — which is exactly why CVE-2025-68613’s real-world exploitation matters more than its CVSS score alone would suggest. Teams running n8n should treat “workflow authoring” as a privileged capability requiring the same access-control discipline as shell access, not a low-risk configuration task.
Frequently Asked Questions
Is CVE-2025-68613 being actively exploited right now? Yes. It’s listed in both the CISA KEV catalog and VulnCheck KEV, with an EPSS score of 0.991 — among the highest exploitation-probability scores our source data tracks.
Do the two sandbox-escape CVEs require the legacy expression engine specifically?
CVE-2026-86083’s record explicitly states the default vm expression engine on patched releases isn’t affected, scoping that flaw to instances still on the legacy engine. CVE-2026-86076’s record doesn’t state an equivalent scoping caveat.
Which n8n versions fix all three CVEs? CVE-2025-68613 is fixed in 1.120.4, 1.121.1, and 1.122.0. CVE-2026-86076 and CVE-2026-86083 are both fixed in 1.123.76, 2.37.7, and 2.38.2 — instances should update to whichever of these lines matches their current major/minor branch.
Data sourced from the National Vulnerability Database (NVD), CISA KEV, VulnCheck KEV, and the GitHub Advisory Database, evaluated September 2026. This product uses the NVD API but is not endorsed or certified by the NVD. See more vulnerability intelligence.