Supabase vulnerabilities: 4 real CVEs vs the misconfigs

Of the 43 CVE records in NVD that match "supabase" (checked 2026-10-27), only 4 are flaws in Supabase's own code, and all four are rated Low or Medium. Most of the rest are bugs in apps built on Supabase: tables without Row Level Security, policies that allow everyone, functions anyone can call. Upgrade @supabase/auth-js to 2.70.0 or later, and audit your RLS and keys, because that is where the leaks are.

Checked against the NVD keyword search on 2026-10-27 and refreshed monthly. The newest Supabase CVE was published on 2026-10-22.

Search "supabase cve" and aggregators list every record that mentions the word, mixing bugs in Supabase's own components, bugs in other products built on Supabase, and one vendor-disputed record scored 9.8 Critical.

What are the known Supabase vulnerabilities?

Four CVEs are in Supabase's own components: the JavaScript auth client, the Auth server and Realtime (two). None is rated High or Critical.

CVE-2025-48370 (auth-js). Before 2.70.0, getUserById, deleteUser, updateUserById, listFactors and deleteFactor did not require the id to be a valid UUID. Per NVD, implementations that validate user-controlled inputs "such as the userId" are not affected. It is the only one of the four that lives in your node_modules.

CVE-2026-31813 (Auth). The MITRE record says it "allows an attacker to issue sessions for arbitrary users using specially crafted ID tokens when the Apple or Azure providers are enabled." The attacker gets an AAL1 session as the victim. The advisory's audit step for self-hosters: Apple identities must have an issuer starting with https://appleid.apple.com/, Azure ones https://login.microsoftonline.com/ or https://sts.windows.net/; any other issuer means the bug was likely exploited.

CVE-2026-62247 (Realtime). If a private channel lets a client write presence but denies it read, that client still received presence_diff messages with other members' presence metadata. It needs presence visibility stricter than broadcast visibility; Postgres Changes row data was unaffected.

CVE-2026-54238 (Realtime). The REST broadcast endpoints accepted an expired token when its exp claim was a JSON string instead of a number, and its broadcasts still reached subscribers. Signature checks still applied.

Who has to patch what?

On the hosted platform, Supabase runs Auth and Realtime for you; the update instructions in these advisories are addressed to self-hosted deployments. If you self-host, upgrade the Auth and Realtime images to at least the fixed versions. The auth-js fix is yours on every setup, because it ships in your app's dependencies.

Which CVEs only look like Supabase CVEs?

The other 39 records fall into two groups, and neither is a Supabase platform bug:

• CVE-2024-24213 (disputed). Filed against "Supabase PostgreSQL v15.1" as SQL injection through /pg_meta/default/query and scored 9.8 Critical by NVD. NVD's own description carries the vendor's response: that endpoint runs SQL an authorized user types into the dashboard, so it is a feature, and "Nothing is injected." Read the NVD record, not the mirrors.
• Apps built on Supabase (38 records). 24 belong to Capgo, an over-the-air update platform built on Supabase: mostly SECURITY DEFINER RPC functions callable with the public API key, and RLS policies on its own tables that let the wrong users read or write. One NVD description calls it "Supabase Capgo", which is why it ranks for supabase cve; the code is Capgo's. The rest include three n8n Supabase-node CVEs, WACRM, Chatbot UI, AutoGPT, Flowise, CMSaaSStarter and a VPS.org one-click Supabase template that published Postgres on all interfaces.

The headline number. Of 43 NVD records matching "supabase" on 2026-10-27, 4 are in Supabase's own components, 1 is vendor-disputed, and 38 are in other projects. 24 of those 38 are one app, Capgo: the same bugs any Supabase app can have, written up with CVE numbers.

The vulnerabilities that actually leak data

Most reported Supabase data leaks trace back to one of these, in the app itself:

