NearScrub

2026-08-30

The Tea app breach leaked 72,000 images — and their EXIF data was reportedly turned into a map of users

The Tea app's July 2025 breach is usually told as a story about verification selfies and photo IDs ending up on 4chan — which it was. But there's a second, quieter layer to what happened, and it's the one with a lesson for anyone who uploads photos to any app: once those files leaked, they carried everything they had always carried. That included, in many cases, EXIF metadata — and within days, the claim circulating alongside the dump wasn't just "here are the photos," it was "here is a map of where these women are."

What actually happened

On July 25, 2025, 404 Media reported that Tea — an app built for women to anonymously share warnings about men they'd dated, which had just topped the App Store charts — had been breached. There was no sophisticated intrusion to speak of: users on 4chan found an exposed database hosted on Google's Firebase platform that, in 404 Media's words, lacked authentication controls entirely. The files were simply downloadable, and 4chan threads promptly filled with users' driver's licenses and selfies.

Tea's own statement put numbers on it: approximately 72,000 images were exposed — about 13,000 of them selfies and photo IDs submitted during account verification, and about 59,000 images that had appeared in posts, comments, and direct messages. All of it came from what the company called a "legacy data storage system" holding data from before February 2024. Four days later it got worse: TechCrunch reported a second exposure of more than 1.1 million direct messages — conversations running from early 2023 up to that very week — after which Tea disabled messaging entirely.

The files that weren't supposed to exist

The detail that turned this from a security failure into a trust failure: those verification photos weren't supposed to be there at all. As the National Law Review's write-up of the incident notes, Tea's 2022 privacy policy told users verification photos would be "securely processed and stored only temporarily and will be deleted immediately following the completion of the verification process." The breach demonstrated, in the most public way possible, that a retention promise is a statement about intent — and that the person uploading the file has no way to verify, then or ever, whether it's being kept.

The metadata layer: from leaked photos to a claimed map

Then came the part that's specifically about the files rather than the servers. Simon Willison, reviewing the incident the next day, made an observation most coverage skipped: "Many of those photos included EXIF location information too." A photo taken with location services on carries its GPS coordinates inside the file, and an app that stores the raw upload stores the coordinates with it — so when the raw files leaked, the coordinates leaked as part of them. NPR's reporting a week later described where that went: "Online trolls also claimed to have sourced the metadata included in the photos and used it to make a map of Tea subscribers' locations."

Two honesty notes belong here, the same kind this blog attaches to every incident story. First, the map is a claim: NPR reports it as something trolls said they did, and the National Law Review likewise describes it as circulating on X rather than independently verified — this post keeps it hedged for exactly that reason. Second, the hedge doesn't rescue anyone: whether or not any particular map was accurate, the coordinates that would make one possible were genuinely in the leaked files, readable by anyone with the dump and any EXIF viewer. The uncertain part is what was built from the data, not whether the data was there.

Three layers of harm, decided at three different moments

Pull the incident apart and a leaked photo turns out to carry three different kinds of exposure, each decided at a different moment by a different party — which is what makes this a different story from the ones this blog has covered before. The Partiful case was a platform that intended to strip GPS data and shipped a bug; the marketplace-tests post was about platforms' upload pipelines varying by policy. Tea is the third failure mode: a platform that kept raw files it said it wouldn't, until a breach published them wholesale.

Three layers of a leaked photo — and who decides each 1 · The picture itself — a face, an ID document Decided when you choose what to photograph and where to send it. No tool changes this. 2 · Metadata inside the file — EXIF GPS, timestamp, device Decided before upload. NearScrub removes it in the browser, so a later leak has nothing to carry. 3 · What the server keeps — retention, copies, logs Decided by the platform's code and policy — outside your control the moment the upload completes.
Layer 3 is what failed at Tea — twice, counting the retention promise and the open database. Layer 2 is the only one a user can close unilaterally, and it's the layer that turned leaked portraits into claimed coordinates.

The layer you can actually close

That middle layer is what NearScrub handles, and the Tea case is the cleanest argument for handling it before upload rather than trusting anyone to handle it after. Drop a JPEG in and the entire EXIF block — GPS coordinates, capture timestamp, device identifiers — is removed, along with XMP, IPTC/Photoshop fields, and embedded comments, entirely inside the browser tab: no upload, no server, and the scrubbed copy is written as a new file next to your untouched original. A PNG gets the same treatment for its text and timestamp chunks. A batch of files shows you a report of what each one actually carries before anything is removed. A file cleaned this way can still leak, if the service you send it to gets breached — but what leaks is the picture, not the picture plus the coordinates of your home.

What pre-upload scrubbing honestly can't fix here

Three limits are worth stating plainly, because the Tea incident runs into all of them. If an app captures your verification selfie with its own in-app camera, there's never a file on your device to scrub first — the pre-upload step only exists for photos you pick from your library. An ID photo's harm is mostly its visible content: stripping EXIF from a driver's license photo removes the coordinates, not the license, and nothing about metadata removal makes uploading identity documents safe. And nothing you do to a file controls layer three — whether a platform honors its deletion policy, secures its storage, or logs its own location data about you is its code and its conduct, invisible from outside, as 72,000 images' worth of people found out at once. One more practical note: iPhones shoot HEIC by default, which NearScrub doesn't parse — convert to JPEG first (or share via a route that converts automatically), then scrub the JPEG.

The habit

The Tea breach compressed the whole argument for pre-upload metadata hygiene into one news cycle: a platform's promises about your files are unverifiable, its storage can outlive those promises by years, and when it fails, it fails for everyone at once — with every byte those files carried. You can't audit anyone's Firebase configuration before signing up. You can make sure the photos you hand over would have nothing to add to a map. Strip the metadata while the file is still yours; after upload, it never is again.