tl;dv Data Breach: 181,874 Meetings Exposed, Live Calls Joinable

A single missing access-control rule on one database collection turned tl;dv, an AI meeting-notes and transcription platform used by more than 2 million people, into a searchable index of other people's video calls. Independent security researcher bobdahacker disclosed in August 2026 that tl;dv's Firestore database exposed 181,874 meeting records belonging to 84,312 users, and that roughly 1,000 of those meetings were, at any given moment, still recording — meaning their links were doorways into live calls a stranger could join uninvited. The full writeup, "tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open," is the original source for this incident; explainx.ai did not independently verify tl;dv's backend, and everything technical below is paraphrased from that disclosure with direct attribution.

This is the latest entry in explainx.ai's coverage of AI-product security failures, alongside our writeups of the Tailscale/Hugging Face intrusion and the OpenAI–Hugging Face incident timeline. Like those, it's a story about identity and access boundaries failing quietly in production for months before anyone outside the company noticed.

TL;DR

How the vulnerability worked

tl;dv authenticates users with a JWT, which the client exchanges for a Firebase token via gw.tldv.io/v1/users/firebase/token. That token is what grants read access to tl;dv's Firestore database, at projects/lmi-store/databases/(default). Firestore is not secure by default — every collection needs its own explicit security rule defining who can query what, and tl;dv had correctly written that rule for nearly every collection in its schema: users, chats, transcripts, clips, recordings, videos, notes, teams, and organizations all returned a 403 Forbidden the moment a client tried to query across tenants.

The meetings collection was the exception. According to the disclosure, any authenticated tl;dv account — including a brand-new, free-tier signup — could query that one collection and pull back every meeting record on the platform, not just its own. Each record carried the creator's email address, the conference ID, the video provider (Google Meet or Microsoft Teams), the recording status, and timestamps.

This is a textbook example of the Firestore footgun that's shown up across multiple unrelated startups' breaches this year: the platform requires developers to write security rules per collection, and it is entirely possible to correctly lock down nine collections and miss a tenth. There's no default-deny safety net once at least one rule exists — a missing rule on a specific collection just means that collection is open to anyone with a valid token, full stop.

Live calls, not just metadata

The status: recording field is what made this more than a privacy-policy violation. A meeting record in that state meant tl;dv's bot was actively inside a live call, and the conference ID in the record was a working, joinable link into it. The researcher reported that roughly 1,000 meetings sat in this state at any given moment across the exposed collection — a live feed of calls an outsider could join in real time by watching the database.

Two proofs of concept illustrate the risk plainly:

1. A call belonging to the Malaysian Ministry of Education, with a presenter addressing 157 participants. tl;dv's own recording bot was already present; the researcher joined alongside it, unannounced and uninvited.
2. A call with 21 students from a US university, mid-demo of a startup prototype — screen-sharing their app while, per the disclosure, discussing adding client-side email validation and setting up Supabase live on screen.

Neither meeting had any indication an outsider had entered. That's the practical difference between "our database leaked some emails" and "a stranger can silently sit in on your organization's live video calls" — a distinction worth keeping in mind next to our guide on restricting what a locally-installed AI agent like Claude Desktop can access, since the risk model is the same underlying question: what does this software actually have standing access to, and who else can reach it through the same door.

The scale: 84,312 users, 35,003 domains, 23 governments

Querying the exposed collection surfaced 181,874 meeting records across 84,312 unique users and 35,003 unique email domains. The disclosure breaks that down into a few notable buckets:

• Government meetings from 23 countries — all .gov-class domains — including Brazil, Colombia, Peru, Ukraine, El Salvador, the Philippines, Chile, Indonesia, Mexico, the United States, Qatar, Malaysia, Uzbekistan, Sri Lanka, Haiti, South Africa, Jamaica, Honduras, Argentina, Thailand, Japan, Israel, and Belize.
• Universities, including Berkeley, the University of Tokyo, De La Salle, and Universidad Nacional de Colombia.
• Corporate accounts across the remaining ~35,000 domains, including Mitsui-Soko (484 meetings across four regional offices), Mitsui Fudosan, HubSpot, Confluent, Mekari, and AnyMind Group.

Usage patterns embedded in the metadata are almost incidental but telling: peak activity was July 2025 with 43,209 meetings recorded platform-wide, and the single busiest recurring slot was Wednesday 2pm UTC with 7,804 meetings — standup-hour clustering, visible only because the collection itself had no access boundary.

