181,874 meetings laid bare: dissecting the hole in tl;dv and a Firestore Rules checklist

WEB technologies and their applications
, , , ,
1

There is a class of vulnerabilities with neither a CVE, nor an exploit, nor a patch. Simply five lines weren’t written somewhere in the project. The tl;dv meeting transcription service story is a textbook example, and a good reason to take a look at your own Firebase project.

Below is a date-based chronology, a breakdown of the mechanics, and what to check in your own setup.

January 28: the report goes to the company

Researcher going by the nickname BobDaHacker writes to tl;dv co-founder Rafael Alshtadt on LinkedIn and, separately, to the CTO. The gist of the report: the collection meetings in Firestore is exposed to any authenticated service user, with no tenant separation by client.

January 29–30 Alshtadt responds that the CTO will contact immediately. The CTO does not get in touch.

What exactly was disclosed

According to the researcher’s publication, the following were accessible:

  • 181,874 meeting records;
  • 84,312 unique users;
  • 35,003 email domains, including government ones from 23 countries;
  • about 1,000 meetings with status recording — i.e., currently ongoing;
  • more than 1,000 publicly accessible records, where 715 invited addresses from 228 domains were exposed.

In the record fields lay the creator’s email, the conference platform, timestamps, recording status, and — crucially — the conference ID. In other words, a string that lets you simply enter the Google Meet or Teams room. The researcher verified this: joined two unrelated calls, including the Malaysian Ministry of Education meeting with 157+ participants.

Error:

Separately, it’s worth documenting the check method itself. Connecting to someone else’s ongoing call is no longer “reading open data,” but unauthorized access, regardless of how hole-filled the system was. Ethical research stops at proving the possibility, not at implementing it. Do not repeat this on anyone else’s infrastructure, including your SaaS subscription.

How it worked technically

The mechanic is surprisingly boring, and that’s the point.

The tl;dv client logs in, obtains a JWT, exchanges it for a Firebase token via gw.tldv.io/v1/users/firebase/token — and then goes straight to Firestore, in the lmi-store project. No intermediate API that would check “is this your meeting” exists in this chain.

How the client goes to Firestore directly
How the client goes to Firestore directly1280×720 57.8 KB

This is where the Firebase architecture’s main pitfall lies. In the classic three-tier setup between client and database, your server sits in the middle, and a missing tenant_id check must be done in a specific handler. In Firebase there are no servers in between: Security Rules are the backend for authorization. A missed rule on any collection means the entire collection is open.

Important:

request.auth != null — this checks that a person is signed in, not that the person is entitled to this particular record. In a product where registration is open to everyone, the first condition doesn’t mean anything.

February 14 — July 22: silence

In the chronology, further events are almost none, and this is the saddest part.

Date What happened
January 28, 2026 first report, LinkedIn + CTO letter
January 29–30 promise that the CTO will respond immediately
February 14–19 follow-up reminders, no answer
March 6 researcher re-checks — the hole is still there
July 22 after almost half a year, the hole is still there
August 4 material published in Dark Reading, no reaction from the company

The tl;dv security page states a response time to vulnerability reports of 24 hours. A public company statement on the substance could not be found as of this text’s preparation.

Warning:

A second finding by the same researcher: an internal app with World Cup predictions on the worldcup.tldv.io subdomain was exposing employee data through the /api/entities/* endpoint without any authorization at all. The exact number of exposed records in the summaries varies, so I won’t quote a figure here — the pattern is what matters: an internal toy on the same domain as production lives by a “who will find it” rule.

What to check in your project today

If you have anything on Firebase — here is a minimal check.

1. Find collections with no rules. The default “test mode” rule looks like this and lives for exactly 30 days, after which it’s often replaced with something like “temporary”:

allow read, write: if request.time < timestamp.date(2026, 9, 1);

Look in firestore.rules for any if request.auth != null without additional conditions — this is the vulnerable form.

2. Bind access to the owner, not to the fact of login.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    match /meetings/{meetingId} {
      allow get: if request.auth != null
                 && resource.data.ownerId == request.auth.uid;

      allow list: if request.auth != null
                  && request.query.limit <= 100;

      allow create: if request.auth != null
                    && request.resource.data.ownerId == request.auth.uid;

      allow update, delete: if request.auth != null
                            && resource.data.ownerId == request.auth.uid;
    }
  }
}

3. Remember that rules are not filters. Firebase documentation states this directly: “You cannot write a query for all documents in a collection and expect Cloud Firestore to return only the documents the client has access to.” If the rule requires matching ownerId, then the client request must also include the corresponding where — otherwise it will just fail. Many are surprised by this, and the moment a temptation arises to “loosen the rule now and tighten it later” appears. They don’t return.

Success:

A working regime:

  • rules live in the repository and are deployed via firebase deploy --only firestore:rules, not edited in the console;
  • every collection has a test in firebase emulators:start — testing not only “my view sees mine,” but also “others do not see others”;
  • any subdomain of production is considered production, including internal toys;
  • the vulnerability report form contains an address that is read not only by marketing.
Security:

And a consumer takeaway that concerns everyone: an AI notetaker in your calendar is an external company that stores audio, transcripts, and a list of participants for all your meetings. The threat model here is not about breaking encryption, but about one collection missing a line. If personal data, trade secrets, or an NDA pass through a meeting, the decision to connect such a service is a decision to process data by a third party, with all contract and jurisdiction questions that follow.

Question:

Who reviewed their Firestore Rules later than “when they wrote the first version of the app”? And a separate question for those who sent vulnerability reports to SaaS: how many times did you actually get a reply?

Sources