CVE-2026-77068
n8n 1.x August 2026 batch: node-schema loader path traversal -> RCE, Snowflake node arbitrary file read/write, resource-locator expression injection, Form-node stored XSS and Filter/Switch ReDoS
- Severity
- critical
- Affected product
- n8n
- Affected versions
- n8n < 1.123.69
- Fixed in
- n8n 1.123.69
- Added to NewScan
- 2026-08-20
- Detected by
- NewScan — free, self-hosted
How NewScan reports it
COMPONENT VERSION RANGE
NewScan fingerprints n8n from its response and reports this CVE when the detected version falls inside the affected range below.
ONE row for the whole 2026-08-20 n8n batch, the Bouncy Castle pattern: every CVE in it is fixed by the same 1.x release (1.123.69), so five rows would be five findings that all say "upgrade to 1.123.69". Named on CVE-2026-77068 (8.7, @n8n/workflow-sdk node-schema loader derives the schema module path from the attacker-supplied node type with no traversal check -> RCE in the n8n main process, global:member is enough). Also covers CVE-2026-77080 (Snowflake node passes free-form Execute Query through to arbitrary file read AND write), CVE-2026-77075 (resource-locator link-preview expression injection), CVE-2026-77072 (Form node completion page stored XSS - the sandbox CSP was applied to the wrong response) and CVE-2026-77082 (Filter/Switch nodes compile user-supplied patterns -> ReDoS). Ranges from the vendor advisories GHSA-6h4x-896x-fw5m / -r4j2-j3wm-q689 / -fh4c-9rr2-p7qc / -rmr5-775f-jvm2 / -q3fv-295f-qfpf: four of the five say `before 1.123.69` for the 1.x line, and only 77068 does not name 1.x at all - it is kept in the row because its fix ships in the same release and the loader it fixes is present in 1.x, but that is the one id here that rests on our reading rather than on an explicit 1.x bound. THE 2.x BRANCHES ARE DELIBERATELY ABSENT and this is the important half: the same advisories bound 2.x at < 2.33.4 and 2.34.x at < 2.34.1, but n8n 2.x publishes NO version anonymously - measured 2026-08-20 against n8nio/n8n:2.34.1 on loopback, where GET /rest/settings returns 8 keys (authCookie, communityNodesEnabled, defaultLocale, enterprise, previewMode, settingsMode, sso, userManagement) with no versionCli, /healthz is {"status":"ok"}, /rest/version is 404 and the 24 KB SPA shell contains no version-shaped string at all. A 2.x row would be permanently dead data, so it is not written; the same measurement means the two existing CVE-2025-68613 2.x rows above cannot fire either (docs/backlog.md). The 1.x source is real and measured the same day: vulhub/n8n:1.65.0 answers /rest/settings with ~40 keys including versionCli 1.65.0, which is the number scan_n8n gates on.
References
Scan for this yourself — local, in-band scanning is free.
Get NewScan (FREE) →