n8n EUVD-2026-101723

Exploitation requires a victim-authored n8n workflow that uses version 1 of the Microsoft SQL node AND binds untrusted external input (explicitly called out: webhook fields) into the node's Query field via an expression, so that the value is concatenated into SQL text without parameterisation. This specific insecure-workflow configuration is the attack requirement (AT:P in the provided CVSS 4.0 vector) and is the key limiting factor: default installations, workflows that do not expose the MSSQL node to external input, or workflows using parameterised inputs are not exploitable. Affected only on n8n before 2.41.4 and on the 2.42.x line before 2.42.1. Where the condition is met, no authentication or user interaction is needed (PR:N/UI:N) and the injected SQL runs with the stored database credential's privileges.

The provided CVSS 4.0 base score is 7.0 (High), driven by a network attack vector (AV:N), low complexity (AC:L), no privileges (PR:N) and no user interaction (UI:N), but critically gated by AT:P - an attack requirement indicating that exploitation depends on a specific precondition, namely a workflow that binds untrusted input (e.g. webhook fields) into the Query field of the vulnerable Microsoft SQL node v1. The impact metrics are telling: the n8n host itself sees only low confidentiality impact (VC:L, VI:N, VA:N), while the subsequent system - the connected SQL Server database - sees high confidentiality and integrity impact and low availability impact (SC:H/SI:H/SA:L), reflecting classic SQL injection consequences against the backend DB with the stored credential's privileges. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided in the input, so exploitation probability and real-world exploitation status cannot be quantified. This is a genuine high-severity issue for environments that have built workflows feeding untrusted webhook data into the MSSQL node, but it is NOT a drop-everything universal risk: the AT:P requirement means default or well-designed workflows are not exposed, so this is closer to a configuration-dependent high-CVSS issue than an unconditional unauthenticated RCE-class flaw. Note the terminology tension to verify: the description states 'unauthenticated external callers can execute arbitrary SQL,' which aligns with PR:N, yet exploitation realistically depends on the victim having authored a vulnerable workflow - confirm the exposed-workflow assumption against your own n8n deployment.

An organization runs an n8n workflow (version 1 of the Microsoft SQL node, n8n before 2.41.4 or 2.42.0-2.42.0) that takes input from a public webhook trigger and substitutes a webhook field value directly into the Query field expression. An unauthenticated external caller sends a crafted request to that webhook endpoint containing SQL metacharacters, which are concatenated into the SQL text without parameterisation and executed against the connected SQL Server with the stored credential's privileges. No public exploit identified at time of analysis, but the injection pattern is trivially reproducible given a known vulnerable workflow.