{"slug": "one-missing-firestore-rule-exposed-181874-meetings", "title": "One Missing Firestore Rule Exposed 181,874 Meetings", "summary": "A security researcher known as BobDaHacker found that tl;dv, an AI meeting notetaker, left its Firestore 'meetings' collection readable by any authenticated user, exposing 181,874 meeting records from 84,312 users across 35,003 email domains, including government addresses from 23 countries and companies like HubSpot and Confluent. The researcher joined two live meetings to prove the vulnerability, including a Malaysian Ministry of Education meeting with over 150 participants. The bug was reported on January 28, 2026, and the public writeup landed August 4, after several ignored follow-ups.", "body_md": "[Security](https://sourcefeed.dev/c/security)Article\n\n# One Missing Firestore Rule Exposed 181,874 Meetings\n\nThe tl;dv leak is a Firebase story first, and a warning about how much access AI notetakers concentrate.\n\n[Ji-ho Choi](https://sourcefeed.dev/u/jiho_choi)\n\nA security researcher who goes by BobDaHacker found that [tl;dv](https://tldv.io/), an AI meeting notetaker that plugs into Zoom, Google Meet, and Microsoft Teams, left its `meetings`\n\ncollection in Firestore readable by any authenticated user. Not their own meetings — everyone's. The tally: 181,874 meeting records spanning 84,312 users and 35,003 email domains, including government addresses from 23 countries, universities like Berkeley and the University of Tokyo, and companies including HubSpot and Confluent. The records carried creator emails, timestamps, recording status, and — the part that matters — live conference IDs. At any given moment, roughly a thousand meetings sat in the database with `status: recording`\n\nand a joinable room ID attached. The researcher joined two calls to prove it, including a Malaysian Ministry of Education meeting with over 150 participants.\n\nThe bug was reported on January 28, 2026. The public writeup landed August 4, six months and several ignored follow-ups later.\n\n## The oldest bug in the serverless playbook\n\nStrip away the AI framing and this is the most familiar failure in the Firebase era. [Cloud Firestore](https://firebase.google.com/docs/firestore) lets clients query the database directly; your entire authorization layer is a set of declarative security rules. Write them correctly and you get fine-grained multi-tenancy for free. Miss one collection and any user with a free-tier JWT can enumerate your whole tenant population with a single query.\n\nThat's precisely what happened here, and the detail that makes it sting is that tl;dv got it right almost everywhere else. Users, transcripts, and recordings collections were locked down. One collection wasn't. There's no partial credit in this model: security rules are deny-by-default per rule but your product is only as isolated as your least-audited collection, and nothing in the Firebase console screams at you when a collection's rules quietly allow cross-tenant list queries.\n\nThe rap sheet for this bug class is long. Misconfigured Firebase access rules were at the heart of the 2024 Arc browser vulnerability (CVE-2024-45489), where Firestore trust assumptions let an attacker push code into other users' browsers, and the Chattr AI hiring-bot exposure the same year — also found by BobDaHacker. Firebase makes the insecure path the ergonomic one: the database works before the rules exist, demos ship, and the rules become someone's someday task. Supabase's row-level security and PocketBase inherit the same shape, if not the same defaults. When the client talks straight to the database, rules aren't a hardening step — they're the whole backend.\n\n## \"Just metadata\" is doing a lot of work\n\ntl;dv's official response disputes the six-months-unfixed framing — the company says there were two distinct vectors, the first closed months ago and the second within 24 hours of discovery — and stresses that \"no passwords, recordings, transcripts, AI-generated notes or account and billing data were accessible.\" The vulnerable data, it says, was \"strictly limited to metadata.\" Commenters on Hacker News and Lobsters noted the post was revised several times as the story evolved, which doesn't inspire confidence in any single version of the account.\n\nThe metadata framing deserves to be retired. A conference ID for a live meeting is a bearer credential: possess it, join the call. The only remaining control is a human clicking \"admit\" — and AI notetakers have spent three years training that human to wave through unfamiliar participants, because every meeting now has somebody's bot in the lobby. An attacker with a fresh list of a thousand in-progress meetings, complete with organizer domains, gets to pick targets by `.gov`\n\nsuffix and show up as \"Meeting Notes AI.\" That's not a metadata leak. That's an eavesdropping capability with a target-selection interface.\n\nThere's one more tell in the vendor response: tl;dv says it has removed Firebase from its stack entirely. Ripping out the database rather than demonstrating a working rules-testing process reads less like remediation and more like an admission that nobody trusted themselves to configure it.\n\n## What to actually do about it\n\nIf you ship on a client-direct database, treat security rules like code, because they are. The Firebase emulator plus [ @firebase/rules-unit-testing](https://firebase.google.com/docs/rules/unit-tests) lets you write assertions like \"user A cannot list documents in\n\n`meetings`\n\nwhere `tenantId != A.tenantId`\n\n\" and run them in CI. The test that would have caught this bug is about ten lines. Write one list-query denial test per collection, and make adding a collection without one fail review. The same discipline applies to Supabase: RLS policies belong in migrations with tests, not in the dashboard.If you're on the buying side, this incident is an argument for treating meeting notetakers as tier-one vendors, not productivity toys someone expensed. They hold your calendar, your call access, and your most candid conversations. tl;dv advertised SOC 2 compliance and a 24-hour security-response commitment throughout the six months this went unpatched — a decent reminder that a badge audits process, not queries. Better questions for a vendor: do you test tenant isolation in CI, do you have a published vulnerability-disclosure route that isn't the CEO's LinkedIn DMs, and what exactly does your bot retain. It's also worth knowing which notetakers attend your meetings at all; most orgs couldn't produce that list today, and every bot in the room is another company's database holding your conference IDs.\n\n## The AI part isn't the bug — it's the blast radius\n\nNothing about this vulnerability required AI to exist. But the product category did the concentrating: notetakers aggregate standing access to live meetings across tens of thousands of organizations into one startup's Firestore instance, then compete on shipping speed. The brief's obligatory lesson — audit your access rules — is true and insufficient. The structural lesson is that we've normalized routing the most sensitive real-time data in a company through young vendors whose entire authorization layer can be one forgotten rule, and whose incentive after disclosure is to argue about the word \"metadata.\" The bug was ordinary. The exposure wasn't, and as more of these tools pile up in the lobby of every call, that gap is the thing worth worrying about.\n\n## Sources & further reading\n\n-\n[tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open](https://bobdahacker.com/blog/tldv-hack)— bobdahacker.com -\n[AI Notetaker Lets Hackers Spy on Government, Corporate Video Calls](https://www.darkreading.com/application-security/ai-notetaker-spy-government-corporate-video-calls)— darkreading.com -\n[Our thoughts on the darkreading.com article](https://tldv.io/blog/our-thoughts-on-the-darkreading-com-article/)— tldv.io -\n[Over 181,000 AI meeting recordings left wide open in note taking app](https://news.ycombinator.com/item?id=49242739)— news.ycombinator.com\n\n[Ji-ho Choi](https://sourcefeed.dev/u/jiho_choi)· Security & Cloud Editor\n\nJi-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept.\n\n## Discussion 0\n\nNo comments yet\n\nBe the first to weigh in.", "url": "https://wpnews.pro/news/one-missing-firestore-rule-exposed-181874-meetings", "canonical_source": "https://sourcefeed.dev/a/one-missing-firestore-rule-exposed-181874-meetings", "published_at": "2026-08-10 15:08:57+00:00", "updated_at": "2026-08-10 15:14:16.003378+00:00", "lang": "en", "topics": ["ai-products", "ai-safety", "ai-policy"], "entities": ["tl;dv", "BobDaHacker", "Firestore", "Zoom", "Google Meet", "Microsoft Teams", "HubSpot", "Confluent"], "alternates": {"html": "https://wpnews.pro/news/one-missing-firestore-rule-exposed-181874-meetings", "markdown": "https://wpnews.pro/news/one-missing-firestore-rule-exposed-181874-meetings.md", "text": "https://wpnews.pro/news/one-missing-firestore-rule-exposed-181874-meetings.txt", "jsonld": "https://wpnews.pro/news/one-missing-firestore-rule-exposed-181874-meetings.jsonld"}}