CVE-2026-110840 in n8n
Summary
by MITRE • 10/15/2026
n8n before 2.41.4 and 2.42.x before 2.42.1 contains an SQL injection vulnerability in version 1 of the Microsoft SQL node, which substitutes Query field expression values directly into SQL text without parameterisation. When a workflow binds untrusted input such as webhook fields to the Query field, unauthenticated external callers can execute arbitrary SQL against the connected database with the stored credential's privileges.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in n8n versions prior to 2.41.4 and version 2.42.x prior to 2.42.1 represents a critical security flaw within the Microsoft SQL node, specifically affecting its first iteration of implementation. This component is designed to facilitate database interactions for workflow automation tasks, allowing users to execute queries against Microsoft SQL Server instances. The core technical deficiency lies in how the Query field processes input data. Instead of employing parameterized queries or prepared statements, which are industry-standard practices for preventing injection attacks, the node directly substitutes user-supplied expression values into the raw SQL text string. This lack of proper sanitization and separation between code and data creates a classic injection vector that attackers can exploit to manipulate database operations.
The operational impact of this flaw is severe due to the nature of workflow automation systems like n8n. These platforms often handle sensitive business logic and connect to critical backend infrastructure. When an administrator configures a workflow, they may bind untrusted input sources, such as webhook endpoints or HTTP request parameters, directly into the Query field for dynamic execution. If these inputs are not strictly validated on the server side before being passed to the SQL node, external attackers can inject malicious SQL commands. Because n8n executes queries using the credentials configured in the workflow connection settings, successful exploitation grants the attacker full access privileges associated with that database account. This effectively bypasses authentication mechanisms entirely for any unauthenticated caller who discovers a vulnerable webhook or endpoint linked to this specific node configuration.
From an industry standards perspective, this vulnerability is classified under CWE-89, which denotes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The attack vector aligns with the ATT&CK technique T1190, Exploit Public-Facing Application, particularly when the vulnerable webhook or API endpoint is exposed to external networks. Furthermore, if the attacker leverages this access to extract sensitive data from the database, it falls under CWE-862 and relates to ATT&CK techniques such as Data from Information Repositories (T1005) or Unsecured Credentials (T1552), depending on whether they are reading existing data or attempting to harvest stored credentials for lateral movement. The severity is compounded by the fact that n8n is frequently deployed in environments where automation workflows bridge multiple systems, potentially exposing not just one database but a network of interconnected services if credential reuse occurs.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary and most effective solution is to upgrade the n8n instance immediately to version 2.41.4 or later, where this specific implementation flaw has been corrected by implementing proper parameterization for SQL queries within the Microsoft SQL node. For organizations unable to patch instantly due to operational constraints, a temporary workaround involves strictly validating all inputs that are bound to the Query field using allowlists of permitted characters and patterns before they reach the workflow execution engine. Additionally, administrators should audit existing workflows to identify any instances where untrusted external data is directly mapped to SQL query parameters without intermediate validation steps. Implementing Web Application Firewalls (WAFs) with rules specifically tuned for SQL injection signatures can also provide a layer of defense-in-depth, although this should not be relied upon as the sole mitigation given that sophisticated attackers may bypass basic WAF rules through obfuscation techniques.