tl;dv’s Firestore Nightmare: 181,874 Meetings, Zero Tenant Isolation, and the CTO Who Ghosted
The meetings collection had no tenant isolation. No ownership checks. No security rules that actually restricted who could read what. Any authenticated user, meaning anyone with a free account, could query every meeting record across every organization on the platform. All 181,874 of them. From 84,312 unique users across 35,003 email domains.
The vulnerability, discovered and documented by security researcher BobDaHacker in late January 2026, exposed far more than meeting metadata. It exposed the architectural gap between authentication and authorization, the fragility of trust in SaaS vendors, and a disclosure process that made the original breach look competent.
The One-Collection Failure That Broke Everything
Here’s the technical breakdown of what happened. When you authenticate to tl;dv, the platform exchanges your JWT for a Firebase token via gw.tldv.io/v1/users/firebase/token. That token grants you access to their Firestore database at projects/lmi-store/databases/(default).
Every meeting document contains the creator’s email address, the conference ID (a joinable Google Meet or Teams room link), provider details, recording status, and timestamps. For meetings actively recording, that conference ID is a live, active call.
The researcher found roughly 1,000 meetings with status: recording at any given moment. A thousand live conference calls, each with an exposed joinable ID. An attacker with a simple bot could automate joining all of them simultaneously.
What makes this particularly damning is that the other collections, users, chats, transcripts, clips, recordings, videos, notes, teams, organizations, all had proper security rules. They returned 403 errors for unauthorized access. Someone configured security for everything except the most operationally sensitive collection in the system.
This is a textbook broken object-level authorization problem. Firestore security rules in production need ownership or tenant conditions. What tl;dv had was a rule that probably checked request.auth != null, verifying only that a user was logged in, not that they were the right user.
The Dark Side of “Is It Recording?”
The exposure wasn’t just historical data. The real danger was real-time surveillance capability. The researcher demonstrated this by actually joining two live meetings.
The first was a call hosted by the Malaysian Ministry of Education, where a presenter was addressing 157 participants. The tl;dv bot was already in the room. The researcher joined uninvited, admitted by a system designed for convenience, not security.
The second was a university startup pitch session where students were screen-sharing their prototype and discussing .edu email validation. The irony was thick enough to spread on toast: they were building auth while their meeting platform had none.
The researcher’s estimate, reported by Dark Reading, suggests that impersonating an expected AI notetaker and requesting admission worked in 80% of tested cases. Meeting bots have become so ubiquitous that hosts see a generic notetaker identity and approve entry without verifying which account is behind it.
The exposure reached 23 countries’ government domains, universities including Berkeley and the University of Tokyo, and companies like HubSpot, Confluent, and Mitsui Fudosan. Wake up on a Wednesday at 2pm UTC, and you’d catch the busiest window, 7,804 meetings happening simultaneously.
“Public by Default” Is a UX Problem Dressed as a Security Issue
tl;dv’s official response, published by CTO Allan Bettarel, walks a careful line. The company claims the vulnerability was two distinct vectors, with the first fixed and validated months ago, and the second being a “newly discovered, alternative exploitation path.”
That’s a lawyer-approved way of saying the same Firestore collection had two holes.
But the response contains a genuinely interesting admission: public sharing on tl;dv is opt-in and off by default. Users must deliberately enable visibility for content to be accessible outside their team. The company frames this as a defense, only users who intentionally opted into public sharing had their transcripts exposed.
The problem? “Public” means different things to different users. This is a UX problem the industry is collectively circling. Anthropic dealt with exposed public artifacts across Claude’s MCP ecosystem. Lovable worked through cases where user-configured public settings produced broader visibility than expected. Zoom learned this lesson in 2020 with 15,000 exposed cloud recordings.
When you ask users to opt into “public”, are you asking them to consent to their meeting being discoverable, or just linkable? The distinction matters. In tl;dv’s case, over 1,000 meetings in a sample of 27,334 were public, exposing 715 invitee emails across 228 domains.
The Compliance Theater Problem
Tl;dv’s security page is a trophy case. SOC 2 Type II. GDPR compliant. EU AI Act compliant. AES-256 encryption. Hosted in the EU. Six compliance badges lined up like a self-esteem poster.
None of it prevented a free-tier user from enumerating every meeting on the platform.
This is the compliance theater problem: certifications attest to an organization’s systems at a point in time, but they cannot validate every collection, API route, or new feature. A single rule exception bypasses an otherwise mature control set. Your SOC 2 report doesn’t check whether your newest Firestore collection has proper tenant isolation. Your GDPR compliance doesn’t test whether your database returns fields you didn’t intend to expose.
Firestore security rules are part of the application’s security boundary, not an optional back-end refinement. When you let web and mobile clients communicate directly with stored data, a core part of Firestore’s architecture, the rules are the firewall. Google’s documentation is explicit: client-accessible deployments depend on those rules to block malicious requests.
A rule that checks only whether request.auth exists is suitable for development. Shipping it to production means granting every signed-in user access to every document covered by that rule. Production rules need an ownership or tenant condition, such as matching the authenticated user’s organization claim to an organization ID stored on the document.
The Vibecoded Side Hustle That Leaked Everything
Just when you thought the story couldn’t get more entertaining, there’s the pasta infrastructure. Tl;dv names their microservices after Italian dishes: cappellini, carbonara, fusilli, penne, puttanesca-v0, ravioli. An entire restaurant worth of Express servers.
On one of those subdomains lived worldcup.tldv.io, a FIFA World Cup 2026 prediction game, “vibe-coded by non-engineering teammates” according to the CTO’s response. The Player entity API had zero authentication. A single GET /api/entities/Player request returned all 43 player records, including 19 @tldv.io employees with full names and corporate emails. The CTO’s own Gmail was in the API response. Player #5 on the leaderboard was “Super Duper CEO.”
The irony is al dente. A company that records millions of people’s meetings vibecoded an internal fun app that leaked their own employee directory. Same control class, same failure mode: endpoints exposed without access checks matching the sensitivity of the data behind them.
This pattern connects to a larger conversation about shared databases and architectural trade-offs in distributed systems. When teams ship internal tools with production-adjacent infrastructure, they’re creating attack surface that nobody’s monitoring. The world cup app was separate from customer data, but it was on the same subdomain infrastructure, running the same vibecoded energy.
Six Months of Silence
The most damning part of this story isn’t the vulnerability. Broken object-level authorization happens. The disclosure timeline is where this becomes a governance story:
| Date | Event |
|---|---|
| Late January 2026 | Firestore tenant isolation bypass discovered |
| January 28, 2026 | Researcher contacts Raphael Allstadt via LinkedIn, emails CTO |
| January 30, 2026 | “I am sure the team is reviewing it very very soon ❤️” |
| February 15, 2026 | Still not fixed. “He’ll come back ☺️” |
| February 19, 2026 | “We’re on it. It needs some time…” |
| March 6, 2026 | Still not fixed. Seen. No reply. |
| July 22, 2026 | “still not fixed…” No reply. |
Six months. The CTO never responded. The security page promised 24-hour response times. Dark Reading’s attempts to reach the company received no reply before publication.
In the CTO’s response, there’s a personal acknowledgment: “I recognize that I should have kept the researcher updated after his initial outreach earlier this year, and I take full responsibility for that communication gap.”
That’s a start. But here’s the uncomfortable question: if tl;dv’s independent penetration testing vendor did identify the initial vulnerability “earlier this year”, why was the researcher left in the dark for six months? Why did Dark Reading have to publish before anyone acknowledged the issue publicly?
Lessons for Anyone Building Multi-Tenant Systems
The tl;dv breach should be a case study in every software architecture class. Here’s what any team building a multi-tenant SaaS, especially one handling sensitive data, should internalize.
1. Treat Firestore rules as production code.
They deserve code review, version control, and adversarial testing. Google provides a Firestore Emulator Suite and rules-testing library that can simulate authenticated and unauthenticated users, assert successful and failed requests, trace rule evaluations, and generate coverage reports. Use them. Create two or more test tenants, then prove that users from one tenant cannot list, retrieve, update, or subscribe to another tenant’s records. The cost of this testing is trivial compared to the cost of a breach.
2. Separate sensitive join data from readable metadata.
Firestore reads operate at the document level. Security rules cannot expose one field in a document and conceal another from the same reader. If a conference identifier, creator email, recording state, and display data occupy one document, a user allowed to read that document receives everything. Sensitive join material should live behind a server-side authorization layer that issues short-lived access only to approved participants.
3. Understand that authentication is not authorization.
The tl;dv failure is a textbook example. Authentication answered whether the requester was a valid user. The missing control was whether that user belonged to the same organization as the requested meeting document. Any system that trusts a JWT without checking tenant context is a system that’s already failed.
4. Audit your “forgot” collections.
The pattern here is striking: every other collection in tl;dv’s Firestore had proper rules. Only meetings was exposed. This suggests an oversight, not a deliberate design decision. If you’re building on Firebase, periodically audit which collections have rules worse than the others. Run automated scans that flag collections where the rules are weaker than the data sensitivity demands.
The multi-tenant data isolation and access control failures in SaaS platforms aren’t limited to NoSQL databases. PostgreSQL deployments face the same challenges with row-level security and connection pooling. The lessons transfer: default-deny access, verify ownership at the application layer, and treat database security rules as part of the threat model.
The Deeper Structural Problem
What’s genuinely unsettling about this breach is how unremarkable it is. A platform that records your most sensitive conversations, job interviews, performance reviews, internal strategy sessions, had its tenant boundary held together by the equivalent of a paperclip. The security page promised SOC 2, GDPR, AES-256, EU hosting, 24-hour response times, and six badges confirming the company was serious about security.
The reality was a single missing rule in a production database.
The researchers behind incidents like this keep finding the same pattern: certification ≠ control validation, compliance ≠ security, and “vibe-coded” internal tools leak employee data in the same way production systems leak customer data.
For organizations using AI meeting notetakers, the lesson is darker. You don’t control the security posture of the vendors you invite into your most sensitive conversations. An AI notetaker is a privileged third-party participant with access to live audio, video, shared screens, participant identities, and post-meeting content. Treat it that way. For sensitive calls, admit meeting bots only after confirming who invited them and which vendor account they represent. Consider whether government, legal, HR, and executive meetings need a no-bot policy.
Tl;dv’s CTO announced the company is removing Firebase from their stack entirely. That’s a reasonable move, the common denominator across both incidents was Firebase. But moving to a different database won’t fix the underlying issues: broken default security, inadequate disclosure processes, and a culture where security review is something that happens after the researcher’s third follow-up.
The Firestore database had better uptime than their inbox. And that, more than any missing security rule, is the real indictment.
