CVE-2026-118645 in n8n
Summary
by MITRE • 10/28/2026
n8n before 1.123.85, 2.x before 2.43.5, and 2.44.x before 2.44.1 contains a filter injection vulnerability in the Quick Base node, which sends the Where filter to the Quick Base API as raw query text. Attackers supplying untrusted input such as webhook data used to build the filter can make Get Many return every record or Delete remove every record with the workflow credential's privileges.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in n8n versions prior to 1.123.85, 2.x before 2.43.5, and 2.44.x before 2.44.1 represents a critical security flaw within the Quick Base integration node. This issue stems from improper neutralization of special elements used in an SQL or query-based command, specifically categorized under CWE-77: Improper Neutralization of Special Elements used in a Command. In this context, the vulnerability manifests as filter injection rather than traditional code execution, but it shares the same root cause of failing to properly sanitize user-supplied input before incorporating it into a data retrieval or manipulation query structure. The Quick Base node is designed to interact with the Quick Base API by constructing Where filters that dictate which records are retrieved or modified during workflow operations.
The technical flaw lies in how these Where filters are transmitted to the external API. Instead of parameterizing inputs or strictly validating and escaping special characters, n8n passes the filter content as raw query text directly into the HTTP request body sent to Quick Base. This architectural decision means that any input provided by a workflow user, particularly from untrusted sources such as webhook payloads, form submissions, or external API triggers, is interpreted literally by the backend service without adequate sanitization. An attacker who controls this input can inject malicious filter logic that alters the intended scope of the query operation.
The operational impact of this vulnerability is severe due to its potential for data exfiltration and destructive actions. By crafting a specific injection payload within the untrusted input, an adversary can manipulate the logical structure of the Where clause. For instance, by injecting boolean operators or tautologies such as 1=1, the attacker can bypass conditional restrictions entirely. This allows them to force the Get Many operation to return every record stored in the Quick Base database accessible via that workflow credential. Similarly, if the workflow includes a delete node utilizing this vulnerable filter mechanism, an injected payload could result in the deletion of all records associated with the target table or application. The scope of damage is directly tied to the privileges held by the API credentials configured within the n8n instance, potentially leading to significant data loss or privacy violations depending on the sensitivity of the stored information.
This vulnerability aligns closely with MITRE ATT&CK technique T1505.003: Server Software Component: Web Shell, in terms of its impact profile if it leads to persistent access, but more accurately maps to T1213: Data from Information Repositories for exfiltration and T1485: Data Destruction for the deletion scenario. It also reflects CWE-917: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection) adapted for API query parameters, highlighting a common pattern where developers assume that passing strings to REST APIs is inherently safe compared to direct database queries.
To mitigate this risk, organizations running affected versions of n8n must upgrade immediately to version 1.123.85 or later, 2.43.5 for the 2.x branch, and 2.44.1 for the 2.44.x series where these patches have been applied. Until an update is feasible, administrators should restrict access to workflows containing Quick Base nodes by enforcing strict authentication controls on webhook endpoints and ensuring that only trusted internal services can trigger them. Additionally, implementing input validation at the workflow level to reject suspicious characters or patterns in fields destined for filter construction can provide a layer of defense-in-depth. It is also advisable to review API permissions associated with n8n integrations, adhering to the principle of least privilege by ensuring that service accounts do not possess broad delete-all capabilities unless absolutely necessary for business logic.