CVE-2026-77071 in n8n
Summary
by MITRE • 08/20/2026
n8n before 1.123.69, 2.33.4, and 2.34.1 contains a PostgREST filter injection vulnerability in the Supabase node's Row Get Many, Delete, and Update operations, which built filter queries by concatenating an expression-bindable value without escaping. An attacker could inject a condition that widened the filter to match every row, turning an intended single-row operation into full-table disclosure, deletion, or modification.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in n8n versions prior to 1.123.69, 2.33.4, and 2.34.1 represents a critical server-side logic flaw within the Supabase integration node, specifically affecting the Row Get Many, Delete, and Update operations. This issue stems from how the application constructs database filter queries for these specific actions. Instead of utilizing parameterized queries or properly escaping user-supplied input, n8n concatenates expression-bindable values directly into the SQL-like query string used by PostgREST. This architectural decision bypasses standard security controls that rely on separating code from data, thereby creating a classic injection vector where untrusted input is interpreted as executable logic by the database engine.
From a technical perspective, this flaw aligns with CWE-94, commonly known as Improper Control of Generation of Code or SQL Injection. The core mechanism involves the lack of sanitization on filter parameters provided by workflow creators or end-users interacting with n8n instances. When an attacker provides a maliciously crafted input string for these operations, they can inject additional logical conditions into the query. For instance, in a scenario where the application intends to fetch or modify a single record based on a unique identifier like user ID 123, an injection payload could alter the filter condition to always evaluate as true, such as appending OR 1=1. This effectively neutralizes the restrictive nature of the original query, causing the database operation to apply to all rows in the target table rather than just the intended single record.
The operational impact of this vulnerability is severe and varies depending on which node operation is exploited. In the case of Row Get Many, an attacker can achieve full-table data disclosure by forcing the filter to match every row, resulting in a massive exfiltration of sensitive information stored within that table. For Delete operations, the consequence is catastrophic data loss, as the injection allows for the deletion of all records rather than just the specified target. Similarly, Update operations enable unauthorized bulk modification of database entries, potentially leading to data integrity issues or privilege escalation if critical configuration fields are altered. This transforms what should be precise, targeted administrative actions into broad-scale destructive or exploitative events against the underlying Supabase database infrastructure.
This vulnerability is further contextualized by MITRE ATT&CK techniques related to Data Exfiltration and Impact categories. Specifically, it facilitates unauthorized access to data through improper query construction, allowing attackers to bypass intended access controls. The ability to widen filters effectively grants an attacker read-write-delete privileges over entire tables if the n8n service account has such permissions in Supabase, which is a common configuration for workflow automation tools that require broad database access to function correctly.
Mitigation strategies must prioritize immediate version upgrades as the primary defense vector. Organizations running affected versions of n8n should upgrade to 1.123.69 or later, 2.33.4 or later, or 2.34.1 or later, where this concatenation flaw has been remediated through proper input sanitization and parameterized query implementation. In environments where immediate upgrading is not feasible due to operational constraints, administrators should implement strict network-level controls such as Web Application Firewalls (WAF) configured to detect SQL injection patterns in API requests directed at the n8n instance. Additionally, applying the principle of least privilege to the database user account used by the Supabase node can limit the blast radius; ensuring that this account does not have unrestricted delete or update permissions on sensitive tables reduces the potential damage even if an injection succeeds. Regular auditing of workflow configurations and restricting who can create workflows containing database nodes are also recommended administrative controls to reduce exposure.