Tea is a women-only dating safety app with 1.6 million users in the United States. Its entire value proposition is trust. Women use it to run background checks on potential dates, anonymously flag bad actors, and share safety information with each other. The tagline is “the safest place to spill tea.”
When Tea onboards users, it asks them to upload a selfie and a government-issued photo ID to verify their identity. In return, it promises to delete that verification data immediately after authentication is complete.
On July 25, 2025, hackers accessed a legacy database Tea had never deleted. Inside: 13,000 selfies with government IDs, 59,000 additional user images, and 1.1 million private messages from women discussing divorce, abortion, infidelity, and sexual assault. The data was posted publicly. Within hours, users’ faces were being rated on 4chan.
There were actually two breaches, not one
Tea’s public disclosure framed the incident as a single event affecting a legacy database. The reality was more complicated. Security researcher Kasra Rahjerdi investigated further and found a second, entirely separate exposure.
A legacy Firebase instance containing data from users who registered before February 2024. Tea had promised to delete verification images immediately after account approval. The images were never deleted. 13,000 selfies paired with government-issued photo IDs, plus 59,000 additional images from posts and direct messages. Accessed by hackers who found an unsecured Firebase endpoint and exploited it directly.
A separate Firebase configuration where the stored messages were neither encrypted nor access-restricted. Any user with an API key could query the database directly. Researcher Rahjerdi found that 1.1 million private messages spanning from early 2023 to July 2025 were accessible. The messages included deeply personal disclosures — divorce, abortion, infidelity, sexual assault. Many contained identifying information: real names, phone numbers, meeting locations. Tea disabled direct messaging on July 29 to stop further exposure.
Three misconfigurations that caused it
What happened after the data was public
The consequences of this breach were not abstract. Within hours of the data being posted, a 4chan thread shared a custom Google Map purporting to tie the leaked verification images to the locations of women registered on the app. The thread was later deleted. Users reported being identifiable from their government IDs paired with their selfies.
The 1.1 million messages contained information that made most users’ real-world identities trivial to determine: names, phone numbers, meeting locations, combined with deeply personal disclosures. Two class action lawsuits were filed in California. Tea offered free identity protection services to affected users.
An app whose core promise was protecting women’s safety in dating became the mechanism through which their identities, locations, and most private conversations were exposed. The breach didn’t undermine the brand. It directly contradicted everything the product was supposed to be.
The pattern that keeps repeating
This breach follows an entirely familiar pattern. A company promises to delete sensitive data, does not build the process to actually do it, runs a secondary database without monitoring, and discovers the gap when a researcher or attacker finds it first.
The Tea breach is not a story about a sophisticated attacker. It is a story about a company that grew fast — Tea became the number one free app on the US App Store before this incident — and whose security infrastructure did not grow with it. Legacy systems were not audited. Data lifecycle policies were not enforced in the infrastructure. Cloud configuration was not independently verified.
-
✓
Continuous cloud posture management that maps every active storage instance, flags publicly accessible resources, and alerts when data that should be restricted is exposed. -
✓
Data lifecycle enforcement that translates privacy promises into actual deletion workflows. If Tea’s infrastructure had enforced the deletion it promised, there would have been nothing to leak. -
✓
Encryption at rest for sensitive user data — particularly any data involving identity verification. An encrypted database does not become usable when someone gains access to the endpoint. -
✓
Regular audits of legacy and decommissioned systems to ensure that databases believed to be unused are not still running, still accessible, and still holding data.
The Tea breach is particularly instructive because none of the failures were novel. Misconfigured Firebase. Undeleted legacy data. No access controls on sensitive storage. These are documented, well-understood problems with known solutions. The breach happened not because the solutions didn’t exist but because nobody had run the check.
Cloud misconfigurations and legacy data exposures are the most common source of breaches that should never have happened.
Osto runs continuous cloud posture management across your environment, flagging misconfigured storage, unencrypted data, and publicly accessible resources before an attacker or researcher finds them. For companies handling identity or sensitive user data, this isn’t optional infrastructure. It’s the check that tells you whether your privacy promises match your actual configuration.
If you haven’t audited your cloud environment recently, the honest answer is that you don’t know what’s sitting in a legacy instance that nobody has looked at in 18 months.