72,000 photos and no lock on the door
A women's safety app promised anonymity, then left 72,000 user photos, including 13,000 selfies and government IDs, in a cloud storage bucket with no authentication. Anyone with the link could download them. Here is how the same missing guardrail keeps shipping, and what a release gate catches first.
- security
- vibe coding
Tea was a dating safety app for women. The whole premise was protection: you verified you were a woman by uploading a selfie, sometimes a photo of your driver’s license, and in return you got an anonymous space to warn other women about the men they might date. By July 2025 it had more than 1.6 million users and had climbed to the top of the App Store.
On July 25, 2025, a post appeared on 4chan with a link. Behind the link was Tea’s cloud storage, wide open. No password, no login, no access control of any kind. One person described it plainly: “No authentication, no nothing. It’s a public bucket.” The app built to keep women safe had left their faces and their government IDs sitting on the open internet.
What was exposed
The storage was a Firebase bucket (part of Google’s app platform), and the misconfiguration was the whole story: the files were reachable by anyone who had the URL, without authenticating. As reported by 404 Media, who broke the story, and laid out in security.org’s timeline:
- Roughly 72,000 images in total
- About 13,000 of them were verification selfies and government IDs (driver’s licenses and passports)
- About 59,000 were images from posts, comments, and direct messages
Tea had told users the ID photos were deleted right after verification. They were not. The company had migrated to newer storage in early 2024 but left the legacy data behind, still readable, in the bucket nobody locked.
It got worse. Some of the leaked photos still carried GPS metadata, so within hours someone had built a map plotting the locations of affected users. Three days later, on July 28, a second exposed database surfaced, this one holding more than 1.1 million private messages: conversations about relationships, health, abortion, and phone numbers, all the things people share when they believe a safety app is safe.
The same bug, wearing a different backend
We keep writing about this because it keeps happening. In the Moltbook breach it was a Supabase database with Row-Level Security switched off and the public key in the frontend, which added up to an unauthenticated admin login to production. In the Lovable flaw we wrote about earlier, CVE-2025-48757, it was generated apps shipping that same missing RLS across more than 170 confirmed apps. Tea is that story with Firebase instead of Supabase: a storage layer whose access control was never turned on, so the “private” data was public by default.
The backend brand changes. The mistake does not. Every one of these is a place where the thing that makes cloud storage safe (an access rule, an RLS policy, an auth check) was simply never configured, and the app ran perfectly fine without it right up until a stranger pointed a browser at it.
Why the model does this to you
Was Tea vibe coded? The company never published a root cause, and it is only fair to say so. But within hours the security conversation had turned to vibe coding (Vercel’s CEO among those weighing in), and analysts who looked at the app reported API keys and client tokens hardcoded into the source. Whatever the exact origin, the failure is the signature vibe-coding failure, and it is worth understanding why.
Ask an AI assistant to “let users upload a selfie for verification” and it will wire up working file uploads in minutes. The files go up, the app reads them back, the demo works. What the model will not do, unless you know to demand it, is write the storage rules that decide who is allowed to read those files. Firebase, like Supabase, will run perfectly with its storage left wide open; the access rule is a step you add, and it is invisible in a demo, because the app behaves identically whether the bucket is locked or not. The difference only shows up when someone who is not you asks for the file.
That is the trap. The person doing the prompting cannot review a security rule they never knew was missing, and “it works” gives no signal at all that it is unsafe.
What a release gate catches here
Tea did not need a bigger model or a slower team. It needed one look across the whole surface before real users started uploading their driver’s licenses. A five-layer scan flags every piece of this:
- Configuration: a Firebase (or any cloud) storage bucket readable without authentication is a misconfiguration finding on its own, and one of the highest-signal ones there is.
- Secrets: the API keys and client tokens hardcoded into the app surface as exposed credentials.
- Code: verification images retained long after they were supposed to be deleted, and file access with no server-enforced authorization, are exactly the data-handling and broken-access-control patterns static analysis is built to flag.
Any one of those is a release blocker. Together they are an unambiguous no-go, which is the entire point of a gate: not three separate dashboards to triage, but one decision before the app is live. We laid out how the layers correlate into that single answer in the five layers of a release gate.
The hardest part of the Tea story is how ordinary the mistake was. Not a zero-day, not a sophisticated attacker, just a bucket with the lock left off, found with a URL. Vibe coding can build a safety app in a weekend. It can leave it unlocked in the same weekend. The weekend build was never the risk. Shipping it without one honest look was.