A September 2026 scan found 16,326 public databases behind live apps, most of them built with AI coding tools, and the fix is one setting almost nobody checks

A researcher scanned roughly 300,000 websites in September 2026 for signs of a common backend setup, the kind that pairs a database with ready-made login and API access so a new app can go live in days instead of months. Of those, 16,326 had at least one database table that anyone with the link could read: no password, no login, nothing. More than half showed signs of real personal data sitting inside those open tables.

No one broke in to find this. That's the part worth sitting with. The researcher didn't exploit a flaw; they asked the database a plain question and it answered, because the setting that would have refused the question was never turned on. The gap traces back to how the table got built. Made through the platform's own visual dashboard, the protection switches on by itself. Made the way an AI coding assistant actually wires up a new backend, through a direct API call, it doesn't.

That distinction matters because of who is building backends through the API path right now. It's the fastest-growing way a small team or a first-time founder ships a working product: describe what you want, let an AI coding assistant generate the database, the login, and the app in one sitting. The tool is built to make the demo work. Whether the data behind it is actually locked down isn't something most of those tools check, and that gap is what this piece covers: what the September scan found, what the wider data on AI-generated code says about why this keeps happening, and the one check that would have caught all 16,326 of these before a researcher did.

Start with the scan itself. UpGuard's research, published September 25, 2026, checked around 300,000 domains showing signs of this setup and found 16,326 databases with at least one publicly readable table ^[1]. More than half carried indicators of personal data in their schemas: names, emails, phone numbers, order history. A smaller group went further, exposing stored passwords or authentication tokens directly, and a handful carried what looked like payment card data ^[1]. None of that required cracking anything. The researcher built a list of the same kind of sites everyone else builds and checked whether the front door was locked.

The reason traces back to a single default. The backend platform behind this scan, like most that pair a database with instant APIs, turns on row-level access protection automatically when a table is created through its own dashboard. Create the same kind of table programmatically, the way an API call does, and the way an AI coding assistant actually does it when it generates a backend in one pass, and that protection does not turn on by itself ^[1][2]. The table behaves identically either way. One version just happens to answer any question anyone asks it.

This isn't a one-off platform quirk. Veracode's 2026 GenAI Code Security Report tested more than 100 models across four rounds of benchmarking and found the average security pass rate at 56%, barely moved from the year before, while the same models write syntactically working code essentially every time ^[3]. The code runs almost all the time. Whether it's safe to run is close to a coin flip, and giving the model no explicit security instruction pushes the failure rate to roughly 44% ^[3]. Coding-focused models scored no better on security than general-purpose ones in the same report ^[3].

A separate, independent benchmark makes the same point from a different angle. Researchers took 200 real feature requests pulled from open-source projects, each one a case where a human developer had originally shipped a vulnerable fix, and had an AI coding agent attempt the same request fresh. The agent produced a functionally correct solution 61% of the time. Only 10.5% of those solutions were actually secure ^[4]. Telling the agent about the known vulnerability ahead of time didn't meaningfully change the outcome ^[4].

The exposure runs one layer deeper than the database. A 2025 academic study that ran 576,000 code samples through 16 different models found that 19.7% of the package names those models suggested did not exist: invented dependencies that sound plausible and aren't real ^[5]. Anyone can register one of those fake names on a public package registry and ship whatever they want inside it, and attackers already have: one security researcher's own stand-in package pulled over 30,000 downloads in three months just by matching a name models kept inventing ^[5]. Open-source models hallucinated these names at roughly 21.7% of the time against 5.2% for commercial ones ^[5], and the underlying risk doesn't depend on which model wrote the code. It depends on whether anyone checked that every package it pulled in is real before it shipped.

The common thread across these four findings is where the checking stops. Every tool here does what it's optimized to do extremely well: produce code that runs. Whether the database behind it is locked down, whether the packages it pulled in actually exist, whether the demo that worked on day one still works safely on day ninety: none of that is what gets checked by default, and for 16,326 live databases in September 2026, nobody else checked either.