Beyond metadata: actual meeting content leaked too

Metadata exposure alone would be a serious incident. The disclosure goes further: the researcher scraped 27,334 meeting IDs from the exposed collection to check which ones had public sharing enabled — tl;dv meetings default to private, but individual users can toggle sharing on. Over 1,000 meetings had public sharing turned on, exposing 715 invitee email addresses across 228 domains once those shared pages were pulled.

Named examples from the disclosure include a Brazilian government conservation meeting (PACTO Mata Atlântica) with participants from WWF, The Nature Conservancy, Conservation International, WRI, and the São Paulo state government; meetings involving Ukraine's Ministry of Digital Transformation; and a HubSpot sales call. None of those organizations opted into having their meeting participant lists become queryable by an unrelated third party.

A second, unrelated bug: the World Cup game

The disclosure includes a separate, lower-severity finding worth noting for completeness. tl;dv's internal employee World Cup prediction game (worldcup.tldv.io, built on the Base44 no-code platform) had a completely unauthenticated API endpoint — GET /api/entities/Player — that returned all 43 players' data with no session or auth requirement whatsoever. That leaderboard data exposed 19 @tldv.io employees' full names and corporate email addresses, plus the personal Gmail address of the person tl;dv itself lists as its security disclosure contact, pulled from the same unauthenticated leaderboard.

It's a minor bug next to the Firestore issue, but it fits the same pattern: an internal tool built quickly on a no-code platform, shipped without anyone asking whether its API needed auth at all.

Disclosure timeline: "still not fixed," for months

The accountability story is arguably the more important half of this disclosure. According to the researcher's account:

• Late January 2026 — the researcher discovers the tenant-isolation bypass.
• January 28, 2026 — contacts tl;dv co-founder Raphael Allstadt directly via LinkedIn. Allstadt responds within minutes, asks the researcher to email the company's CTO, and says it will be looked at "immediately."
• January 29 – March 6, 2026 — repeated follow-ups from the researcher, each time reporting the flaw was "still not fixed." Allstadt offers reassurances without a fix: "I am sure the team is reviewing it very very soon," and later, "We're on it. It needs some time." The CTO, named as the actual point of contact, reportedly never personally responds.
• July 22, 2026 — the researcher's last documented check before writing up the disclosure: still unfixed.
• Around the public disclosure in early August 2026 — per commentary on the Hacker News discussion thread, tl;dv appears to have patched the collection only in the days immediately surrounding the post going live, roughly six months after the initial report. tl;dv also published its own response, framing the finding partly by noting that other AI/SaaS products have recently had similar public-sharing-setting issues surface — tl;dv's own characterization, not a claim explainx.ai is independently verifying.

Six months between "we'll look at it immediately" and a fix, on a bug that let any signed-in user list every meeting on the platform, is the part of this story that should worry potential customers more than the bug itself. Vulnerabilities happen; a security program is measured by what happens in the six months after report number one.

Why "SOC 2 compliant" didn't help

tl;dv's security page lists SOC 2 compliance, GDPR compliance, EU AI Act compliance, and AES-256 encryption. All of that can be true and this incident still happens, because none of those attestations audit whether a specific Firestore collection has the same access-control rule as its siblings. SOC 2 evaluates whether an organization has documented controls and follows its own process consistently — it is an audit of process maturity, not a penetration test of every query path in a production database. A missing rule on one collection, out of a dozen, is exactly the kind of implementation detail a SOC 2 report is not designed to catch.

This is a recurring theme worth internalizing for anyone evaluating an AI SaaS vendor: compliance badges tell you a company has a paperwork trail, not that a specific engineer didn't forget one rule in one collection. The useful question isn't "are they SOC 2 compliant" — most vendors in this category are — it's "what happened the last time someone reported a real bug," which is exactly what this disclosure's six-month timeline answers for tl;dv.

The broader pattern: Firestore, and the wider AI-tooling breach wave

Commenters on the Hacker News thread pointed out that Firestore's per-collection security-rule model is a recurring root cause across multiple unrelated startups' breaches this year — not a tl;dv-specific design flaw, but a structural footgun. Firestore requires an explicit rule per collection and enforces nothing by default; it's straightforward to correctly lock down nine collections and simply miss a tenth, exactly as happened here.

