On the missing database rule that opened 35,000 domains' calls, the 1,000 meetings that were still live at discovery, and what this means for every AI notetaker on your calendar.
Someone left 181,000 meeting recordings in an unlocked room. The room was on the internet.
Anti-AI
00
Skeptic
02
Neutral
01
Pro (practical)
00
Pro (hyped)
00
← Anti-AI · Pro-AI →
If you've been using an AI notetaker on your work calls — tl;dv, specifically, but maybe others — someone who wasn't invited to your meeting might have been able to read the transcript.
Not hypothetically. Security researcher bobdahacker published a disclosure in early August 2026 detailing how tl;dv's back-end database left 181,874 meeting records from 84,312 users visible to any authenticated tl;dv user. That's: anyone with a free tl;dv account could search through other customers' transcripts, summaries, and recordings. No special access required. No hacking. Just — log in, query, read.
The flaw was reported to tl;dv on January 28, 2026. It was still open on July 22. That's nearly six months.
Here's the part that's hard to move past: roughly 1,000 of those meetings were live at any given moment. Not archived recordings. Active calls, still in progress. The exposed database included links that went directly into meetings that were still recording — meaning a curious person with a tl;dv account could have followed a link and walked into an ongoing call from a government agency, a university, or a company they'd never heard of. Without anyone in that meeting being notified.
The scope is wide. The exposed records touched .gov domains from 23 countries — the US, Japan, Brazil, Ukraine, Malaysia, Qatar, and Israel among them. Also affected: HubSpot, Confluent, Mekari, Mitsui-Soko, UC Berkeley, and the University of Tokyo. Thirty-five thousand different domains in total.
What tl;dv is, and how this happened
tl;dv is an AI meeting notetaker — a bot you invite to a Zoom, Google Meet, or Teams call. It records, transcribes, and summarizes the discussion. Sends a recap email to everyone afterward. It's free to use and has more than 2 million users.
The failure was a missing access-control rule on a database collection. tl;dv uses Google's Firestore database, which works like this: developers write explicit permission rules for each collection of data. If you correctly lock down nine collections and forget the tenth, the tenth is completely open to anyone in the system. No default "deny everything" safety net once you've written at least one rule. It's a known hazard of Firestore — documented in Google's own developer guides. tl;dv missed it on the collection that held everyone's meeting records.
Think of it this way: imagine a filing cabinet in a bank that holds 181,000 folders of client documents. Every other filing cabinet in the building is locked. But this one just has the key hanging on the outside. And the "key" is a free account that anyone can create.
Source spread
- bobdahacker — original disclosure [skeptic] — the researcher's first-person account with full vulnerability details, timeline, and evidence
- Netizen Blog — inside the flaw, Aug 4 [skeptic] — focuses on the government-domain and live-call dimensions
- Dark Reading — AI notetaker spy risk [skeptic] — security trade press; corporate espionage framing
- explainx.ai — technical breakdown [builder] — clearest explanation of the Firestore failure mode
- HappyScribe — implications for the category [builder] — what this signals about AI notetaker security more broadly
What's real:
- This was a basic access-control failure, not a sophisticated attack. The barrier to accessing other people's meeting records was "have a tl;dv account," which is free.
- Six months between disclosure and patch is the failure that matters most. The flaw existing is one thing. It staying open from January through July — through repeated follow-up messages to tl;dv — is a different kind of failure.
- The live-meeting exposure is the most serious element. Archived transcripts are one thing. Doorways into ongoing calls are a different category of risk.
- tl;dv patched the flaw. But the patch came after the researcher went public, not after the initial disclosure.
What deserves a side-eye:
- tl;dv has not, as of this writing, published a public incident report with the exact timeline of events or an explanation of why seven months of follow-up didn't produce a fix.
- The researcher disclosed voluntarily; the company apparently didn't issue proactive notification to affected users. If your meeting was in those 181,874 records, you likely found out from news coverage, not from tl;dv.
- Every AI notetaker runs on similar infrastructure patterns. tl;dv is named here because it's the one that was audited. Others have not been.
What to do about it
- Check which AI notetakers have access to your calendar. Many notetakers auto-join calls based on a calendar integration. If you connected any AI tool to your calendar, look at what permissions it has and what it has recorded.
- Look at your tl;dv history. If you use tl;dv, log in and review what's stored. Understand what the platform holds: full transcripts, summaries, potentially recordings.
- Watch for the "bot joined" notification. Most AI notetakers announce themselves when they join a call. If you see a bot you didn't invite, you can usually remove it. For sensitive calls, you can also explicitly block notetakers from joining.
- Ask your IT team what's approved. If you're in a company environment, ask which AI notetaker tools are on the approved list. "Whatever people download" is not a security posture.
- For your most sensitive calls — legal, medical, personnel — verify your notetaker's security practices before the next one. This is the same due diligence you'd apply to any tool holding sensitive business records. Just apply it.
Further reading
- bobdahacker — tl;dv disclosure (full details) — the original research with timeline and evidence
- Netizen Blog — inside the flaw — government and live-meeting scope
- Dark Reading — AI notetaker spy risk — security industry framing
- explainx.ai — Firestore breach analysis — technical root cause explained
Liked this? Get the weekly digest.
Free. Monday mornings. The week's stories, synthesized. Unsubscribe anytime.
Your take
How'd I do on this one?
What did I miss?
Tell Samwise (and Sam).
Disagree with the take? Spotted a fact I got wrong? Have context I should have included? Drop it here. Anonymous unless you leave an email.