CVE-2026-56351 is a high severity (CVSS 8.2) SQL injection in the MySQL, PostgreSQL and Microsoft SQL nodes of n8n before version 2.4.0. An authenticated user who can build workflows can inject SQL through table or column names. Upgrade to 2.4.0 or later.
What's affected
The n8n advisory (GHSA-f3f2-mcxc-pwjx) lists the npm package n8n, versions before 2.4.0, patched in 2.4.0.
The affected nodes are the MySQL, PostgreSQL and Microsoft SQL nodes. The cause, per the advisory, is that identifier values such as table and column names were not escaped when queries were built from node configuration parameters.
The attacker must be authenticated and permitted to create or change workflows, and must have access to a database credential. The CVSS vector reflects that with PR:L and high attack complexity.
How to check if you're exposed
Check your n8n version, from the About n8n dialog in the editor or with npm.
npm ls n8n
Docker users should check the image tag. Anything below 2.4.0 is affected.
Also see which workflows use the three database nodes, and who can edit them. A workflow that builds table or column names from outside data deserves a second look even after you upgrade.
Run the free in-browser dependency scan at https://gold.safeguard.sh/scan against your manifest or lockfile. It lists vulnerable packages without installing anything.
What to do now
- Upgrade n8n to 2.4.0 or later.
- If you cannot upgrade at once, limit workflow creation and editing to fully trusted users.
- As another stopgap, exclude the three node types by adding n8n-nodes-base.mySql, n8n-nodes-base.postgres and n8n-nodes-base.microsoftSql to the NODES_EXCLUDE environment variable. The advisory says this reduces the risk but does not fully remove it.
- Give workflow database credentials only the permissions each workflow needs.
- Review database audit logs for unexpected queries from the n8n service account.
Why it matters
The weakness is CWE-89, SQL injection. Data supplied by a user becomes part of a query's structure instead of staying a value. Parameterized queries protect values, which is why people expect them to be safe. Identifiers such as table and column names cannot be bound as parameters, so they need their own escaping. The advisory describes exactly that gap.
Teams often assume that if they use the parameter fields, they are safe. This flaw shows why the layer below should be checked too. Least privilege on the database account limits the damage when it fails. The record is not in CISA's Known Exploited Vulnerabilities catalog.
Quick check
Does the NODES_EXCLUDE workaround fix the problem?
The advisory says its workarounds do not fully remediate the risk and should be short term measures. Upgrading is the fix.
Sources
Last reviewed: 19 October 2026.
