UpGuard Finds Thousands of Supabase Databases Exposing Sensitive Data Online

Updated September 26, 2026 6:23 pm

Thousands of databases hosted on Supabase are exposing people’s sensitive information to the public internet, according to new research from cybersecurity firm UpGuard. The findings matter because they show how the rise of AI-assisted app building is accelerating a familiar but still dangerous problem: developers are deploying software with data stores that are left open by mistake.

UpGuard says it identified about 16,000 Supabase-hosted databases in which some level of personal data was publicly accessible, including names, addresses, phone numbers, passwords and other account details. The research suggests that the rapid expansion of vibe-coded apps and quick-turn development workflows is making basic security failures more common, not less.

Supabase, which has become a major backend platform for developers building modern web and mobile apps, has grown quickly alongside the boom in AI coding tools. But the same tools that make it easy to launch software can also create blind spots around database permissions, access controls and public exposure.

What UpGuard found in Supabase databases

UpGuard’s research focused on how much real-world information could be reached through improperly configured databases hosted on the platform. The answer, according to the firm, was a significant amount.

The company said it encountered publicly visible records containing personal details such as names, addresses, phone numbers and user passwords. In a smaller number of cases, it also found authentication tokens, which can be especially sensitive because they may be used to access user accounts or related services.

The exposed data was not limited to generic test material. UpGuard said the databases were tied to a range of actual projects and services, some of them highly sensitive.

• Private communications involving users of an adult streaming service in India
• Thousands of license plate records linked to a U.S. valet operation
• Contact information collected by an immigration and relocation service
• Data associated with an African government’s consulate in France
• Records from a virtual SIM operation used to receive one-time passcodes

That last example is especially noteworthy because services that intercept or relay verification codes are often part of phishing, fraud or account takeover schemes. In other words, the exposure was not only broad but potentially relevant to abuse and criminal activity.

Why vibe coding is making database mistakes more common

AI-assisted coding has lowered the barrier to building websites and apps, but it has also changed who is shipping software and how quickly they are doing it. Many developers now move from idea to deployment in hours, sometimes without fully understanding the infrastructure behind their apps.

That speed can be an advantage, yet it often comes with hidden security costs. Generated code may include flawed assumptions, while the underlying database or storage settings can be left at permissive defaults. In some cases, the developer may not realize that a project is publicly reachable until the data has already been indexed, copied or scraped.

This is the core risk UpGuard is flagging: the easier it becomes to build, the easier it can become to misconfigure. A platform that makes app creation simpler can also make it simpler to accidentally place sensitive data within reach of anyone on the web.

How do exposed databases become a public problem?

Exposed databases usually become public because of configuration errors, not because an attacker successfully breaks in. A database may be left without proper authentication, connected to the internet with weak access controls, or deployed in a way that makes records readable without an intended permission check.

Once that happens, anyone who knows where to look may be able to retrieve the contents. The problem is especially serious when the database holds personally identifiable information, account credentials or material that could be used for fraud, extortion or impersonation.

UpGuard’s research underscores how security failures often stem from the way a project is configured, not only from outside hacking attempts, and how quickly sensitive records can become visible when developers assume the defaults are safe.

How big is the exposure problem on Supabase?

UpGuard said it found roughly 16,000 databases with some degree of exposed personal information while they were hosted on Supabase. The company did not say that all 16,000 contained the same volume or sensitivity of data, but the figure suggests the issue is widespread rather than isolated.

While many of the affected datasets were apparently based in the United States, UpGuard said the issue is global. That fits a broader pattern in cybersecurity: public cloud and developer platforms often power products built everywhere, but poor security practices can leak data across borders.

The firm also said its work builds on earlier findings involving Supabase-hosted databases, including cases linked to Y Combinator startups and popular consumer apps. In other words, this is not a one-off incident but part of a recurring pattern that has already surfaced in previous reporting.

What Supabase says about the findings

Supabase told TechCrunch through its chief information security officer, Bil Harmer, that the company had not yet reviewed UpGuard’s report in full but considers its projects to be secure by default. He framed the issue as one of shared responsibility between the platform and its customers.

That distinction matters because cloud and database platforms often provide secure defaults, but customers still decide how each project is configured. If access rules are loosened, credentials are exposed or network settings are changed incorrectly, the platform owner may not be able to prevent every mistake.

