Earlier this year, a routine penetration test conducted by an independent vendor identified a vulnerability affecting access to certain meeting metadata. During this same period, an independent security researcher also reached out to disclose findings related to this same vector. Utilizing these reports, we deployed a remediation, and the fix was later formally validated by our external penetration testing firm, confirming that the vulnerability was successfully closed.

Recently, however, we became aware of a newly discovered, alternative exploitation path related to the same part of our tech stack. Contrary to claims that a single vulnerability was left unresolved for six months, our independent penetration testing vendor has formally attested that these were two distinct vectors. The initial vulnerability was fully closed and validated months ago. This recent incident involved a secondary method of attack that was previously unknown.

Consistent with our standard security posture, which is to act immediately whenever any issue is identified, we deployed a second fix and completely closed this new vector within 24 hours of discovery.

Because the common denominator between both of these distinct incidents was Firebase, we are taking the additional step of immediately removing it from our tech stack altogether to definitively eliminate the risk of similar vulnerabilities in the future.

For complete transparency, a signed attestation from our penetration testing vendor confirming our procedural behavior and immediate remediation during both incidents is available upon request to customers and prospects at [email protected].


What was and wasn’t accessible

The vulnerable data was strictly limited to metadata: meeting identifiers, conference IDs (the links used to join Google Meet or Microsoft Teams calls) and participant email addresses and domains.

Crucially, no passwords, recordings, transcripts, AI-generated notes or account and billing data were accessible. None of this information could be reached through this vulnerability, nor is it stored in this part of our infrastructure in the first place. While we treat all personal information with the utmost seriousness, the exposed data did not include highly sensitive personal data or the actual contents of any conversations.

In terms of practical impact, there were two distinct vectors, which vary in severity:

First, by using the exposed meeting IDs, an individual could look up the transcript or AI notes strictly for meetings that users had explicitly chosen to make public. Public sharing on tl;dv is an opt-in setting which is off by default, and must be deliberately enabled by a customer who wants a meeting to be visible outside their team.

Because these users had intentionally enabled public link-sharing, this content was, by design, already accessible to anyone holding the link. Even for these public meetings, content was not surfaced through tl;dv’s normal browsing or search: reaching it required specific programmatic actions by a technically versed hacker.

Second, in a select few instances, the individual was able to obtain meeting URLs and enter the live rooms by using an unfamiliar name and being manually admitted by the Organizer. As part of our immediate fix, we have fully secured this access point to ensure meeting URLs can no longer be obtained this way.


The wider context

Public sharing settings across AI and SaaS products have surfaced similar findings in recent months. Anthropic addressed exposed public artifacts across Claude and its MCP ecosystem via Google Search. Lovable and Zoom have both worked through cases where user-configured public settings produced broader visibility than users had anticipated. It is a category of UX problem the industry is collectively getting sharper about.

The common thread: “public” can mean different things to different users, and the UX around opting into public visibility needs to make the consequences unambiguous. We are taking a fresh look at how we surface those choices in our own product even better, and expect to ship changes soon.


What we are doing going forward

Security is not a fixed destination for any platform. We continue to invest in independent testing, in fast remediation of anything that surfaces and in the ongoing evolution of how we protect customer data.

We also recognize the role the broader cybersecurity community plays in this journey. The researcher who identified this alternative vector is a highly skilled expert with a track record of uncovering vulnerabilities at massive organizations. Scrutiny from top-tier talent isn’t just an inevitable part of scaling a software platform, it is a necessary force that pushes our defenses to become stronger and more resilient.

On a personal note, I recognize that I should have kept the researcher updated after his initial outreach earlier this year, and I take full responsibility for that communication gap. Moving forward, we are refining our vulnerability disclosure and response processes to ensure that all external security reports receive the immediate attention, respect, and clear follow-up they deserve.


Reaching us

For any account-specific questions, please email [email protected].


Allan Bettarel
CTO, tl;dv

P.S. Yes, our team also built a small internal World Cup prediction app earlier this year, vibe-coded by non-engineering teammates for fun and hosted on a subdomain. It had no connection to any customer data or production systems, and we’ve since tightened up the access to it.