On 4 August 2026, a security researcher published the details of a flaw in tl;dv, an AI meeting assistant with more than two million users, after waiting six months for a fix that never arrived. The numbers are stark: 181,874 meeting records, 84,312 unique users, 35,003 email domains, and government meetings from 23 countries. What makes it worth your attention is not the size of the exposure but the cause. No exploit chain, no zero-day, no compromised dependency. A single missing condition in a database rules file was the only thing between one authenticated user and every meeting on the platform.
If your product lets the browser talk directly to your database, and a growing number built in the last three years do, this is your architecture too.
TL;DR
- A missing tenant-boundary check in tl;dv’s Firestore security rules exposed 181,874 meeting records across 84,312 users and 35,003 domains, including live calls with joinable conference IDs.
- The pattern is architectural, not incidental: Firebase and Supabase move authorisation out of server code into a declarative rules file that most teams never test, review, or monitor.
- This failure class is already at industrial scale. 916 Firebase sites leaked 125 million records in 2024, 150+ popular apps were found exposed in 2025, and CVE-2025-48757 confirmed 170+ Lovable-generated apps shipped without row level security.
- Metadata was the real payload. Conference IDs are not identifiers, they are credentials, and they let an attacker join meetings in progress.
- Treat AI notetakers as privileged third-party meeting participants. 35,003 domains means the tool sat inside thousands of organisations that never procured it.
- Six months of vendor silence turned a fixable misconfiguration into a public incident. Disclosure responsiveness belongs in vendor assessment, not just your penetration test report.
What actually broke
tl;dv authenticates users with a JWT, then exchanges it for a Firebase token granting access to its Firestore project. That part is standard. The problem was what came next: the meetings collection carried no rule tying a document to the requester’s organisation, so any user with a valid token could query the entire collection across every tenant on the platform.
The exposed fields were metadata: creator email addresses, timestamps, recording status, and conference IDs. It is tempting to file that under “low severity, no content disclosed”. That misses the point. Roughly a thousand meetings were recording at any moment, and the conference IDs for those live Google Meet and Teams rooms sat in the same queryable collection. A conference ID is not a reference to a resource, it is the means of entering it. Combine it with creator domains and you have a targeting mechanism: filter for a competitor, a government department, or a law firm, and walk into the room while it runs. A further thousand public meetings exposed full transcripts, video, and 715 invitee email addresses.
The disclosure timeline is its own lesson. The researcher contacted tl;dv’s chief executive and CTO on 28 January 2026 and was promised a CTO response within 24 hours under the company’s own security policy. It never came, across follow-ups from February through July, and the flaw was still unfixed at publication.
The architecture that keeps producing this bug
Backend-as-a-service platforms made a genuinely useful trade. By exposing the database directly to the client, Firebase and Supabase let a small team ship a real product without operating an API tier. When your React component calls supabase.from('meetings').select('*'), that request goes from the browser to the database. Nothing sits in between to filter the result.
What that removes is not just boilerplate. It removes the place where authorisation logic normally lives. In a conventional stack, a query for another tenant’s data passes through a controller, a service layer, and an ORM scope, each a plausible location for a check and each covered by tests written in the same language as the rest of your code. In the client-direct model, all of that collapses into a rules file: Firestore Security Rules, or PostgreSQL row level security policies.
Those rules files fail in a specific and predictable way, and it is worth being precise about why:
- They are not treated as application code. A rules file rarely gets the review attention a controller change would, and most teams have no test asserting that tenant A cannot read tenant B’s rows.
- Coverage is per-collection, not global. Protection is additive, so every new collection or table starts unprotected and security debt accrues silently as the schema grows.
- Development defaults leak into production. Firebase test mode and Supabase tables created with RLS disabled both work perfectly in development. Nothing fails, nothing warns.
- Failures are silent and total. A missing check in server code often surfaces as a bug someone notices. A missing rules condition produces correct-looking behaviour for legitimate users and full access for anyone querying deliberately.
The evidence that this is systemic rather than anecdotal is substantial. In 2024, researchers found 916 sites using Firebase leaking around 125 million user records, including 19 million plaintext passwords. In 2025, more than 150 popular applications, several with over 100 million downloads, were found exposing data through Firebase misconfigurations ranging from private messages to AWS tokens. CVE-2025-48757 established that Lovable, a vibe-coding platform with roughly eight million users, had been generating Supabase backends without row level security enabled, with 170+ production applications confirmed exposed.
None of these are Firebase or Supabase defects. They are the consequence of relocating your security boundary into an artefact your engineering process does not treat as load-bearing.
If you build on a client-direct database
The remediation is not “move off Firebase”. It is to give the rules file the same rigour as the rest of your codebase.
- Write adversarial tenant tests. The Firestore Emulator Suite and a local Supabase instance both support this: create two tenants, authenticate as one, and assert every read and write against the other’s data is denied. Run it in CI. This single test class would have caught the tl;dv flaw in January.
- Make deny the default and prove the exception. Audit every collection and table for an explicit policy. Treat any unprotected one as a production incident, not a backlog item.
- Keep capability data off the client path. Conference IDs, signed URLs, join tokens, and invite codes are credentials. They belong behind a server-side endpoint that authorises the specific request, not in a collection the browser can query.
- Separate metadata sensitivity from content sensitivity. Ask what an attacker could do with the field list alone. Aggregated metadata across tenants is a targeting capability in its own right.
- Instrument query patterns. One account enumerating an entire collection is a detectable signal, yet most teams using BaaS have no alerting on read volume per principal.
- Have a disclosure route a human answers. A security.txt file, a monitored inbox, a named owner. The gap between tl;dv’s stated 24-hour policy and six months of silence is what turned a config bug into a headline.
If you buy AI meeting tools, and you almost certainly do
That figure of 35,003 email domains is the part that should reach your leadership team. AI notetakers spread through calendar integrations and individual sign-ups, so they arrive inside organisations without ever passing a procurement review. Meanwhile the tool holds the highest-value unstructured data in the business: strategy discussions, salary conversations, client commercials, incident calls.
Treat a recording bot as a privileged third-party participant rather than a transcription feature. Practically: audit which staff have connected assistants to company calendars and whether auto-record is on by default; set a no-bot rule for meetings covering personnel, legal, financial, and client-confidential matters; use waiting rooms and restrict guest admission so an unrecognised bot cannot silently join; and treat an unexpected bot as an incident to investigate rather than a glitch to dismiss.
On the vendor side, the questions are unglamorous and effective. How is tenant isolation enforced, and is it tested? Where is data stored, and under what retention period? Is there a published security contact with a response commitment, and can they evidence meeting it? A vendor who cannot answer the third question will not answer the first under pressure either.
The broader pattern
Every abstraction that removes a tier of infrastructure relocates the responsibility that tier was carrying. Serverless moved capacity planning into concurrency limits. Managed CI moved build integrity into workflow permissions. Client-direct databases moved authorisation into a rules file. That is usually a good trade, but only if the team recognises where the responsibility landed and resources it accordingly.
The teams getting this right are not avoiding Firebase and Supabase. They can point to a CI job proving tenant isolation holds, and they review that rules file with more care than the component querying it.
At REPTILEHAUS we build on these platforms deliberately, because for the right product they are the fastest sensible route to production. We also treat security rules as application code, with adversarial multi-tenant tests in the pipeline and capability data behind server-side authorisation. If you cannot demonstrate that your tenant boundaries hold, or you want a second opinion on an AI tool that has quietly become critical to your operations, get in touch. An isolation audit is short work with an unusually high return.
📷 Photo by Chris Montgomery on Unsplash
