n8n CVE-2026-77071

Exploitation requires three concurrent conditions: (1) the target n8n instance must have one or more active workflows that include the Supabase integration node performing Row Get Many, Delete, or Update operations; (2) the filter parameter in that node must be populated via an n8n expression that incorporates attacker-controllable input (e.g., a webhook payload field, HTTP query parameter, or form value); and (3) the n8n instance must be connected to a live Supabase backend via a configured credential. Default n8n installations with no Supabase workflows are entirely unaffected. The CVSS 4.0 AT:P metric confirms this prerequisite. Authentication to n8n is not required if the workflow trigger (e.g., a webhook) is publicly accessible. Exploitation scope is bounded by the database permissions of the Supabase service role credential stored in n8n.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H) scores 7.1. The AT:P (Attack Target: Partial) metric is the critical qualifier - exploitation is not universally applicable but requires a specific deployment configuration. The vulnerable-system impact is zero (n8n itself is not directly compromised), while the subsequent-system impact is uniformly high (the Supabase database backend). This reflects a classic injection-via-proxy pattern where the automation platform is the vulnerable intermediary and the real damage lands on the data store. No CISA KEV listing and no confirmed POC code shift the practical urgency toward moderate-high for organizations using the Supabase node with externally-influenced workflow inputs. The risk is substantially higher in multi-tenant or SaaS n8n deployments where multiple users can define workflows or where public-facing webhooks feed into Supabase operations.

An attacker identifies a public-facing n8n webhook that triggers a workflow containing a Supabase Delete node, where the row filter is populated from the webhook payload using n8n's expression syntax. The attacker crafts a payload that injects a PostgREST filter condition (e.g., a tautology such as 'id=gt.0') alongside the intended filter value, causing the DELETE operation to match and destroy every row in the target table rather than the intended single record. No public exploit code has been confirmed, but the injection primitive is conceptually simple given the string-concatenation root cause.