n8n's Supabase Bug: What It Means for Your App

A real vulnerability landed today in a tool a lot of vibe-coded backends touch: Supabase. Not a leaked key, not a config mistake — a code-level bug in how a popular automation tool built its database queries. At the same time, the platforms you build with are quietly shipping the guardrails you probably didn't know you needed.

TL;DR

• A patched n8n bug (CVE-2026-77071) let attackers turn single-row Supabase operations into full-table disclosure, deletion, or modification.
• A separate CVE in an unrelated app shows how trusting client-supplied headers for rate limiting backfires — a pattern common in AI-generated backends.
• Vercel open-sourced deepsec, an agent-powered scanner for finding vulnerabilities in your own codebase.
• v0 published how it keeps generated code away from users' raw OAuth tokens — a template worth copying if your app talks to third-party APIs.

The n8n–Supabase bug: one bad filter, every row

If you connect n8n to a Supabase database — a common pattern for founders who vibe-coded a frontend and wired up automations for emails, syncs, or admin tasks — pay attention to CVE-2026-77071. The Supabase node's Row Get Many, Delete, and Update operations built filter queries by concatenating a value instead of escaping it. An attacker could inject a condition that widened the filter to match every row. A query meant to touch one record could disclose, delete, or modify the whole table.

This is a code bug in n8n, not a Supabase configuration problem. It's fixed in n8n 1.123.69, 2.33.4, and 2.34.1. If you run n8n workflows against Supabase, update. Then check your Row Level Security policies anyway — RLS is your last line of defense when a client, a workflow tool, or a piece of generated code sends a query you didn't expect. A public Supabase anon key is fine by design. Missing or weak RLS is the actual risk, and this bug is a clean example of why.

Trusting the client is still the most common mistake

A second CVE this cycle, CVE-2026-69183, hit an unrelated app (Monkeytype) but illustrates a pattern that shows up constantly in AI-generated backends: the rate limiter derived its key from client-controlled cf-connecting-ip and x-forwarded-for headers instead of the trusted, proxy-derived IP. Rotate the header, get a fresh rate-limit bucket, bypass the throttle entirely. The result was mail-bombing via password-reset and verification endpoints.

AI coders love to reach for request headers because they're easy to read and the code looks reasonable: grab the IP, key the rate limiter off it, done. The problem is that cf-connecting-ip and x-forwarded-for are set by whoever sends the request, not by your infrastructure, unless a proxy in front of your app strips and re-sets them first. Monkeytype's rate limiter keyed on those headers directly, so rotating them on every request bought a fresh bucket, turning password-reset and email-verification endpoints into an unauthenticated mail-bombing tool (CVSS 7.5). If an AI builder generated your rate limiting, check what it's keying on. The only IP you can trust is the one your platform's edge sets after stripping client-supplied headers, never whatever the request claims about itself.

Vercel open-sources deepsec, a scanner for your own code

Vercel released deepsec, an open-source security scanner built on coding agents instead of static rules. It runs a five-stage pipeline — static scan, agent investigation, a second agent that revalidates each finding to cut false positives, git-blame enrichment, then export — using Claude and GPT models to trace how data actually moves through a codebase instead of pattern-matching known bug signatures. Vercel reports a 10-20% false-positive rate, which is honest for the category, and a full scan on a large repo can run for days and cost real money in model usage. It's not a replacement for continuous monitoring — it's a heavyweight, run-when-you-need-it audit for a codebase you've already shipped and never had reviewed. If you're sitting on a large AI-generated app you built months ago and never checked, it's a real option, and it's free.

v0 shows the right pattern for third-party OAuth tokens

Vercel also opened v0's Snowflake integration to public preview, and the authentication design is worth copying even if you never touch Snowflake. You connect your Snowflake account through OAuth once; v0 never stores the password or the token. Vercel's layer handles the application and authentication logic, Snowflake's own layer handles compute and data, and every query still runs under your existing Snowflake permissions — nobody had to write custom access-control logic to make that true. That's the pattern worth copying: when your AI-built app talks to a third-party API, let that service's own OAuth flow issue and hold the credential, route the request through a server-side layer, and never let a token land in code a browser can read. If your app currently has an API key or OAuth token sitting in client-side JavaScript, that's the thing to fix first.

FAQ

Is my Supabase anon key a security risk?

No. The anon key is meant to be public — it ships in every browser bundle by design. The risk is what your Row Level Security policies let that key do. A public key with locked-down RLS is safe. A public key with no RLS is an open database.

Does my Supabase app need RLS policies?

Yes, unless every table is meant to be fully public. Supabase doesn't enable RLS by default on tables created through the SQL editor, and an AI builder wiring up your backend has no way to know your access rules unless you specify them. Check each table in the Supabase dashboard — if RLS shows disabled and the table holds anything sensitive, write the policy before you ship.

How does v0 authenticate to Snowflake?

Through Snowflake's own OAuth flow. You authorize once, Snowflake issues the credential, and v0 never sees or stores your password. The generated app's queries then run under your existing Snowflake permissions, so nobody has to duplicate access control logic in application code.

The bottom line

Nothing this week needs a panic response. It's a reminder that two failure modes keep repeating: code that widens a filter it shouldn't, and code that trusts something the client controls. Neither needs a CVE in your specific stack to matter. Update n8n if you run it, check your Supabase RLS policies regardless, and audit anywhere your app derives a decision — a rate limit, an auth check — from a header or field the caller can set.