Researchers at cyber risk management company UpGuard have found more than 16,000 Supabase databases exposing readable tables, with personally identifiable information showing up in more than half of the exposed databases they identified.
Supabase may not be a familiar name to many people outside software development. It is an open-source development platform built around PostgreSQL, an open-source relational database system, that gives developers database, authentication and other backend services that can be used to build applications and websites quickly.
The important distinction in this story is that this is not being reported as a compromise of Supabase itself. UpGuard attributes the exposures to application security configuration problems, including missing or ineffective Row Level Security policies and incorrect handling of keys and permissions.
UpGuard identified 16,326 databases with readable tables after examining roughly 300,000 domains showing signs of Supabase use. Because of the scale of the research, the company analyzed table schemas – the structures describing database tables and the kinds of fields they contain – to determine what kinds of data might be exposed rather than attempting to read every row in every database.
More than half of those databases showed indicators of personally identifiable information. Smaller percentages appeared to contain passwords or authentication tokens, credentials that can be used to prove an authenticated session or authorize access to a service. UpGuard said a very small number had what it described as plausible credit-card data.
That last finding deserves some caution. It does not establish that criminals stole complete credit-card numbers, nor does the research establish fraudulent use of cards from these databases. In one of the applications UpGuard investigated more closely, researchers found financial information including payout accounts and Stripe account information with the last four digits of cards. That is sensitive financial information, but it is not the same thing as proving that complete card numbers were stolen.
The plaintext password finding is much less ambiguous.
A Canadian immigration and relocation service exposed nearly 5,000 user records containing information including names, email addresses, phone numbers and dates of birth. UpGuard reported that 884 of those records also contained passwords stored in plaintext – readable form rather than being protected with a one-way password hash.
Passwords should not be stored in recoverable plaintext. Applications should store passwords using appropriate password-hashing mechanisms, which transform a password through a one-way process so the application does not need to store the original password. An access-control failure, where someone can retrieve information they were not supposed to be allowed to access, is bad enough. Combining that failure with plaintext password storage makes the consequences potentially much worse, particularly for anyone who reused the same password elsewhere.
Other examples found by UpGuard show how broad the problem can become. A U.S. valet service exposed records involving more than 100,000 customers, including phone numbers, email addresses, names, license plates, visit history and other information. An India-based adult creator platform exposed identity information, financial information and more than 100,000 private messages. A Philippines-based one-time password (OTP) service exposed information involving more than 2,000 users and more than 100,000 SMS messages. An African government consulate database exposed records involving 25,000 people, including physical addresses and emergency housing locations.
Why did this happen?
Supabase provides Row Level Security, or RLS, to control which database rows a user is allowed to access. Supabase’s documentation warns that tables in exposed schemas need RLS and appropriate grants and policies. The company’s shared-responsibility documentation also makes clear that customers are responsible for access management, their data and applying appropriate security controls.
Encryption does not make a bad authorization policy disappear. Supabase states that its hosted platform encrypts data at rest and in transit. Encryption at rest means stored data is encrypted while it sits on disks or other storage media. Encryption in transit protects data while it moves between systems or across a network. But if an application is configured so that a requester is permitted to retrieve information that should have been restricted, encryption at rest is not going to prevent the application from returning readable data.
There is also an AI-development angle worth watching. BleepingComputer reports that AI-assisted development accounts for more than 60 percent of newly created Supabase databases. UpGuard says coding agents are part of the pattern it is seeing, while also cautioning that its scans do not establish that every affected site was created with an AI coding agent.
That distinction matters. AI-assisted coding by itself does not prove that AI caused a particular exposure. What this research does demonstrate is the danger of deploying applications without understanding the security controls protecting the underlying data. Whether code is written by a human, generated with an AI assistant or produced through some combination of the two, somebody still needs to understand and verify the permissions before putting real customer information behind them.
As of September 30, I did not find this Supabase research listed in either Have I Been Pwned’s Pwned Websites directory or XposedOrNot’s breach directory. Both services can be useful for checking email addresses and domains against breach information, but absence from either directory should not be interpreted as proof that information was never exposed.
That is especially important here because the word “exposed” is doing a lot of work. UpGuard demonstrated that databases were readable when they should not have been. That does not automatically mean attackers found every exposed database, downloaded the information or are circulating it.
For users, the usual security practices still apply: use unique passwords, use a password manager where appropriate, enable multifactor authentication when it is available and check reputable breach-notification services. For developers, this research is another reminder that database permissions, RLS policies, secrets and production security controls need to be deliberately configured and tested.
More than 16,000 readable databases is already a serious finding. There is no need to turn an exposure into a confirmed criminal breach before the evidence supports it.
Sources
Related
Discover more from Jared's Technology podcast network
Subscribe to get the latest posts sent to your email.
Over 16,000 Supabase databases expose sensitive data through misconfiguration
Researchers at cyber risk management company UpGuard have found more than 16,000 Supabase databases exposing readable tables, with personally identifiable information showing up in more than half of the exposed databases they identified.
Supabase may not be a familiar name to many people outside software development. It is an open-source development platform built around PostgreSQL, an open-source relational database system, that gives developers database, authentication and other backend services that can be used to build applications and websites quickly.
The important distinction in this story is that this is not being reported as a compromise of Supabase itself. UpGuard attributes the exposures to application security configuration problems, including missing or ineffective Row Level Security policies and incorrect handling of keys and permissions.
UpGuard identified 16,326 databases with readable tables after examining roughly 300,000 domains showing signs of Supabase use. Because of the scale of the research, the company analyzed table schemas – the structures describing database tables and the kinds of fields they contain – to determine what kinds of data might be exposed rather than attempting to read every row in every database.
More than half of those databases showed indicators of personally identifiable information. Smaller percentages appeared to contain passwords or authentication tokens, credentials that can be used to prove an authenticated session or authorize access to a service. UpGuard said a very small number had what it described as plausible credit-card data.
That last finding deserves some caution. It does not establish that criminals stole complete credit-card numbers, nor does the research establish fraudulent use of cards from these databases. In one of the applications UpGuard investigated more closely, researchers found financial information including payout accounts and Stripe account information with the last four digits of cards. That is sensitive financial information, but it is not the same thing as proving that complete card numbers were stolen.
The plaintext password finding is much less ambiguous.
A Canadian immigration and relocation service exposed nearly 5,000 user records containing information including names, email addresses, phone numbers and dates of birth. UpGuard reported that 884 of those records also contained passwords stored in plaintext – readable form rather than being protected with a one-way password hash.
Passwords should not be stored in recoverable plaintext. Applications should store passwords using appropriate password-hashing mechanisms, which transform a password through a one-way process so the application does not need to store the original password. An access-control failure, where someone can retrieve information they were not supposed to be allowed to access, is bad enough. Combining that failure with plaintext password storage makes the consequences potentially much worse, particularly for anyone who reused the same password elsewhere.
Other examples found by UpGuard show how broad the problem can become. A U.S. valet service exposed records involving more than 100,000 customers, including phone numbers, email addresses, names, license plates, visit history and other information. An India-based adult creator platform exposed identity information, financial information and more than 100,000 private messages. A Philippines-based one-time password (OTP) service exposed information involving more than 2,000 users and more than 100,000 SMS messages. An African government consulate database exposed records involving 25,000 people, including physical addresses and emergency housing locations.
Why did this happen?
Supabase provides Row Level Security, or RLS, to control which database rows a user is allowed to access. Supabase’s documentation warns that tables in exposed schemas need RLS and appropriate grants and policies. The company’s shared-responsibility documentation also makes clear that customers are responsible for access management, their data and applying appropriate security controls.
Encryption does not make a bad authorization policy disappear. Supabase states that its hosted platform encrypts data at rest and in transit. Encryption at rest means stored data is encrypted while it sits on disks or other storage media. Encryption in transit protects data while it moves between systems or across a network. But if an application is configured so that a requester is permitted to retrieve information that should have been restricted, encryption at rest is not going to prevent the application from returning readable data.
There is also an AI-development angle worth watching. BleepingComputer reports that AI-assisted development accounts for more than 60 percent of newly created Supabase databases. UpGuard says coding agents are part of the pattern it is seeing, while also cautioning that its scans do not establish that every affected site was created with an AI coding agent.
That distinction matters. AI-assisted coding by itself does not prove that AI caused a particular exposure. What this research does demonstrate is the danger of deploying applications without understanding the security controls protecting the underlying data. Whether code is written by a human, generated with an AI assistant or produced through some combination of the two, somebody still needs to understand and verify the permissions before putting real customer information behind them.
As of September 30, I did not find this Supabase research listed in either Have I Been Pwned’s Pwned Websites directory or XposedOrNot’s breach directory. Both services can be useful for checking email addresses and domains against breach information, but absence from either directory should not be interpreted as proof that information was never exposed.
That is especially important here because the word “exposed” is doing a lot of work. UpGuard demonstrated that databases were readable when they should not have been. That does not automatically mean attackers found every exposed database, downloaded the information or are circulating it.
For users, the usual security practices still apply: use unique passwords, use a password manager where appropriate, enable multifactor authentication when it is available and check reputable breach-notification services. For developers, this research is another reminder that database permissions, RLS policies, secrets and production security controls need to be deliberately configured and tested.
More than 16,000 readable databases is already a serious finding. There is no need to turn an exposure into a confirmed criminal breach before the evidence supports it.
Sources
Share this:
Like this:
Related
Discover more from Jared's Technology podcast network
Subscribe to get the latest posts sent to your email.
Published in article commentary