tl;dv exposed 181,874 meetings via one missing rule

Your AI notetaker sits in every call you take: sales pricing, legal, hiring, the conversation about the customer you are about to lose. It is not a widget. It is a database of your company's unguarded speech, hosted by a vendor you evaluated on transcript quality. A disclosure published this month about tl;dv shows what happens when that database is missing one line of access control.

What actually happened

Security researcher BobDaHacker published findings that tl;dv's Cloud Firestore meetings collection had no tenant isolation. Any authenticated tl;dv user could obtain a Firebase auth token and query every meeting record on the platform — 181,874 meetings, 84,312 users, 35,003 email domains. Other collections (users, transcripts, recordings) correctly returned 403. That one did not.

Each record handed over the creator's email address, the conferencing provider, timestamps, recording status, and a conference ID — a joinable Google Meet or Teams room. Roughly a thousand meetings were actively recording at any moment. The researcher reported that impersonating an expected AI notetaker and requesting admission to a live call worked in about 80% of attempts tested. Affected domains included government bodies across 23 countries and universities including Berkeley and the University of Tokyo.

The timeline is the part that should change how you buy software. First contact was January 28, 2026, by LinkedIn and email to the CTO. Follow-ups ran through July. Dark Reading reported the issue was still live at publication on August 4. The fix is a few lines of Firestore security rules scoping reads to the authenticated user's organization — the exact scenario Google's own Firestore documentation warns about. We have seen no public response from tl;dv.

Why vendor tenant isolation matters for your business

Two separate failures here, and only one is technical.

The technical one is boring and extremely common: a multi-tenant app where the client talks straight to the database and the only thing between customers is a security rule someone forgot to write. If you build on Firebase, Supabase, or anything else with client-side data access, row-level security is not a hardening step you do later — it is the tenancy model. Write the deny-by-default rule first, then test it from a second account. Not from the admin console.

The non-technical one is worse. Six months of unanswered disclosure is not a bug, it is a statement about the company. And it is knowable before you sign. Cheap checks that take an afternoon:

• Is there a security contact that answers? security@, a /security.txt, a disclosure policy. Email it during evaluation and time the reply.
• What does the tool actually retain, and can you delete it? A notetaker that keeps transcripts indefinitely is a subpoena target and a breach multiplier.
• Who can join your calls? Waiting rooms on, admit-by-name off. "It looked like our notetaker" is now a documented entry technique.
• Does anyone own the vendor list? Most small companies cannot name every SaaS tool with access to their calendar. That inventory is a one-hour job and it is the prerequisite for every other control.

You cannot audit a vendor's Firestore rules. You can absolutely notice that nobody answered the researcher.

Sources: BobDaHacker, Dark Reading.