UpGuard researchers identified 16,326 Supabase databases exposing readable tables after analyzing roughly 300,000 domains showing signs of using the platform. More than half of the exposed databases contained indicators of personally identifiable information, while smaller subsets included passwords or authentication tokens.
Researchers traced the exposures to security configuration issues including missing or ineffective row-level security policies and improper use of public keys. UpGuard noted that Supabase has become popular with AI-assisted developers and said tables created programmatically through APIs do not enable row-level security by default. However, the researchers said their findings do not establish that every affected application was built using an AI coding agent.
Examples included a U.S. valet service exposing more than 100,000 customer records, a Canadian immigration service exposing nearly 5,000 records including 884 plaintext passwords, and an African government consulate exposing information on 25,000 people.
Ryan McCurdy, VP of Marketing, Liquibase:
“AI has dramatically lowered the barrier to building software. Someone can create an application and stand up a database without understanding much about database security.
“The same tools that make development easier also make it easier to push a bad configuration into production.
“Database misconfigurations aren’t new but AI changes the scale. More people can build software, they can build it much faster, and AI agents can now create database changes directly.
“We shouldn’t solve that by putting more manual reviews in the way. We need to make the governed path the easiest path. Database changes should be checked against security policies before they reach production, regardless of whether a developer or an AI agent created them.
“The source of the change doesn’t determine the risk. The change itself does.”ㅤ
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“Vibe coding has collapsed the distance between having an idea and deploying software, but a working application and a secure application are different achievements. UpGuard found 16,326 Supabase databases with readable tables. More than half carried indicators of personal data, and the examples include a United States valet service exposing more than 100,000 customer records and a Canadian immigration service exposing 884 plaintext passwords. Someone who can prompt an AI agent into producing a login screen and a database may still not understand which customer records each user should be allowed to read.
“Supabase makes that distinction concrete. Its publishable key is meant to appear in browser code, while the security boundary is row-level security, policies that decide which rows a user can read. UpGuard notes that tables created programmatically through APIs do not enable row-level security by default. An AI agent can produce a functional schema and API call in seconds, but it cannot decide whether the query is authorized.
“The broader pattern includes Tea’s Firebase exposure, Lovable’s Supabase projects, Moltbook’s exposed agent tokens, and DeepSeek’s open ClickHouse database. Different backends, same failure, software reached production before anyone verified what an anonymous request could read or change.
“I would treat security review as a deployment requirement for any AI-built application handling customer data. Test the live API as anonymous and authenticated users, inspect row-level security policies and database grants, and verify that secrets are absent from client code. The person who can make an application work has demonstrated one capability. An anonymous API request tests whether they built it securely.”
If you have Supabase, it’s time to make this go away as this should be a extremely high priority for you to deal with.
Related
This entry was posted on September 29, 2026 at 3:04 pm and is filed under Commentary with tags Supabase. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
More than 16,000 misconfigured Supabase databases expose sensitive data
UpGuard researchers identified 16,326 Supabase databases exposing readable tables after analyzing roughly 300,000 domains showing signs of using the platform. More than half of the exposed databases contained indicators of personally identifiable information, while smaller subsets included passwords or authentication tokens.
Researchers traced the exposures to security configuration issues including missing or ineffective row-level security policies and improper use of public keys. UpGuard noted that Supabase has become popular with AI-assisted developers and said tables created programmatically through APIs do not enable row-level security by default. However, the researchers said their findings do not establish that every affected application was built using an AI coding agent.
Examples included a U.S. valet service exposing more than 100,000 customer records, a Canadian immigration service exposing nearly 5,000 records including 884 plaintext passwords, and an African government consulate exposing information on 25,000 people.
Ryan McCurdy, VP of Marketing, Liquibase:
“AI has dramatically lowered the barrier to building software. Someone can create an application and stand up a database without understanding much about database security.
“The same tools that make development easier also make it easier to push a bad configuration into production.
“Database misconfigurations aren’t new but AI changes the scale. More people can build software, they can build it much faster, and AI agents can now create database changes directly.
“We shouldn’t solve that by putting more manual reviews in the way. We need to make the governed path the easiest path. Database changes should be checked against security policies before they reach production, regardless of whether a developer or an AI agent created them.
“The source of the change doesn’t determine the risk. The change itself does.”ㅤ
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“Vibe coding has collapsed the distance between having an idea and deploying software, but a working application and a secure application are different achievements. UpGuard found 16,326 Supabase databases with readable tables. More than half carried indicators of personal data, and the examples include a United States valet service exposing more than 100,000 customer records and a Canadian immigration service exposing 884 plaintext passwords. Someone who can prompt an AI agent into producing a login screen and a database may still not understand which customer records each user should be allowed to read.
“Supabase makes that distinction concrete. Its publishable key is meant to appear in browser code, while the security boundary is row-level security, policies that decide which rows a user can read. UpGuard notes that tables created programmatically through APIs do not enable row-level security by default. An AI agent can produce a functional schema and API call in seconds, but it cannot decide whether the query is authorized.
“The broader pattern includes Tea’s Firebase exposure, Lovable’s Supabase projects, Moltbook’s exposed agent tokens, and DeepSeek’s open ClickHouse database. Different backends, same failure, software reached production before anyone verified what an anonymous request could read or change.
“I would treat security review as a deployment requirement for any AI-built application handling customer data. Test the live API as anonymous and authenticated users, inspect row-level security policies and database grants, and verify that secrets are absent from client code. The person who can make an application work has demonstrated one capability. An anonymous API request tests whether they built it securely.”
If you have Supabase, it’s time to make this go away as this should be a extremely high priority for you to deal with.
Share this:
Like this:
Related
This entry was posted on September 29, 2026 at 3:04 pm and is filed under Commentary with tags Supabase. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.