Harmer said the company provides secure defaults and supporting tools, while customers manage how their projects are configured. He also said Supabase alerts affected customers when it discovers security issues. In a broader reflection on the problem, he emphasized that security work never truly ends and that the company wants to keep making secure deployment easier for developers.

Supabase’s position is that it offers secure defaults and tooling, but that customers remain responsible for how individual projects are configured and protected.

That response is consistent with a broader industry debate. Platforms can reduce risk, but they cannot fully eliminate misconfiguration when users are rapidly shipping apps, often with limited security expertise.

Why this matters beyond one platform

The larger story is not just about Supabase. It is about the collision between AI-driven software creation and old-fashioned operational mistakes that still cause some of the biggest leaks on the internet.

For years, breaches have repeatedly been tied to databases, file stores and web servers that were left open or poorly protected. The list of consequences includes leaked immigration records, military emails, government files, driver’s license scans and children’s personal information. The medium changes; the failure mode stays familiar.

What is new is the scale and pace of software creation. Vibe coding allows more people to build more apps, faster. That can be productive, but it also expands the number of systems that need correct security settings, review and maintenance.

Security teams have long warned that convenience often comes with complexity hidden under the hood. The difference now is that nontraditional builders — founders, marketers, operators and hobbyists using AI tools — may be launching software without knowing which controls need to be turned on before any real data is stored.

How can developers reduce the risk?

Developers can reduce the risk by treating database security as part of the build process, not as an afterthought. That means checking access rules before launch, limiting public exposure, rotating tokens, reviewing logs and understanding what data actually resides in each project.

1. Verify whether the database is publicly reachable before deployment.
2. Use authentication and access controls that restrict who can read or write data.
3. Audit stored information regularly and remove data that is no longer needed.
4. Rotate credentials and tokens if exposure is suspected.
5. Test generated code and infrastructure settings rather than trusting defaults blindly.

For organizations handling sensitive personal data, those steps are not optional. They are the minimum guardrails required to prevent a minor configuration error from becoming a public breach.

How the exposed data could be abused

Exposed personal information can be valuable in several ways. Names, phone numbers and addresses can feed identity theft, phishing and social engineering campaigns. Passwords and tokens can enable account compromise. Location-related records, such as license plates, can reveal movement patterns or be used to target specific individuals.

Even when a dataset appears incomplete, it can still be dangerous when combined with other information. Criminals often use small fragments of data from multiple sources to build more complete profiles of victims or employees.

In the worst cases, an exposed database can create a chain reaction: a leak leads to account access, account access leads to additional data theft, and the stolen data fuels further fraud. That is why researchers treat even partial exposure as a serious finding.

What this says about the state of AI-era infrastructure

The rise of AI coding assistants and rapid app builders has changed the economics of software production, but it has not changed the fundamentals of security. Databases still need proper controls. Authentication still matters. Sensitive information still needs to be minimized, protected and monitored.

The problem is that the new development culture is often optimized for speed, iteration and product-market fit. Security, by contrast, is about precision, patience and verification. When those incentives collide, the result can be a sprawling set of products that work well enough to launch but are not secure enough to store real user data.

Supabase is not unique in this regard. Similar exposure problems have affected many modern development platforms, cloud services and storage systems over the years. But the platform’s popularity among vibe-coded startups gives the latest findings added significance because it suggests the issue is scaling with the tools themselves.

Timeline of the issue

The problem did not emerge overnight. It has developed as AI-assisted development, easy deployment and database-as-a-service platforms have converged.

What happens next

The immediate question is how many of the exposed datasets will be secured, removed or remediated after disclosure. In cases like this, the practical outcome depends on how quickly customers respond and how effectively platform operators can help them lock down access.

The broader challenge will be whether AI-era development practices mature fast enough to keep up with the risks they are creating. As more people build software with less technical background, the industry will need clearer guardrails, better education and stronger defaults to prevent accidental exposure.

For now, UpGuard’s findings serve as a reminder that database security is still one of the most important and most overlooked parts of modern software development. The tools may be newer, but the consequences of getting configuration wrong remain painfully old-fashioned: public data, private harm and a cleanup that often comes too late.