EUVD-2026-27113
GHSA-hp3c-vfpm-q4f7
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
6DescriptionGitHub Advisory
Impact
The fix for GHSA-f3f2-mcxc-pwjx did not cover the Snowflake node or the legacy MySQL v1 node. Both nodes construct SQL queries by directly interpolating user-controlled table names, column names, and update keys into query strings without identifier escaping, enabling SQL injection against the connected database.
Exploitation requires a specific workflow configuration:
- The Snowflake or MySQL v1 node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into identifier fields such as table name, column name, or update key.
Successful exploitation could allow data exfiltration, modification, or deletion on the downstream database.
Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Migrate workflows from the legacy MySQL v1 node to the MySQL v2 node, which already implements identifier escaping.
- Disable the Snowflake node by adding
n8n-nodes-base.snowflaketo theNODES_EXCLUDEenvironment variable. - Avoid passing unvalidated external user input into table name, column name, or update key fields via expressions in the affected nodes.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
AnalysisAI
SQL injection in n8n Snowflake and legacy MySQL v1 nodes allows authenticated users with workflow creation permissions to execute arbitrary SQL against connected databases by injecting malicious table names, column names, or update keys via expression inputs. This vulnerability affects n8n versions before 1.123.32, 2.17.4, and 2.18.1; successful exploitation enables data exfiltration, modification, or deletion. The flaw represents an incomplete fix to a prior SQL injection vulnerability (GHSA-f3f2-mcxc-pwjx) that already patched MySQL, PostgreSQL, and SQL Server nodes but overlooked the Snowflake node and legacy MySQL v1 implementation.
Technical ContextAI
n8n is a workflow automation platform that constructs and executes database queries through visual node configurations. The Snowflake and legacy MySQL v1 nodes interpolate user-controlled identifiers (table names, column names, update keys) directly into SQL query strings without escaping, violating SQL identifier quoting standards. Unlike parameterized prepared statements which separate SQL logic from data, direct string interpolation treats user input as executable SQL syntax. When expressions (dynamic inputs from forms, webhooks, or workflow variables) flow into identifier fields, an attacker can break out of the intended identifier context and inject arbitrary SQL clauses. This occurs because identifiers in SQL (table and column names) cannot be safely parameterized like data values; they require proper quoting (backticks, double quotes, or brackets depending on database dialect) or validation. The prior vulnerability (GHSA-f3f2-mcxc-pwjx, fixed in n8n 2.4.0 for MySQL, PostgreSQL, and SQL Server) demonstrates that this class of flaw had been partially addressed but incompletely - the fix did not extend to all affected database connectors.
RemediationAI
Vendor-released patches: upgrade to n8n version 1.123.32, 2.17.4, or 2.18.1 or later depending on your current branch. The patch implements identifier escaping in the Snowflake and legacy MySQL v1 nodes to prevent SQL injection. For immediate mitigation prior to patching, administrators should implement the following controls, noting their trade-offs: (1) Restrict workflow creation and editing permissions to fully trusted users only - this limits the attacker profile but reduces workflow development agility and may not be feasible in large organizations with many designers; (2) Migrate existing workflows from the legacy MySQL v1 node to the MySQL v2 node, which already includes identifier escaping - this requires workflow reconfiguration and testing but eliminates vulnerability in that specific node; (3) Disable the Snowflake node entirely by adding n8n-nodes-base.snowflake to the NODES_EXCLUDE environment variable - this eliminates the Snowflake attack surface but prevents all Snowflake integrations until upgrade is completed; (4) Implement strict input validation in workflows by avoiding expression-based inputs to identifier fields (table names, column names, update keys) and instead hardcoding these values or using dropdown/selection controls that do not permit user input - this is the most operationally complex mitigation but provides defense-in-depth if combined with other controls. The n8n advisory is available at https://github.com/n8n-io/n8n/security/advisories/GHSA-hp3c-vfpm-q4f7.
Same weakness CWE-89 – SQL Injection
View allShare
External POC / Exploit Code
Leaving vuln.today