180,000 meetings. Assuming five people per call, that represents the conversations of 900,000 individuals—sales negotiations, job interviews, performance reviews, company strategy sessions, and government agency meetings. They were stored in a cloud database by an AI meeting assistant tool, and the door to that database was unlocked. Anyone who registered a free account could browse through all 180,000 meeting logs, and even retrieve live links to ongoing calls to walk right in uninvited. Cybersecurity researcher Bob Diachenko did just that: he walked straight into an online meeting of Malaysia’s Ministry of Education with 157 attendees present. Nobody had invited him, and the session was actively being recorded.
A Company Built on Keeping Other People’s Secrets
The company is named tl;dv (short for “Too Long; Didn’t View”), an AI meeting assistant tool that invites a bot into your Zoom, Google Meet, or Teams calls to record the session, generate transcriptions, and summarize key takeaways using AI. Boasting over two million users and backed by venture capital, it is widely recommended across sales circles on LinkedIn.
Sales calls, recruitment interviews, performance evaluations, internal strategy discussions—users store everything inside. It is precisely the kind of content shared after the “This meeting is being recorded” prompt sounds, everyone exchanges an awkward smile, and then proceeds to discuss confidential business matters for the next 45 minutes.
How the Vulnerability Happened: No Hackers, Just an Unlocked Door
To be clear: this was not a sophisticated cyberattack. There was no password cracking, no zero-day exploitation; the attacker did not even need to crack anything.
The issue resided in the database’s access controls. Cloud databases like Google’s Firestore rely on a fundamental security rule: each user must only access their own data, known in technical terms as tenant isolation. tl;dv’s database lacked this isolation layer entirely. Imagine an apartment building where every room should be locked independently, but instead, the building has a single central lobby containing a master ledger listing every room number, tenant email address, and which room is currently holding a meeting. Any tenant signing up for a free account could flip through the master ledger and knock on any room door.
Figure: A searchable list of meeting records discovered by researchers. Any logged-in user could query all entries. Source: bobdahacker.com
Researchers tallied the database contents: 181,874 meeting records belonging to 84,312 users across 35,003 corporate domains. The leak included meetings from government agencies in 23 countries, top universities such as UC Berkeley and the University of Tokyo, and major corporations like Mitsui and HubSpot. The single highest peak occurred last July, with 43,209 new meetings recorded in a single month.
Even more alarming was the real-time exposure: at any given moment, roughly 1,000 meetings were actively being recorded, with live meeting links sitting exposed in the database, allowing automated scripts to join calls in bulk. The researcher demonstrated this live: when he entered the 157-person Malaysian Ministry of Education meeting, a presentation was underway, and tl;dv’s own bot was listed alongside the attendees.
Figure: An online call joined uninvited by a researcher, with 157 attendees present while recording was in progress. Source: bobdahacker.com
For potential attackers, the value of this dataset extends far beyond textual meeting summaries—to the raw audio itself. Voice fraud prevention professionals noted in comment sections that with samples of an employee’s genuine voice, AI models can clone voices convincingly enough to call finance departments requesting wire transfers. This leak essentially distributed the voiceprints of tens of thousands of people to the entire world.
What Was Exposed Inside the Meeting Logs
What happens inside a meeting? Salary negotiations, layoff lists, M&A plans, legal disputes, and client pricing floors. Meetings from government bodies can involve national security—transcripts from Ukraine’s Ministry of Digital Transformation were present in the leaked data, leading commenters to ask bluntly whether Ukraine realized Russia could be watching. In another crashed call, a student startup team from an American university was screen-sharing and discussing project prototypes. As they talked about implementing email validation, the researcher reflected: “Please set your database permissions correctly too.”
Figure: Another call crashed by researchers, where a student startup team was screen-sharing a project demo. Source: bobdahacker.com
Additionally, over 1,000 meetings had been marked as “public” by users, allowing audio recordings and transcripts to be viewed directly. These included an environmental protection meeting held by the Brazilian government with WWF and The Nature Conservancy present, as well as a HubSpot sales call. Furthermore, 715 attendee email addresses were exposed across 228 domains—providing a ready-made target list for phishing campaigns.
The Company’s Response: Months of Silence Followed by a “Public Data” Defense
What angered the tech community most was how the issue was handled after discovery. On January 28, the researcher contacted tl;dv via LinkedIn. Within minutes, the company replied: “Thanks! Please send this to our CTO.” After that, the CTO never responded. The researcher followed up repeatedly in February, March, and July, while the database remained wide open. It was not until early August, when the investigation report went public and media outlets began covering the story, that the company patched the vulnerability within days and published an official response.
The most controversial statement in the company’s response claimed that exposed data was “strictly limited to metadata,” while recordings and transcripts “were never leaked,” asserting that accessible calls were merely those “users explicitly chose to make public,” classifying them as “public data.” Community members reacted with outrage: the researcher had obtained complete transcripts and recordings from over 1,000 public meetings, and users checking “share publicly” certainly did not realize they were making their calls indexable by the entire world. Adding to the irony, the company’s CEO had stated in a public interview months earlier that European companies “care more about data, security, and privacy” and “build compliance into the product from day one”—a quote now quoted verbatim across discussion threads.
What Do Security Certifications Actually Audit?
This brings us back to the core question: certifications. The company’s security page displays a prominent lineup of badges: SOC 2 compliance, GDPR adherence, AES-256 encryption—resembling a trophy case. Following the incident, the most prominent voice across developer forums was that these certifications mean virtually nothing.
What does an audit actually verify? Put simply: whether you have documented security policies and whether you can show that you follow your documented processes. What does it fail to verify? Whether the policy itself is well-designed, whether your database is locked, or whether the software is actually secure. To draw an analogy: it is like an exam that only tests whether you answered according to your own written rules, rather than whether your answers are correct—if you write “1+1=3” and prove you calculated accordingly, you still pass. Or in everyday terms: a health inspector confirming that a restaurant posted a “Kitchen Hygiene Manual” without evaluating whether the manual specifies “wipe counters daily” or “wipe counters once before opening,” nor checking the counters directly.
An industry practitioner shared a story illustrating this reality: to pass a compliance audit, his company required him to install “compliance monitoring software” on his laptop. He complied, placed the machine aside, and continued working on his personal laptop—leaving the “certification completely intact.” Another user noted using a certified product whose chat logs were forcibly uploaded to vendor servers and made public with a single click. Compliance frameworks prove that a company “does what it says,” but the fundamental flaw has always been: whether what was said holds any real value in the first place.
Further Reflections on Trust and Compliance
In this incident, the technical details are straightforward; what is complex is the collapse of trust. Users entrusted their most private workplace discussions to a tool, which placed them in an unlocked cabinet. Users assumed certification badges represented a guarantee of security, while compliance frameworks only guaranteed that paperwork was filed. A database vulnerability can be patched, and Firebase rules can be rewritten, but the erosion of trust surrounding the word “certified” is far harder to repair.
This article does not aim to reach a final verdict for either party: the company maintains that there were “two independent vulnerabilities, the first of which was long fixed,” while the researcher documented “six months of unresponsiveness with the database remaining open.” Readers may compare both accounts and draw their own conclusions. Yet one question is worth pondering for everyone: the next time an online meeting host announces “This call is being recorded,” it might be worth asking—does the tool recording it truly deserve your voice?
Reference links:
- Bob Diachenko: Tl;dv Leak Investigation Report
- Hacker News Discussion Thread (HN)
- tl;dv Official Response: “Our thoughts on the darkreading.com article”
- Dark Reading Report: “AI Notetaker Exposes Government, Corporate Video Calls”
- SourceFeed Analysis: “One Missing Firestore Rule Exposed 181,874 Meetings”
