CVE-2026-77068 is a high severity (8.8) path traversal in n8n's MCP node-schema loader that lets an authenticated member run code in the main n8n process. n8n before 2.33.4 and 2.34.x before 2.34.1 are affected. Upgrade to 2.33.4 or 2.34.1 or later.
What's affected
The record says n8n before 2.33.4 and 2.34.x before 2.34.1 are affected. GitHub's advisory lists the same range and says the patched versions are 2.33.4 and 2.34.1 or later.
The component is the @n8n/workflow-sdk node-schema loader used for MCP node-schema loading. The attacker needs an authenticated account with global:member privileges. The record and advisory describe the code execution as happening in the n8n main process.
Where sources differ. The advisory scores this High 8.7 on CVSS 4.0, and the record's CVSS 3.1 score is different, so the two numbers describe the same flaw through different scoring models.
How to check if you're exposed
Find every n8n instance, including ones a team stood up on its own, and print the version:
n8n --version
docker exec <container> n8n --version
npm ls -g n8n
The first works where the CLI is installed, the second for a Docker container, the third for a global npm install. Compare with the patched versions: 1.123.69 on the 1.x line, 2.33.4 on 2.33, and 2.34.1 on 2.34. Also check whether Instance-level MCP is turned on, since the flaw sits in the MCP schema loading path.
GitHub lists these temporary mitigations in the advisory:
- Restrict n8n instance access to fully trusted users only.
- Disable Instance-level MCP if it is not required.
- Run the n8n process under a dedicated low-privilege OS user account, to limit what any file access can do.
GitHub is clear that they do not fully remediate the risk and are short-term measures. A dependency scan is the quickest way to find this kind of component across many projects. Safeguard's free in-browser scan at gold.safeguard.sh/scan checks your dependencies against known CVEs, and reachability analysis helps you separate libraries your code actually calls from ones that only sit in the tree.
What to do now
- Upgrade n8n to 2.33.4, or 2.34.1 or later, whichever matches your release line.
- Until you can, apply the advisory's temporary mitigations, which GitHub says reduce risk without fully fixing it.
- Review who has accounts on the instance and what role each holds. Remove people who do not need access.
- Look through existing workflows for the feature involved, and confirm nothing unexpected has been added.
- Re-check the version afterward and record it.
Why it matters
n8n's loader built a schema module path directly from the node type string a caller supplies, without checking for path traversal sequences. A user could therefore point the loader at files outside the intended folder, and the code in them ran in the main process. This is path traversal, filed under CWE-22, and here it ends in code execution because the loaded file is executed, not just read.
The attacker needs a member account, which is a low bar on instances where many people build automations. n8n often holds credentials for many other services, so code execution in its main process can reach well beyond the host. The record does not mark it as a CISA KEV entry.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this need an admin account?
No. The record says an authenticated user with global:member privileges is enough.
What is the quick mitigation if I cannot upgrade today?
GitHub suggests limiting access to trusted users, disabling Instance-level MCP if you do not need it, and running n8n as a low-privilege OS user. None of these fully fixes the issue.
Sources
Last reviewed: 18 October 2026.
