tl;dv(Too Lazy; Didn't Validate):181,874 场会议门户大开
我在 2026 年 1 月 28 日报告了这个问题。现在是 2026 年 7 月。六个月过去了。Firestore 数据库仍然门户大开。CTO 从未回复。我猜是我的邮件太长了,他们没看。
什么是 tl;dv?
tl;dv(Too Long; Didn't View)是一个 AI 会议录制平台。它会往你的 Google Meet、Zoom 或 Teams 通话里投放一个机器人,录制全部内容,进行转录,并用 AI 生成摘要。用户超过 200 万。有投资人支持。LinkedIn 销售网红社区里有一半人在为它站台。
他们存储你的销售通话、求职面试、绩效评估、内部战略会议。就是那种有人说"本次通话正在被录音",大家紧张地笑一笑,然后分享 45 分钟商业机密的场合。
漏洞
当你注册 tl;dv 时,平台用 JWT 对你进行认证,并通过 gw.tldv.io/v1/users/firebase/token 将其换取一个 Firebase token。该 token 让你可以查询他们在 projects/lmi-store/databases/(default) 上的 Firestore 数据库。
meetings 集合没有租户隔离。任何已认证的 tl;dv 用户都可以查询平台上每个账户的每一场会议。每条会议记录都会交给你创建者的邮箱地址、会议 ID(这是一个可加入的 Google Meet 或 Teams 房间)、服务提供商、录制状态和时间戳。
对于处于 recording 状态的会议,那个会议 ID 就是一个正在进行的、活跃的通话。你可以实时观看这个集合,看到会议开始录制,抓取 ID,然后不请自来地走进别人的通话。在任何给定时刻,集合中大约有 1,000 个带有 status: recording 的会议。一千个暴露了会议 ID 的实时通话。一个带有机器人的攻击者可以同时加入所有这些通话。

我加入了 2 场会议
我做到了。
从 Firestore 抓取了一个会议 ID,加入了一场属于 马来西亚教育部 的实时 Google Meet。一位女士正在向 157 多名参与者做演示。tl;dv 机器人已经在参与者名单中了。我就在同一个通话里。没有人邀请我。是 Firestore 数据库邀请的。

我还加入了一场通话,里面是来自一所美国主要大学的学生正在构建一个创业应用。通话中有 21 人。他们正在屏幕共享整个项目,讨论原型,而且,不骗你,还在谈论他们需要为 .edu 电子邮件地址添加客户端验证。他们还在屏幕上实时设置 Supabase,我满脑子想的都是“请设置 RLS 策略”,因为大多数人不设,然后你就会落得和 tl;dv 一样的下场。
我太想开口说点什么了。“嘿,你可能还需要服务端验证。”但这是一个概念验证,不是咨询。

规模
我查询了 Firestore meetings 集合,发现有 181,874 条会议记录,属于 84,312 个独立用户,覆盖 35,003 个电子邮件域名。
来自 23 个国家的政府会议:巴西、哥伦比亚、秘鲁、乌克兰、萨尔瓦多、菲律宾、智利、印度尼西亚、墨西哥、美国、卡塔尔、马来西亚、乌兹别克斯坦、斯里兰卡、海地、南非、牙买加、洪都拉斯、阿根廷、泰国、日本、以色列和伯利兹。全部都是 .gov 域名。政府雇员在一个任何免费套餐用户都能枚举全部内容的平台上录制通话。
来自伯克利、东京大学、德拉萨大学、哥伦比亚国立大学的大学会议。数十个 .edu 和 .ac 域名。
来自其余全部 35,000 个域名的企业会议。三井仓库(484 场会议,横跨四个地区办事处)、三井不动产、HubSpot、Confluent、Mekari、AnyMind Group。每一家曾经使用过 tl;dv 的公司,其会议元数据都存放在同一个未受保护的集合中。
峰值月份是 2025 年 7 月,共 43,209 场会议。最繁忙的时段:UTC 时间周三下午 2 点,7,804 场会议。周三高峰日的站会时段。
但是等等,还有更多
我还想知道默认情况下有多少实际内容可以访问——会议默认是私密的(也就是说你无法观看视频或查看转录文本),所以我抓取了 27,334 个会议 ID,并检查了其中哪些是公开的。超过 1,000 个是公开的。715 个受邀者邮箱暴露在 228 个域名之下。
亮点:一场巴西政府保护会议(PACTO Mata Atlântica),参与者来自 WWF、The Nature Conservancy、Conservation International、WRI 以及圣保罗州政府。来自乌克兰数字转型部的会议。一通 HubSpot 销售电话。涉及哥伦比亚国立大学和智利 Cámara Verde 的会议。
意面基础设施
tl;dv 用意大利面来命名他们的微服务。一次子域名扫描发现了 cappellini、carbonara、fusilli、pasta、penne、puttanesca-v0 和 ravioli,全部位于 tldv.io 之下。整整一家意大利餐厅分量的 Express 服务器。
太长;没进球
在探索他们的子域名时,我发现了 https://worldcup.tldv.io。这是一个为 tl;dv 员工打造的、基于 Base44 的 FIFA World Cup 2026 氛围编程预测游戏。它叫“World Cup Pick'em”,他们的内部队伍名叫“Too Long; Didn't Score”。挺可爱。
Player 实体 API 完全没有身份验证。GET /api/entities/Player 无需会话 cookie 就能返回所有玩家记录。43 名玩家。 19 名 @tldv.io 员工,包含全名和企业邮箱。
Raphael Allstadt,我的披露联系人,给了我含糊的安抚,然后就没了音讯,他以 298 分排名第二。他的个人 Gmail 也出现在 API 响应中。全球排行榜上的第 5 名玩家是“Super Duper CEO”。是谁就留给你们猜了。
Prediction 和 Fixture 实体同样完全敞开。一家录制了数百万人会议的公司,用 vibecoding 做了一个内部娱乐应用,结果泄露了自己员工的通讯录。这讽刺意味真是恰到好处。

披露
1 月 28 日,我在 LinkedIn 上给 Raphael Allstadt 发消息,告诉他我发现了一个泄露用户数据的重大漏洞。他几分钟内就回复了:“谢谢!你能把它报告给我们的 CTO 吗?我们会立刻查看。”我把邮件发了过去。他说“谢谢!”我问了奖励的事。他说:“我的 CTO 会回复你。”
CTO 再也没有回复我。
1 月 29 日:“顺便说一句,你们的 CTO 还没联系我,问题也没修好。”1 月 30 日,Raphael:“我相信团队很快就会很快审查它 ❤️”2 月 14 日:“还没收到邮件,漏洞仍然有效。”Raphael:“他会回来的 ☺️”我告诉他,也许应该修复漏洞,而不是让客户继续暴露在风险中。2 月 19 日:“我们正在处理。这需要一些时间,但请放心,我们会跟进的。如需进一步沟通,我建议你联系我们的 CTO。”
那位从未回复的 CTO。就是那位 CTO。
3 月 6 日:“仍然没有修好。”Raphael 于下午 5:42 已读。没有回复。
7 月 22 日:“仍然没有修好……”没有回复。
他们的安全页面就是一个奖杯陈列柜。符合 SOC2。符合 GDPR。符合 EU AI Act。托管在欧盟。AES-256 加密。一段创始人承诺视频。六枚合规徽章排成一排。最底部埋着一行字:“如果你发现了我们应该处理的隐私或安全问题,请随时通过 [email protected] 告诉我们。我们的安全团队将在 24 小时内回复。”我直接给 CTO 发了邮件。六个月。没有回应。他们的 Firestore 数据库正常运行时间都比他们的收件箱强。
| 日期 | 事项 |
|---|---|
| 2026 年 1 月下旬 | 发现 Firestore 租户隔离绕过 |
| 2026 年 1 月 28 日 | 联系了 Raphael Allstadt(LinkedIn),并给 CTO 和 Raphael 发了邮件 |
| 2026 年 1 月 29 日 | Raphael 给出了含糊的安抚 |
| 2026 年 2 月至 3 月 | 多次跟进。CTO 始终没有回复。 |
| 2026 年 7 月 | 仍然没有修复。仍然没有回应。祝你好胃口。 |
致 tl;dv
你们的平台记录着人们最敏感的对话。求职面试。销售谈判。政府简报。你们的用户信任你们,把明确同意录制的内容交给了你们。
修复 Firestore 的租户隔离问题。Firestore 安全规则就是为此而设的。你对其他所有集合(users、chats、transcripts、clips、recordings、videos、notes、teams、organizations 都返回 403)都已经正确处理了。你只是忘了 meetings。
给世界杯应用加上身份验证,否则就把它下线。你的员工名录只差一个 GET 请求就能拿到。
回应安全研究人员。尤其是当他们告诉你,你平台上的每一场会议都能被任何拥有免费账户的人查询到的时候。
再见,感谢所有的意面 :3
tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open
I reported this on January 28th, 2026. It is now July 2026. Six months later. The Firestore database is still wide open. The CTO never responded. I guess my emails were too long and they didn't view them.
What is tl;dv?
tl;dv (Too Long; Didn't View) is an AI meeting recording platform. It drops a bot into your Google Meet, Zoom, or Teams call, records everything, transcribes it, and generates summaries with AI. Over 2 million users. Backed by investors. Endorsed by half of LinkedIn's sales influencer community.
They store your sales calls, job interviews, performance reviews, internal strategy sessions. The kind of content where someone says "this call is being recorded" and everyone nervously laughs and then shares trade secrets for 45 minutes.
The Vulnerability
When you sign up for tl;dv, the platform authenticates you with a JWT and exchanges it for a Firebase token via gw.tldv.io/v1/users/firebase/token. That token lets you query their Firestore database at projects/lmi-store/databases/(default).
The meetings collection has no tenant isolation. Any authenticated tl;dv user can query every meeting across every account on the platform. Each meeting record hands you the creator's email address, the conference ID (which is a joinable Google Meet or Teams room), the provider, the recording status, and timestamps.
For meetings in recording status, that conference ID is a live, active call. You can watch the collection in real time, see a meeting start recording, grab the ID, and walk into someone's call uninvited. At any given time there are roughly 1,000 meetings with status: recording sitting in the collection. A thousand live calls with exposed conference IDs. An attacker with a bot could join all of them simultaneously.

I Joined 2 Meetings
I did it.
Grabbed a conference ID from Firestore and joined a live Google Meet belonging to the Malaysian Ministry of Education. A lady was presenting to over 157 participants. The tl;dv bot was already in the participant list. I was in the same call. Nobody invited me. The Firestore database did.

I also joined a call where students from a major US university were building a startup app. 21 people in the call. They were screen-sharing their entire project, discussing prototypes, and, I kid you not, talking about how they needed to add client-side validation for .edu email addresses. They were also setting up Supabase live on screen, and all I could think was "please set up RLS policies" because most people don't, and then you end up like tl;dv.
I wanted to say something so badly. "Hey, you might want server-side validation too." But this was a proof of concept, not a consultation.

The Scale
I queried the Firestore meetings collection and saw there were 181,874 meeting records belonging to 84,312 unique users across 35,003 email domains.
Government meetings from 23 countries: Brazil, Colombia, Peru, Ukraine, El Salvador, the Philippines, Chile, Indonesia, Mexico, the United States, Qatar, Malaysia, Uzbekistan, Sri Lanka, Haiti, South Africa, Jamaica, Honduras, Argentina, Thailand, Japan, Israel, and Belize. All .gov domains. Government employees recording calls on a platform that lets any free-tier user enumerate the whole thing.
University meetings from Berkeley, the University of Tokyo, De La Salle, Universidad Nacional de Colombia. Dozens of .edu and .ac domains.
Corporate meetings from all 35,000 remaining domains. Mitsui-Soko (484 meetings across four regional offices), Mitsui Fudosan, HubSpot, Confluent, Mekari, AnyMind Group. Every company that ever used tl;dv had their meeting metadata in the same unprotected collection.
Peak month was July 2025 with 43,209 meetings. Busiest time slot: Wednesday at 2pm UTC, 7,804 meetings. Hump-day standup hour.
But Wait, There's More
I wanted to know how much actual content was accessible too, by default meetings are private (Meaning you cant watch the video or see the transcript), so I scraped 27,334 meeting IDs and checked which ones were public. Over 1,000 were. 715 invitee emails exposed across 228 domains.
Highlights: a Brazilian government conservation meeting (PACTO Mata Atlântica) with participants from WWF, The Nature Conservancy, Conservation International, WRI, and the São Paulo state government. Meetings from Ukraine's Ministry of Digital Transformation. A HubSpot sales call. Sessions involving Universidad Nacional de Colombia and Chile's Cámara Verde.
The Pasta Infrastructure
tl;dv names their microservices after pasta. A subdomain scan reveals cappellini, carbonara, fusilli, pasta, penne, puttanesca-v0, and ravioli, all under tldv.io. An entire Italian restaurant worth of Express servers.
Too Long; Didn't Score
While exploring their subdomains I found https://worldcup.tldv.io. A FIFA World Cup 2026 vibecoded prediction game built on Base44 for tl;dv employees. It's called "World Cup Pick'em" and their internal squad is named "Too Long; Didn't Score." Cute.
The Player entity API has zero authentication. GET /api/entities/Player returns every player record without a session cookie. 43 players. 19 @tldv.io employees with full names and corporate emails.
Raphael Allstadt, my disclosure contact who gave vague reassurances and then went quiet, came in 2nd place with 298 points. His personal Gmail was also in the API response. Player #5 on the global leaderboard is "Super Duper CEO." I'll let you guess who that is.
The Prediction and Fixture entities are also wide open. A company that records millions of people's meetings vibecoded an internal fun app that leaks their own employee directory. The irony is al dente.

Disclosure
On January 28th I messaged Raphael Allstadt on LinkedIn and told him I'd found a huge vulnerability that leaks user data. He responded within minutes: "thank you! can you report it to our CTO and we will look at it immediately?" I sent the email. He said "thank you!" I asked about a reward. "My CTO will come back to you," he said.
The CTO never came back to me.
January 29th: "your cto hasnt reached out yet btw and its not fixed." January 30th, Raphael: "I am sure the team is reviewing it very very soon ❤️" February 14th: "havent got an email and the vulnerability stilll works." Raphael: "He'll come back ☺️" I told him to maybe fix the vulnerability and not leave customers exposed. February 19th: "We're on it. It needs some time, but rest assured we're following through. For further communication, i'll recommend reaching out to our CTO."
The CTO who never responded. That CTO.
March 6th: "still not fixed." Seen by Raphael at 5:42 PM. No reply.
July 22nd: "still not fixed..." No reply.
Their security page is a trophy case. SOC2 compliant. GDPR compliant. EU AI Act compliant. Hosted in the EU. AES-256 encryption. A founder commitment video. Six compliance badges lined up in a row. Buried at the bottom, a single line: "If you have discovered a privacy or security issue that we should address, please always let us know at [email protected]. Our security team will respond within 24 hours." I emailed the CTO directly. Six months. No response. Their Firestore database has better uptime than their inbox.
| Date | What |
|---|---|
| Late January 2026 | Discovered Firestore tenant isolation bypass |
| January 28, 2026 | Reached out to Raphael Allstadt (LinkedIn) and emailed CTO + Raphael |
| January 29, 2026 | Raphael gives vague reassurance |
| February - March 2026 | Multiple follow-ups. CTO never responds. |
| July 2026 | Still not fixed. Still no response. Buon appetito. |
To tl;dv
Your platform records people's most sensitive conversations. Job interviews. Sales negotiations. Government briefings. Your users trusted you with content they explicitly consented to record.
Fix the Firestore tenant isolation. Firestore security rules exist for this. You already do it correctly for every other collection (users, chats, transcripts, clips, recordings, videos, notes, teams, organizations all return 403). You just forgot meetings.
Put auth on the World Cup app or take it down. Your employee directory is one GET request away.
Respond to security researchers. Especially when they're telling you that every meeting on your platform is queryable by anyone with a free account.
So long and thanks for all the pasta :3