1. A table with RLS off. If the Data API exposes a table and RLS is off, the anon key in your browser bundle can read it. Start with how to fix a table with RLS disabled.
2. A policy that says using (true). RLS is on, but the policy lets every caller through.
3. A leaked service-role or secret key. It bypasses RLS entirely; one NEXT_PUBLIC_ prefix ships it to every visitor.
4. A SECURITY DEFINER function anon can execute. The function runs as its owner, usually past RLS, and Postgres grants EXECUTE to PUBLIC by default. This is the Capgo pattern; see why revoking from anon alone isn't enough.

None of these gets a CVE when it happens in your app, so a CVE count says little about whether your project is safe. For the reported incidents, including the SupaPwn research, see the roundup of real Supabase security incidents.

Is my app affected by the auth-js CVE?

Only if a version of @supabase/auth-js below 2.70.0 is installed and user-controlled ids reach the admin functions. Most apps get auth-js through @supabase/supabase-js, which pinned auth-js 2.69.1 or older in every release before 2.50.0. A manifest like this is affected:

{
  "dependencies": {
    "@supabase/auth-js": "2.69.1",
    "@supabase/ssr": "0.6.1",
    "@supabase/supabase-js": "2.49.4"
  }
}

GuardLayer's general/vulnerable-dependency rule flags @supabase/auth-js when it is a direct dependency in package.json below 2.70.0, exact or as a ^ range. It reads package.json only, not your lockfile, and it has no floor for @supabase/supabase-js. So a manifest that lists only "@supabase/supabase-js": "2.49.4" produces no finding, even though it installs auth-js 2.69.1. Check the resolved version yourself:

npm ls @supabase/auth-js

If anything below 2.70.0 shows up, upgrade @supabase/supabase-js to 2.50.0 or later (or auth-js directly, if you depend on it). Then make sure ids passed to auth.admin.getUserById, deleteUser or updateUserById come from your session, not a request parameter.

The scanner does not detect the three server-side CVEs. They live in Auth and Realtime, not in your repo, and no rule reads Docker image tags. It also has no rule for an EXECUTE grant to anon, the Capgo pattern. On the misconfig side it does flag tables created without RLS (supabase/rls-missing-on-table), using (true) policies (supabase/policy-using-true) and service-role keys in client code or public env vars.

Where does Supabase publish its security advisories?

On GitHub, per repository: the Security tab of supabase/auth, supabase/realtime, supabase/auth-js and others lists the GHSA advisories behind the CVEs above. To report a vulnerability, Supabase's security.txt points to its HackerOne program at hackerone.com/supabase.

Watch package names: OSV lists a malware record, MAL-2023-8327, for an npm package called supabase.dev, which is not a Supabase package. OSV has no advisories for npm supabase, @supabase/supabase-js, @supabase/ssr or @supabase/realtime-js, and only the CVE above for @supabase/auth-js.

FAQ

Does Supabase have any critical CVEs? None of the four CVEs in Supabase's own components is rated High or Critical. The one 9.8 Critical record, CVE-2024-24213, is disputed by Supabase, and NVD's description includes the vendor's position that the endpoint is an intended dashboard feature.

What is the Supabase auth vulnerability? There are two. CVE-2025-48370 is in the @supabase/auth-js client library, fixed in 2.70.0. CVE-2026-31813 is in the Auth server: crafted ID tokens could produce sessions for other users when Apple or Azure sign-in was enabled, fixed in 2.185.0.

Do I need to patch my hosted Supabase project? The server-side fixes ship on Supabase's side for hosted projects; the advisories' update instructions are written for self-hosters. You still own your app's dependencies, so run npm ls @supabase/auth-js and upgrade anything below 2.70.0.

Are the Capgo CVEs Supabase vulnerabilities? No. They are bugs in Capgo's own functions and RLS policies, worth reading because the same patterns show up in many Supabase apps.

What are the most common Supabase vulnerabilities? Row Level Security left off, using (true) policies, service-role keys in the browser and SECURITY DEFINER functions callable by anon. All four are app misconfigurations, not platform CVEs.