WHAT HAPPENED, IN FOUR LINES
● The flaw: tl;dv's Cloud Firestore meetings collection had no tenant isolation. Any authenticated user could query every record on the platform.
● The scale: 181,874 meeting records, 84,312 users, 35,003 email domains, government domains from 23 countries.
● The escalation: records included live conference IDs. Roughly 1,000 meetings were recording at any moment. The researcher joined calls uninvited.
● The response: Six months of silence. Reported January 28, 2026. Still open in July. The CTO never replied.
The specific technical failure
tl;dv drops a bot into your Google Meet, Zoom or Teams call, records it, transcribes it, and generates AI summaries. More than 2 million people use it.
When you sign up, the platform authenticates you with a Firebase token. That token is supposed to scope your reads to your own tenant. Security researcher bobdahacker found that the meetings collection in Cloud Firestore carried no such rule. A normal account, free tier included, could obtain a Firebase auth token and query the collection wholesale.
Each returned record contained:
- Meeting creator email address
- Conferencing provider (Meet, Zoom, Teams)
- Timestamps
- Recording status, including whether the session was live
- A conference identifier that resolves to the underlying meeting room
That final field is what separates this from an ordinary metadata leak. Metadata alone is a privacy problem. A metadata record that includes a working conference ID and a live recording flag is an access problem.
What was actually in the exposed set
| Category |
Detail |
| Meeting records |
181,874 |
| Unique users |
84,312 |
| Email domains |
35,003 |
| Government domains |
23 countries including the US, Japan, Brazil, Ukraine, Israel, Qatar, Malaysia, Indonesia, Mexico, Thailand |
| Universities |
Berkeley, University of Tokyo, De La Salle, Universidad Nacional de Colombia, dozens of .edu and .ac domains |
| Corporate |
HubSpot, Confluent, Mitsui-Soko (484 meetings across four offices), Mitsui Fudosan, Mekari, AnyMind Group |
| Live at any moment |
~1,000 actively recording |
| Secondary exposure |
Internal employee directory API reachable with no authentication at all |
Full transcripts were not in the exposed collection. That is the one piece of good news and it is thinner than it sounds, because the conference IDs made the live audio reachable directly.
The second failure: meeting bots are trusted by default
Getting a conference ID is only half an attack. The other half is being admitted to the room, and that is where a human-factors problem compounds the database one.
WHY HOSTS LET STRANGERS IN
Notetaker bots are now familiar participants. A host sees a generic recorder identity in the waiting room, assumes a colleague invited it, and clicks admit. tl;dv's own documentation acknowledges its bot may appear in the waiting room and may be flagged by Google Meet as a potential security risk, and that hosts can still admit it. The reported admission success rate was high enough that this is a reliable path, not a fluke.
So the chain runs: missing database rule reveals a live conference ID, familiar-looking bot requests entry, host waves it through, and the intruder now has audio, video, screen sharing and chat. The researcher documented joining meetings hosted by the Malaysian Ministry of Education and by students at a US university.
The disclosure timeline is the real story
Reported January 28, 2026. Follow-ups sent repeatedly. Still open in July, six months later. The CTO never responded. Dark Reading reported the exposure was still active at the time of its own publication.
tl;dv holds SOC 2. That is worth sitting with, because it is the exact scenario SOC 2 is assumed to prevent and does not.
SOC 2 Type I evaluates controls at a single point in time. It is a photograph. SOC 2 Type II evaluates the same controls over a sustained period, typically six to twelve months, confirming they work continuously. Neither audits how a vendor behaves when an outside researcher emails them, and that behaviour is the variable that turned a fixable January bug into a July disclosure.
The checklist to run on your own notetaker this week
This applies to any tool that records your calls, not just tl;dv. Three questions, in order of how much they tell you.
- Is access scoped per-tenant or per-account, and can the vendor demonstrate it? Ask directly whether tenant isolation is enforced at the database rule layer or only in application code. Application-layer scoping is what fails here, because anyone who can talk to the database directly bypasses it.
- Does the vendor have a published security contact and a documented response SLA? A security.txt file, a bug bounty programme, or a named contact. The absence of one is the single strongest predictor of the tl;dv outcome.
- Do meeting artifacts carry live join credentials? If your recorder stores conference IDs alongside metadata, a metadata leak is an access leak. Ask what happens to that field after the call ends.
Then the operational items:
- Audit which accounts in your org have the notetaker connected, including personal accounts on corporate calendars
- Turn off automatic bot admission in Google Meet and Teams host controls. Require manual verification of every bot
- Set a policy that any bot in the waiting room must be matched to a named internal requester before admission
- For interviews, board discussions, legal calls and performance reviews, disable third-party recording entirely
Decision framework
| If you are... |
Do this |
| In a regulated industry (health, finance, legal) |
Move to local-first transcription. Nothing leaves the device |
| Running sales calls and standups |
Cloud notetaker is fine, but require SOC 2 Type II and a published security contact |
| Conducting interviews or reviews |
Disable third-party bots for those calls specifically |
| A tl;dv customer right now |
Assume metadata was enumerable. Rotate any meeting rooms with persistent conference IDs |
| Building an AI notetaker |
Enforce isolation in Firestore security rules, not in your app layer. Publish a security contact today |
The broader pattern
This is the same access-boundary question that applies to browser agents, MCP servers and desktop AI tools. What does this thing have standing access to, is that access scoped per-account or per-tenant, and what happens when the boundary fails rather than if.
Meeting recorders are unusually exposed because the content is unusually sensitive. Job interviews, board discussions, client negotiations, internal strategy. The category where someone says the call is being recorded, everyone laughs, and then they discuss the thing they would not put in writing.
FAQ
Was my tl;dv transcript leaked?
Per the disclosure, the exposed Firestore collection held metadata rather than full transcripts. Metadata included creator email, provider, timestamps, recording status and conference ID. The conference IDs are the serious part, because they allowed joining live calls.
Has tl;dv fixed it?
As of the public disclosure and subsequent reporting, remediation was not confirmed. Check the vendor for a current advisory before making a decision either way.
Does SOC 2 certification mean a tool is secure?
No. SOC 2 Type I assesses controls at one moment. Type II assesses them over six to twelve months. Neither measures whether the vendor responds to a vulnerability report, which is the failure mode here. Treat SOC 2 Type II as a minimum bar, not a guarantee.
What is local-first meeting transcription?
Tools that run speech-to-text on your own machine and never upload recordings or transcripts to a vendor server. It removes the tenant-isolation risk entirely because there is no shared multi-tenant database. The trade-off is fewer collaboration features and more local compute.
How do I stop unknown bots joining my meetings?
In Google Meet and Microsoft Teams, disable automatic admission from the waiting room and require the host to admit each participant. Then enforce a rule that any recording bot must be matched to a named internal requester before it gets in. The technical control alone is not enough if hosts admit anything that looks familiar.
Should we drop AI notetakers entirely?
For most teams, no. The category is genuinely useful and the failure here was one vendor's missing database rule plus six months of not answering email. What should change is your evaluation process: ask about tenant isolation at the database layer, require a published security contact, and treat vendor silence on a disclosure as disqualifying.