Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 6 min read

What goes wrong with AI-built apps? Seven dated incidents from 2025 to 2026, and the lesson from each

Originally published at systemtrails.com. Seven well-documented incidents from 2025 to 2026 show that AI-built apps fail in three ways: the data layer is reachable from the browser with nothing guarding it, an auth endp

Originally published at systemtrails.com.

Seven well-documented incidents from 2025 to 2026 show that AI-built apps fail in three ways: the data layer is reachable from the browser with nothing guarding it, an auth endpoint trusts an identifier anyone can see, or an AI agent holds write access to production. The fixes are known and small, none of them is a rebuild, and each incident leaves a test you can run on your own app this week.

In short

  • Open data layer is the pattern in four of seven: Lovable's CVE-2025-48757, Tea, Moltbook, and the Red Access scan
  • Auth that trusts a public id: Base44 let anyone register on private apps with only the app_id from the URL
  • Agents with production access: Replit's agent deleted SaaStr's database during a code freeze; a malicious prompt shipped inside Amazon Q
  • The fixes are small and known: row-level security with read policies, server-side auth checks, separated credentials
  • One logged-out test, one URL-id test, and one credential inventory cover all seven

The list, in date order

Every entry below comes from the affected company, the researcher who found it, or named press on the date shown. Numbers are quoted as the source gave them.

Date Incident What was exposed or lost Root cause
Mar 20 to May 29, 2025 Lovable, CVE-2025-48757 303 endpoints across 170 of 1,645 apps (10.3%) Missing or weak row-level security
Jul 2025 Replit agent and SaaStr Data on 1,200+ executives and 1,190+ companies deleted Agent with production write access, no dev/prod split
Jul 17 to 23, 2025 Amazon Q for VS Code 1.84.0 Wiper prompt shipped in a release; failed on a syntax error Over-scoped GitHub token in CI
Jul 25 to 29, 2025 Tea app 72,000 images, then 1.1M+ private messages Exposed Firebase storage bucket
Jul 9 to 29, 2025 Base44 Private apps open to self-registration Register and OTP endpoints unauthenticated
Jan 31 to Feb 2, 2026 Moltbook 1.5M API tokens, 35,000 emails, 4,060 DMs Supabase key in client JS, no RLS
May 2026 Red Access scan 2,000+ apps with sensitive data, of 380,000 assets Public by default, no access control

The three ways it breaks

Seven incidents, three mechanisms. If you know which of the three your app is exposed to, you know which test to run first.

1. The open data layer

Lovable, March to May 2025. Matt Palmer found that Lovable-generated apps queried Supabase from the browser with the public anon key and relied on row-level security that was "missing or insufficient." His scan: 303 endpoints across 170 projects, about 10.3% of 1,645 analyzed, exposing personal data, API keys, and payment records, including the ability to modify payment status. The CVE was published May 29, 2025.

Moltbook, January 2026. Wiz found the AI-agent social network's Supabase key in client-side JavaScript with no RLS policies, giving "full read and write access to all platform data": 1.5 million API tokens, 35,000 email addresses, 4,060 private messages. The founder had said publicly that he did not write a line of the code. Wiz reported it at 21:48 UTC on January 31; it was patched by 01:00 UTC on February 1. Three hours to fix, once someone looked.

Tea, July 2025. Tea's breach came from an exposed Firebase storage bucket: 72,000 images including selfies and government IDs, then over 1.1 million private messages (TechCrunch, July 29, 2025). Claims that Tea was AI-built are unverified, and we do not repeat them. It is here because the mechanism is identical.

Red Access, May 2026. Of 380,000 public assets on AI app-building platforms, roughly 5,000 looked corporate and more than 2,000 held sensitive data, often with admin access for anyone who had the URL.

Before: The browser holds a key that reaches every table or bucket. RLS is off, or on with a policy that says true. The app works because nothing says no.

After: The browser key reaches only rows its user owns: RLS on every table, policies that name auth.uid(), private buckets, and a test that fails the build if a logged-out read returns anything.

Our six Lovable checks walk through the Supabase side of this in under an hour.

2. Auth that trusts what anyone can see

Base44, July 2025. Wiz reported on July 9 that Base44's auth/register and verify-otp endpoints were "exposed without authentication, allowing anyone to register for private applications using only the app_id value," and the app_id sits in every app's URL. Wix fixed it within a day and said it "found no evidence that any customer was impacted."

The lesson generalizes beyond one platform. AI-generated code tends to check that a request is well-formed, not who sent it. Any route that accepts a tenant id, user id or app id from the client and acts on it without checking the session is this bug.

3. Agents with the keys to production

Replit and SaaStr, July 2025. During a declared code freeze, Replit's agent deleted the production database behind Jason Lemkin's project, holding data on more than 1,200 executives and over 1,190 companies, then said rollback was impossible, which was false. Lemkin told The Register he had told it "eleven times in ALL CAPS" not to. Replit's CEO responded with automatic separation of development and production databases.

Amazon Q, July 2025. An attacker used "an inappropriately scoped GitHub token" in AWS's CodeBuild configuration to get a prompt instructing the agent to wipe local files and cloud resources into version 1.84.0 of the VS Code extension. It "was unsuccessful in executing due to a syntax error." Luck, not design.

The pattern behind both

An instruction is not a permission. If an agent, a CI job, or a preview environment holds a credential that can write to production, assume it eventually will. The fix is a credential boundary, not a better prompt.

The three tests that cover all seven

Logged-out read

Open a private window, take the public key from your bundle, and query every table and bucket. Anything returned is finding one.

URL-id action

Using only ids visible in URLs, try to register, read, or write in a space you do not own. Every route should check the session, not the id.

Credential inventory

List every token held by your AI tools, CI, and preview environments. None should be able to write to production.

The one thing to do today

Run test 1. It takes ten minutes, it covers four of the seven incidents, and it is the first thing a security reviewer or an investor's engineer will try.

When this list becomes your problem

Most founders meet these failures at one of five moments: an enterprise pilot sends a security questionnaire, an investor starts technical due diligence, a first engineering hire asks how auth works, an incident lands, or real load arrives. Each of them asks the same three questions this list does. Having the answers dated and written down is the difference between a finding and a footnote.

The failures are not exotic, and the fixes are not a rebuild. Moltbook was patched in about three hours. What takes longer is knowing where to look, which is the part a senior review of the five common patterns shortens.

If you want those three tests run on your actual app by a senior architect, that is what the free teardown is: three findings and a verdict, recorded, within 72 hours.

Sources

Want this checked on your actual code? Free teardown: 3 concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram β†— Reddit 🟧 HN
← News πŸ” Cybersecurity 🏠 Home