A missing tenant boundary in the back end of AI meeting assistant tl;dv reportedly allowed any authenticated user to enumerate meeting records belonging to other customers, including live calls hosted by government agencies, universities, and major companies.
The issue did not require a stolen administrator account, malware, or a flaw in Google Cloud itself. According to research published by BobDaHacker and reporting from Dark Reading, a normal tl;dv account could obtain a Firebase authentication token and query a Cloud Firestore collection containing meeting records from across the service. Those records included the meeting creator’s email address, conferencing provider, timestamps, recording status, and a conference identifier that could be used to reach the underlying Google Meet or Microsoft Teams room.
Dark Reading reported that the exposure remained active when its article was published on August 4, 2026. The researcher said the issue was first reported to tl;dv on January 28, followed by repeated messages through July. Dark Reading said its own attempts to reach the company received no reply before publication.
One Collection Broke the Tenant Boundary
Tl;dv records, transcribes, and summarizes meetings held through Google Meet, Zoom, and Microsoft Teams. Its own support documentation says the service can connect to a user’s calendar and send a notetaker bot to scheduled calls. For Google Meet, the bot still requests admission, and a host must let it into the room before recording begins.
The reported flaw sat behind that workflow. When a user authenticated to tl;dv, the platform issued its own session credential and exchanged it for a Firebase token. That token gave the client access to tl;dv’s Firestore back end. Most collections reportedly enforced account or organization boundaries correctly, blocking access to other customers’ users, transcripts, chats, recordings, notes, and team data. The meetings collection was the exception.
BobDaHacker reported that any signed-in user could list documents from that collection across all tenants. A meeting document exposed enough operational metadata to identify who created the call, which conferencing service hosted it, whether recording was active, and which conference room was involved. The researcher said roughly 1,000 records could be marked as actively recording at a given time, turning the collection into a near-real-time directory of calls using the service.
This is a broken object-level authorization problem expressed through a serverless database. Authentication answered one question: whether the requester had a valid tl;dv account. The missing control was authorization: whether that account belonged to the same user, team, or organization as the requested meeting document.
How the Exposure Became a Meeting Intrusion Path
Reading a meeting record did not automatically place an attacker inside the call. The conference identifier led to the meeting room, but platform admission rules still applied. That left a second boundary: the host, lobby, waiting room, or guest-access configuration on the conferencing service.
The researcher told Dark Reading that impersonating an expected AI notetaker and requesting admission worked in about 80% of tested cases. Dark Reading described one public Google Meet session hosted by an institute linked to Malaysia’s Ministry of Education. BobDaHacker’s own write-up says the researcher entered that call, which had more than 150 participants, and separately entered a university meeting where participants were sharing product development work. The 80% figure is the researcher’s estimate reported by Dark Reading, not an independently published test dataset.
The admission success rate, if representative, points to a security problem beyond database rules. Meeting bots have become familiar participants. Hosts may see a generic notetaker identity, assume another attendee invited it, and approve entry without verifying the account behind it. Tl;dv’s own instructions say its bot can appear in the waiting room and may be flagged by Google Meet as a potential security risk, yet it can still be admitted through host controls.
The result is a two-stage attack path. The technical failure disclosed live meeting metadata across tenants. The human and conferencing-control failure converted that metadata into possible access to audio, video, screen sharing, chat, and spoken confidential information.
Reported Scale Reached Governments, Universities, and Companies
BobDaHacker reported finding 181,874 meeting records tied to 84,312 unique users across 35,003 email domains. The dataset included government domains from 23 countries, university domains linked to institutions such as the University of California, Berkeley and the University of Tokyo, and corporate domains associated with organizations including HubSpot and Mitsui Fudosan.
The broad meeting index did not mean every recording or transcript was public. The researcher said recordings were private by default and reported that other Firestore collections returned permission errors. To measure direct content exposure, the researcher sampled 27,334 meeting identifiers and checked their public-sharing state. More than 1,000 were reportedly public, exposing some transcripts and invitation data; 715 invitee email addresses across 228 domains were found in that subset.
That distinction matters. The primary defect exposed cross-tenant metadata and live join information. A smaller set of meetings also exposed content through public-sharing settings. Private settings reduced the impact for many completed calls, yet they did not protect a live call from an uninvited participant who obtained the conference identifier and passed the meeting’s admission check.
Why Firebase Security Rules Matter
Cloud Firestore is built to let web and mobile clients communicate directly with stored data. In that architecture, access rules are part of the application’s security boundary, not an optional back-end refinement. Google states that Firebase Security Rules control reads and writes at matched document paths, and warns that client-accessible deployments depend on those rules to block malicious requests.
A rule that checks only whether request.auth exists can be suitable during development, but it grants 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 identifier stored on the meeting document. Google’s documentation presents this pattern through checks against request.auth, document fields, user identifiers, roles, and custom authentication claims.
Firestore also treats security rules as query constraints, not post-query filters. A client cannot request an unrestricted collection and expect Firestore to remove unauthorized documents after retrieval. If a query could return records the requester is barred from reading, Firestore rejects the request. A correct tenant rule must be paired with a query scoped to the permitted tenant or owner.
Document design matters too. Firestore reads operate at the document level. Security rules cannot expose one field in a document and conceal another field from the same reader. If a conference identifier, creator email, recording state, and benign display data occupy one document, a user allowed to read that document receives all of those fields. Sensitive join material should be separated from broadly readable scheduling or analytics records, or returned through a server-side service that performs its own authorization checks.
Encryption and Compliance Badges Did Not Address the Failure
Tl;dv’s security page states that it is SOC 2 Type II compliant, GDPR compliant, hosted across Google Cloud, AWS, and Hetzner infrastructure, and uses AES-256 encryption for stored data. The company also says it follows OWASP Top 10 practices, scans production systems for vulnerabilities, reviews code before deployment, and responds to vulnerability reports within 24 hours.
None of those controls, by themselves, prevent a valid user from reading data that an application rule authorizes incorrectly. Encryption protects data from parties that lack the decryption path. In this case, Firestore reportedly returned the records through an authenticated application session. The database treated the request as permitted, so encryption at rest did not block the read.
The incident also shows the limit of using certifications as a substitute for direct control validation. A SOC 2 examination assesses a service organization’s system description and controls tied to security, availability, processing integrity, confidentiality, or privacy. It does not prove that every collection, API route, or new feature has correct object-level authorization. A single rule exception can bypass an otherwise mature control set.
The disclosure process raises a separate issue. Tl;dv publicly promises a 24-hour response from its security team. BobDaHacker published a timeline showing messages beginning January 28 and continuing through July, with no response from the chief technology officer and no confirmed fix. Dark Reading also reported no reply before publication.
A Second Exposure Hit tl;dv’s Own Employee Data
During subdomain research, BobDaHacker also found an internal World Cup prediction application used by tl;dv employees. The researcher reported that an unauthenticated player-data API returned 43 player records, including names, corporate email addresses, and some personal email addresses. Dark Reading reported 42 exposed employees or players, creating a small numerical discrepancy between the two accounts. Both sources agree that the endpoint lacked authentication and disclosed employee information.
The second issue was separate from the Firestore tenant failure, but it reflects the same control class: data endpoints exposed without access checks that matched the sensitivity of the records behind them.
What tl;dv Would Need to Fix
The immediate correction is to deny cross-tenant reads on every meeting document. Firestore rules should require a valid authentication token and verify that the requester belongs to the meeting’s owner, team, or organization. The client query must include the same tenant condition, since Firestore rejects queries that could produce unauthorized results.
The company would also need to test the rule from an adversarial position. Google provides a Firestore Emulator Suite and a rules-testing library that can simulate authenticated and unauthenticated users, assert successful and failed requests, trace rule evaluations, and generate coverage reports. A production test suite should create two or more tenants, then prove that users from one tenant cannot list, retrieve, update, or subscribe to another tenant’s meeting records.
A full response would go past the rule change. Tl;dv would need to review Firestore access logs, token issuance, large collection queries, real-time listeners, and repeated reads of live meeting records to estimate whether the exposure was abused by anyone other than the reporting researcher. It would need to identify affected customers, assess disclosure duties, invalidate any persistent links that remain usable, remove public sharing where it was unintentionally enabled, and document the time window during which cross-tenant access was possible.
The data model also needs revision. Live conference identifiers should not sit in a collection that ordinary clients can enumerate. A safer design would keep sensitive join data behind a server-side authorization layer, issue short-lived access only to approved participants, separate meeting analytics from room credentials, and limit list operations by tenant, role, rate, and business purpose.
What Organizations Using AI Notetakers Should Change
Organizations should treat an AI notetaker as a privileged third-party participant, not a passive transcription feature. The bot can receive live audio, video, shared screens, participant identities, calendar context, and post-meeting content. Its account permissions, data store, integrations, and meeting admission behavior belong inside the organization’s SaaS risk and identity-governance program.
For sensitive calls, hosts should admit meeting bots only after confirming who invited them and which vendor account they represent. Anonymous guests and external bots should remain blocked by default. Government, legal, health, finance, incident-response, personnel, merger, acquisition, and executive meetings may need a no-bot policy or a separately approved recording process.
Administrators should review which users connected meeting assistants to corporate calendars, which meetings are set to auto-record, how recordings are shared, and how long data is retained. Tl;dv provides team-level defaults that can keep meetings private and apply rules based on meeting context, but customer-side privacy settings cannot repair a vendor’s broken tenant boundary. They serve as a containment layer when another control fails.
Meeting platforms should also require authenticated participants, enforce waiting rooms, restrict guest admission, and log participant changes. A bot that appears unexpectedly should be removed and investigated, even when its display name resembles an approved notetaker. Familiarity is not identity verification.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
