CVE records published for n8n's MCP node-schema RCE and a cross-project credential bypass, both fixed August 5
CVE-2026-77068 (high) and CVE-2026-77073 (medium) reached NVD on 2026-08-20, fifteen days after n8n published both advisories and shipped fixes in 2.33.4 and 2.34.1 on 2026-08-05. The first is code execution in the n8n main process: the MCP node-schema loader built a module path from the attacker-supplied node type string without checking for path traversal. The second let the MCP create_workflow_from_code tool persist cross-project credential references when a node's auth type was an expression.
Two n8n vulnerabilities in the workflow platform's MCP surface received CVE records at NVD on 2026-08-20. Both were disclosed and fixed on 2026-08-05, in n8n 2.33.4 and 2.34.1 - the records trail the fixes by fifteen days.
CVE-2026-77068 (GHSA-6h4x-896x-fw5m, high) is code execution in the n8n main process. The @n8n/workflow-sdk node-schema loader built a schema module path directly from the attacker-supplied node type string without checking for path-traversal sequences, so an authenticated user with global:member privileges could point it at malicious files. n8n's advisory lists restricting instance access, disabling instance-level MCP, and running the process under a low-privilege OS account as short-term mitigations only.
CVE-2026-77073 (GHSA-vfrj-582q-mvcp, medium) is narrower. The MCP create_workflow_from_code tool skipped its cross-project ownership check when a node's authentication type was set to an expression rather than a literal string, letting a caller with a valid MCP Bearer API key and a known credential ID persist a foreign credential reference on a workflow in another project. The advisory states the runtime execution path still blocks the foreign credential from being used, so no secret is exposed and no requests are made with it.
How was this verified, and what are the sources?
Published · last verified · confidence 0.95.
- GHSA-6h4x-896x-fw5m, published 2026-08-05T14:21:22Z, high - states the @n8n/workflow-sdk node-schema loader "derived a node's schema module path directly from the attacker-supplied node type string, without checking for path-traversal sequences", that an authenticated user with global:member privileges could cause "a code execution in the n8n main process", that fixes shipped in 2.33.4 and 2.34.1, and lists workarounds (restrict access to trusted users, disable instance-level MCP, run n8n under a low-privilege OS account) it labels short-term only - accessed
- GHSA-vfrj-582q-mvcp, published 2026-08-05T14:20:33Z, medium - states the MCP create_workflow_from_code tool "did not apply the same expression-awareness guard to credential validation that the runtime execution path uses", so when a node's authentication type was an expression the cross-project ownership check was skipped and a foreign credential reference could be persisted; requires MCP enabled, a valid MCP Bearer API key, and a known target credential ID; states the runtime path "still blocks the foreign credential from being used", so no secret is exposed - accessed
- NVD record CVE-2026-77068, published 2026-08-20T12:16 - RCE via path traversal in the MCP node-schema loader, affecting n8n before 2.33.4 and 2.34.x before 2.34.1 - accessed
- NVD record CVE-2026-77073, published 2026-08-20T12:16 - credential validation bypass in create_workflow_from_code when authentication type is set to an expression, affecting n8n before 2.34.1 - accessed
- n8n release tags n8n@2.33.4 and n8n@2.34.1, both published 2026-08-05 - the fix releases, dating the patches fifteen days before the CVE records - accessed