{"id":225,"date":"2026-05-01T05:07:51","date_gmt":"2026-05-01T05:07:51","guid":{"rendered":"https:\/\/blog.osto.one\/?p=225"},"modified":"2026-05-06T16:28:11","modified_gmt":"2026-05-06T16:28:11","slug":"womens-safety-app-exposes-private-messages-data-breach","status":"publish","type":"post","link":"https:\/\/www.osto.one\/resources\/incidents\/womens-safety-app-exposes-private-messages-data-breach\/","title":{"rendered":"The App Built to Keep Women Safe Just Exposed 1.1 Million of Their Private Messages"},"content":{"rendered":"

<\/p>\n

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.”<\/p>\n

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.<\/p>\n

<\/p>\n

\n

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.<\/p>\n<\/div>\n

There were actually two breaches, not one<\/h2>\n

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.<\/p>\n

<\/p>\n

\n
\n
Breach 1 \u2014 The legacy database<\/div>\n

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.<\/p>\n<\/p><\/div>\n

\n
Breach 2 \u2014 The private messages<\/div>\n

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 \u2014 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.<\/p>\n<\/p><\/div>\n<\/div>\n

Three misconfigurations that caused it<\/h2>\n

<\/p>\n

\n
\n 1<\/span><\/p>\n
\n
Data that was promised to be deleted was never deleted<\/div>\n
Tea told users that government ID verification images would be deleted immediately after account approval. Those images remained on legacy servers, out of sight, for over a year. A data lifecycle policy that was communicated to users simply did not exist in the infrastructure. The gap between the privacy promise and the actual data handling practice was the entry point.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n 2<\/span><\/p>\n
\n
Firebase configured without encryption or access controls<\/div>\n
Firebase is a legitimate, widely used platform. But using Firebase doesn’t inherit its security defaults. Tea’s implementation left image and message data neither encrypted at rest nor access-restricted. The Firebase API was public-facing. Anyone who found the endpoint and had an API key could retrieve raw user data. This is a configuration choice, not a platform vulnerability. The platform was fine. The configuration was not.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n 3<\/span><\/p>\n
\n
Legacy systems left running without audit or monitoring<\/div>\n
The compromised database was a legacy instance. Tea had migrated forward but the old database remained active, accessible, and unmonitored. No continuous cloud posture management was running to flag the exposure. No audit had been run to map what data lived where. It was simply forgotten infrastructure that hadn’t been decommissioned.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n

What happened after the data was public<\/h2>\n

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.<\/p>\n

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.<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n

The pattern that keeps repeating<\/h2>\n

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.<\/p>\n

The Tea breach is not a story about a sophisticated attacker. It is a story about a company that grew fast \u2014 Tea became the number one free app on the US App Store before this incident \u2014 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.<\/p>\n

<\/p>\n