The thread also connected this incident to a broader pattern in AI-adjacent tooling: a separate, unrelated breach at a company called Mercor reportedly exposed roughly 4TB of contractor voice recordings, government ID scans, and selfie verification photos — different company, different mechanism, but further evidence that AI-hiring and verification tooling is accumulating the same class of exposure risk as AI meeting recorders. Readers evaluating vendor security should treat this as one incident in a pattern, not an isolated tl;dv problem — a lens we've also applied to why AI agents keep hacking the companies that build them.

Several commenters also raised a subtler risk specific to meeting recorders: exposed recordings capture people's actual speech patterns, which is raw material for voice-cloning and vishing (voice-phishing) attacks. A leaked transcript is a privacy problem; a leaked recording of someone's voice is a separate, ongoing impersonation risk that outlives the original breach.

What to do instead — the local-first pushback

A recurring thread in the Hacker News discussion was a broader loss of trust in cloud-hosted meeting recorders generally, not just tl;dv specifically. Several commenters said this incident pushed them toward exploring local-only transcription tools that never send recordings or transcripts to a third-party server at all — a project called meetily and a commercial local-first tool called Whistle (whose own developer commented in the thread) both came up as examples of that alternative category. explainx.ai isn't endorsing any specific product here; the useful takeaway is that "local-first meeting transcription" is now a real, actively-discussed category for readers who've decided the convenience of a cloud AI notetaker isn't worth the tenant-isolation risk on someone else's database.

If you're evaluating AI tools generally — meeting recorders, browser extensions, or desktop agents — the access-boundary questions are the same ones we walk through in our MCP security guide and our Claude in Chrome safety guide: what does this tool have standing access to, is that access scoped per-account or per-tenant, and what happens when — not if — one access-control rule gets missed.

Honest limitations of this writeup

• explainx.ai did not independently verify tl;dv's backend, Firestore schema, or the researcher's raw query logs — this post relays a third-party disclosure, not our own investigation.
• The claim that tl;dv patched the issue "around" the public disclosure comes from community commentary on the Hacker News thread, not a confirmed tl;dv changelog entry — treat the exact fix date as approximate.
• tl;dv's own response post frames some of this defensively; we've represented that framing as tl;dv's characterization, not as verified fact.
• Numbers throughout (181,874 meetings, 84,312 users, 35,003 domains, etc.) are as reported in the original disclosure and have not been independently recomputed.

FAQ

What happened with tl;dv's data breach? A missing tenant-isolation rule on tl;dv's meetings Firestore collection let any authenticated user — including free accounts — query every meeting record on the platform, not just their own.

How many meetings and users were exposed? 181,874 meeting records across 84,312 unique users and 35,003 email domains, per the researcher's disclosure.

Could attackers actually join live calls, or was this just metadata? Both — around 1,000 meetings at any moment showed status: recording, and their exposed conference IDs were working links into those live calls.

Was tl;dv's SOC 2 / GDPR compliance meaningful here? Not for this specific failure — those attestations audit process and documentation, not whether a single database collection has the same access rule as its siblings.

Has tl;dv fixed the vulnerability? It reportedly remained open from the January 28, 2026 report through at least July 22, 2026, and appears to have been patched only around the public disclosure in early August 2026.

What should I do if I use tl;dv or a similar AI meeting-notes tool? Audit your default sharing settings, rotate any credentials discussed on recorded calls, ask the vendor about their disclosure-response track record rather than just their compliance badges, and consider a local-first transcription tool for meetings you can't risk having stored in someone else's database.

Related reading

• Tailscale on the Hugging Face intrusion — reusable auth keys and workload identity
• OpenAI–Hugging Face Black Hat video timeline
• Four labs, one month: why "my AI hacked a company" stopped making news
• How to restrict what Claude Desktop can access on your computer
• Claude Opus 5 rm -rf'd a Reddit user's drive: the sandbox guide
• Claude in Chrome: features, access & safety
• MCP security guide 2026

Sources

• bobdahacker — tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open (original disclosure, August 2026)
• Hacker News discussion (236 points, ~79 comments)

Follow @explainx_ai for more AI-product security coverage.

This post relays a third-party security disclosure published by an independent researcher on bobdahacker.com. explainx.ai did not conduct its own investigation of tl;dv's infrastructure. Figures, quotes, and the disclosure timeline reflect the researcher's public writeup and community discussion as of August 10, 2026 — verify current status directly with tl;dv before making a vendor decision.