Summary
A critical filter injection vulnerability in n8n's Supabase node allows untrusted field values to alter database filter expressions. When attacker- controlled input reaches the Filters (String) mode, an attacker may read all rows, modify all records, or delete entire tables in a single request.
Affected context
The issue occurs in n8n workflows that use the Supabase node's Filters (String) mode and pass untrusted or insufficiently constrained input into filter field values. It is most risky when the workflow is externally reachable or processes data controlled by users, integrations, or other untrusted sources.
Exploit preconditions
- Attack surface: n8n workflows using the Supabase node
- Required access: Ability to invoke an affected workflow or supply input that reaches the filter fields
- Trigger point: Processing a Supabase request through Filters (String) mode
- Why exploitation is possible: Field values are not escaped or safely parameterized, allowing injected filter expressions to change the intended database operation
Why this happens
The vulnerability results from constructing Supabase filter expressions with untrusted field values without applying context-appropriate escaping or parameterization. This allows input data to be interpreted as query logic rather than as a literal value, matching CWE-89, Improper Neutralization of Special Elements used in an SQL Command. The insecure pattern combines dynamic query construction with insufficient separation between data and database expressions.
Potential impact
- An attacker may read records outside the intended result set.
- An attacker could update records across an entire table.
- An attacker could delete an entire table or its data.
- Affected workflows may cause unauthorized data disclosure or integrity loss.
- Downstream systems may process manipulated or unexpectedly deleted data.
General mitigation guidance
Mitigation generally focuses on preserving a strict separation between
filter data and query expressions.
Common defensive patterns include:
- Use parameterized, structured, or typed query APIs instead of concatenating filter expressions.
- Apply context-aware escaping when a structured API cannot be used.
- Prefer allowlisted fields, operators, and filter formats over arbitrary expression input.
- Validate and constrain workflow inputs at trust boundaries.
- Apply least-privilege database roles so workflow credentials cannot perform unnecessary destructive operations.
- Require explicit authorization and safeguards for bulk updates and deletions.
- Use secure-by-default node configurations that reject ambiguous or unsupported filter syntax.
How teams detect issues like this
Organizations can identify similar risks through:
- Static analysis for string concatenation or interpolation used to construct database filters or queries.
- Code review checks for untrusted workflow data flowing into Supabase filter parameters.
- Testing that verifies special characters and operator-like input remain literal data.
- Runtime monitoring for unusual full-table reads, bulk updates, or destructive requests.
- Policy enforcement requiring parameterized or structured database access APIs.
- Automated security review tools that flag data-to-query flows and missing input validation.
