CVE-2026-77080 is a high severity (8.8) command injection flaw in n8n's Snowflake node. Free-form queries reached the Snowflake SDK without n8n's file access limits, so a user with usable credentials could upload a host file or overwrite one. n8n before 1.123.69, 2.33.4 and 2.34.1 is affected. Upgrade to those versions or later.
What's affected
The record says n8n before 1.123.69, 2.x 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 1.123.69, 2.33.4 and 2.34.1 or later.
The component is the Snowflake node's Execute Query input. The attacker needs an authenticated n8n account and usable Snowflake credentials.
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 search workflows for the Snowflake node and note who can edit them.
GitHub lists these temporary mitigations in the advisory:
- Restrict n8n instance access to fully trusted users only.
- Disable the Snowflake node by adding n8n-nodes-base.snowflake to the NODES_EXCLUDE environment variable.
- Run the n8n process under a dedicated low-privilege user account, to limit the impact of arbitrary file access.
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 1.123.69, 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
The Snowflake node passed free-form query text to the Snowflake SDK, including the SDK's client-side commands, and skipped the file access restrictions n8n applies elsewhere. Those commands can move files between the local host and a Snowflake stage, so a user could send a local file out or replace an existing one. The record files this under CWE-78, OS command injection, because the input reaches a command interpreter that does more than a plain query.
The lesson is about trust boundaries: a node that says it runs a query actually runs a small language with side effects on the host. A dedicated low-privilege account for the n8n process is a good habit even after you patch. The record does not mark it as a CISA KEV entry.
Quick check
What is the quick mitigation?
Add n8n-nodes-base.snowflake to NODES_EXCLUDE to disable the node, if you do not need it. It is a stopgap, not a fix.
What does the attacker need?
An n8n account and usable Snowflake credentials, per the record.
Sources
Last reviewed: 18 October 2026.