Why a Missing Security Rule Exposed 181,000 Meetings: What You Need to Know about tl;dv's Firestone Incident

August 2026 — Security researcher BobDaHacker published a comprehensive vulnerability disclosure revealing that tl;dv, an AI meeting recording platform with over 2 million users, left 181,874 meeting records completely exposed due to a single missing Firestore security rule. Read the full disclosure. What follows is our analysis of what went wrong, what it means for organizations using meeting recorders, and what you should ask your vendors.

Any free-tier user could query every meeting on the platform—including government calls, university sessions, and corporate strategy meetings. This wasn't a traditional data breach. No passwords were cracked, no databases were stolen. The researcher simply authenticated as a regular user and discovered that the meetings collection had no tenant isolation. The front door was left unlocked, and nobody checked.

What Happened

tl;dv uses Firebase/Firestore to store meeting metadata—things like who recorded the call, which conference ID they used, whether it's currently recording, and participant email addresses.

When the security researcher authenticated as a regular user, they discovered the meetings collection had no tenant isolation. This means they could see every single meeting from every single account, not just their own.

Here's the critical part: the researcher didn't need admin access or a leaked API key. Just a normal user account. They queried the database and got back:

• 181,874 meeting records
• Conference IDs for active calls (roughly 1,000 live meetings at any moment)
• Creator email addresses and domains
• Recording status in real time

For live meetings marked status: recording, that conference ID pointed to an active Google Meet, Zoom, or Teams call. The researcher proved the concept by joining two uninvited—one with the Malaysian Ministry of Education (157 participants) and another with university students building a startup.

Who Was Exposed

The data came from 84,312 users across 35,003 email domains:

• 23 governments: Brazil, Colombia, Ukraine, the Philippines, Malaysia, Qatar, and others. Brazilian conservation meetings with NGOs. Ukraine's Ministry of Digital Transformation. Meetings from El Salvador, Haiti, Honduras.
• Major universities: Berkeley, University of Tokyo, Universidad Nacional de Colombia, De La Salle.
• Fortune 500 companies: HubSpot, Confluent, and dozens of others.
• Peak activity: 43,209 meetings in July 2025 alone.

Additionally, over 1,000 meetings were configured as publicly viewable, exposing transcripts and participant emails across 228 domains.

Why This Matters

Meeting metadata doesn't sound like much until you think about what it reveals:

• Deanonymization: Knowing that someone at company X joined a call with someone at company Y at 3 PM on a Thursday tells a story (acquisition? partnership? recruiting?).
• Call interception: Live conference IDs mean an attacker could join uninvited, not just observe metadata.
• Participant harvesting: Email lists from government and corporate meetings become targeting lists.
• Competitive intelligence: Which departments are talking to which vendors? When? For how long?
• Compliance violations: Government and regulated industry customers likely violated their own data handling policies by being recorded on an insecure platform.

The Disclosure Problem

On January 28, 2026, the researcher reported the vulnerability to tl;dv's leadership. The CTO promised a quick fix. Nothing happened. Follow-ups in late January, mid-February, early March: radio silence. By July—six months later—the vulnerability was still unfixed. The CTO never responded.

tl;dv's security page advertises SOC 2 compliance, GDPR compliance, EU AI Act compliance, and AES-256 encryption. At the bottom, a line: "Our security team will respond within 24 hours."

They didn't.

What Went Wrong at the Architecture Level

Here's what makes this a teaching moment: Firestore security rules are specifically designed to prevent this. They work. tl;dv used them correctly for almost every other collection—users, chats, transcripts, clips, recordings, videos, notes, teams, organizations all return 403 (access denied) when queried by unauthorized users.

They just forgot to apply the same rule to meetings.

This is a gap between intent and execution. Compliance frameworks check boxes. Engineering discipline prevents these gaps. The two aren't the same.

What to Look For If You Use a Meeting Recorder

If your organization records calls on a third-party platform here are questions to ask:

1. Tenant isolation: Can one customer's user account see another customer's data? If so, walk away.
2. Metadata access: Is meeting metadata (who, when, duration, participants) restricted to the account owner? Or is it queryable by any authenticated user?
3. Live call exposure: Can you query active meetings in real-time? If yes, that's a security problem waiting to be exploited.
4. Default privacy settings: Are meetings private by default, or public by default?
5. Security incident response: If you report a vulnerability, who's the contact and what's the SLA? Radio silence is disqualifying.
6. Data retention: What happens to raw recordings after the AI processing is done? Do they stick around indefinitely, or are they deleted?

Ask for details. Not compliance badges—actual architecture documentation. SOC 2 and GDPR attestations don't tell you whether your meeting metadata is isolated by customer.

Lessons for Vendors

This vulnerability happened because security rules were configured, not audited. The team probably created a default setup, tested it, and then moved on. Nobody came back to verify that all collections were properly locked down.

For any vendor storing sensitive data:

• Audit your defaults. Never assume a security control is working. Test it.
• Respond to security researchers. Especially when the report involves user data. Ghosting a researcher costs you more than just reputation—it costs trust at scale.
• Separate compliance from security. You can be SOC 2 compliant and still have this problem. Compliance is a floor, not a ceiling.

What Happens Now

As of August 2026, the Firestore database is still exposed. tl;dv hasn't publicly acknowledged the vulnerability or published a fix. Users on platforms like Reddit and Twitter have begun asking whether they should migrate to competitors.

This is how platform trust erodes—not from a single breach, but from how a company responds to one.

If you use tl;dv and have concerns about your data, it's worth a conversation with your security team about tl;dv alternatives and what the company's remediation timeline looks like. If you don't use tl;dv but use any meeting recording tool, this is a useful case study for your procurement and security review process.

Read the full vulnerability disclosure: https://bobdahacker.com/blog/tldv-hack