研究人员称，tl;dv 的一个漏洞暴露了 181,874 条会议记录和实时通话 ID。

Why it matters

AI meeting assistants are becoming repositories for corporate memory. A single tenant-isolation error can expose live-call details across thousands of organizations.

Raphael Allstadt (@rallstadt), Allan Bettarel and Carlo Thissen 正在应对 tl;dv 的一处安全故障，据称该故障允许任何已认证用户查询其他客户的会议记录并获取实时通话的 ID。应用安全研究员 BobDaHacker 统计了与 84,312 名用户相关的 181,874 条记录，并在一篇 8月4日的披露 中公布了这些发现。

该事件直接挑战了 Allstadt 对 tl;dv 所宣传的运营故事。他与两位长期朋友共同创立了这家德国 AI 会议公司，在创立第一年内曾一度仅差一天就会耗尽资金，最终将其发展为现宣称拥有超过 200 万用户的产品。在一篇关于早年经历的 2024 年回顾 中，Allstadt 描述了从投资者关注、收入停滞到学习如何招聘的压力之间的起伏。随着规模扩大，创始人面临了一个更为关键的考验：tl;dv 的安全实践是否跟上了托付给它的对话数量和敏感性的增长。

One collection crossed customer boundaries

BobDaHacker 表示，tl;dv 通过 gw.tldv.io/v1/users/firebase/token 用某用户的认证令牌交换到了一个 Firebase 令牌。该令牌据称允许对一个共享的 Cloud Firestore 数据库进行查询，而 meetings 集合缺乏租户隔离。

研究员称，暴露的记录包括会议创建者的电子邮件地址、会议提供商、录制状态、时间戳和会议 ID。一个标记为 recording 的会议的会议 ID 可能对应一个正在进行的 Google Meet 或 Microsoft Teams 通话。BobDaHacker 估计，在任一时刻大约有 1,000 条记录带有该状态。

Google 的 Firestore 安全指南 明确警告不要使用允许每个已认证用户访问数据库的规则。其文档建议使用基于用户或基于角色的规则，在每个请求中检查所有权和权限。

BobDaHacker 表示，他们使用从 Firestore 获取的会议 ID 进入了两次通话：一次是超过 157 名参与者的马来西亚教育部会议，另一次是一场由美国一所大学的 21 名学生共同参与、围绕创业项目的会议。Dark Reading 独立报道称，在 8 月 4 日的报道刊出时该缺陷仍然存在，当研究员以 AI 记事员的身份伪装时，大约有 80% 的私密会议会允许其入内。

这一差别很重要。持有会议 ID 并不自动绕过会议平台的等候室或入会控制。tl;dv 的暴露据称使通话可被发现，而主办人的弱控制和会议机器人常见的存在则提供了进入的途径。

The 181,874 figure describes metadata, not 181,874 open recordings

这个头条数字需要比原帖标题所暗示的更狭义地解读。BobDaHacker 报告称可访问 181,874 条会议记录，涉及 35,003 个电子邮件域名。研究员表示，录音、转录、片段、笔记及其他集合返回了授权错误，会议内容默认是私密的。

BobDaHacker 另行测试了 27,334 个会议 ID，并报告发现了超过 1,000 条公开可访问的记录，其中包括跨 228 个域的 715 个受邀者电子邮件地址。Dark Reading 后来引用研究员描述了大约 70,000 个会议的样本。这些已发布的报告并未对这些样本规模进行对齐。任何一组数据都不支持“所有 181,874 场会议的音频、视频或转录均可公开访问”的说法。

暴露的元数据仍具有操作价值。样本据称覆盖来自 23 个国家的政府域名、包括 Berkeley 和 the University of Tokyo 在内的大学，以及 HubSpot、Confluent、Mitsui Fudosan 和 AnyMind Group 等公司。会议时间、员工地址和实时会议 ID 可以揭示谁在发言、何时有通话正在进行以及外部人员可能如何接近它。

BobDaHacker 将最初的披露定为 2026 年 1 月 28 日。研究员记录了截至 7 月 22 日的后续情况，并表示在那时 Firestore 的访问仍然可用。因此，当公开报告出现时，该漏洞至少已存在六个月，而非在八月才首次被发现。

Security claims meet the founders' operating reality

对于一个以记录用户可能视为机密的对话为核心的产品来说，时间点非常不利。tl;dv 当前的 security page 声称该服务符合 SOC 2 Type II 和 GDPR 要求，使用 AES-256 加密存储数据，对生产系统进行漏洞扫描并在部署前审查代码。同一页面还承诺 tl;dv 的安全团队将在 24 小时内响应漏洞报告。

BobDaHacker 的披露描述了一个 Firestore 集合中的基本授权错误，以及从一月延续到七月的报告流程。Dark Reading 在一定程度上证实了该说法，包括能够检索其他客户的会议数据并进入通话。tl;dv 尚未提供公开的技术说明来确定完整范围、修复日期或受影响客户是否被通知。

Allstadt 的增长策略一直围绕让已记录的对话在原始通话之外也能发挥作用。tl;dv 现在宣传 AI 摘要、后续邮件、CRM 更新、销售评分和跨会议的聚合洞见。每增加一个流程，就会在 tl;dv 的访问控制后面集中更多的职场信息。

创始团队已经在产品上经历了一个艰难的变化。当 tl;dv 在 2022 年 6 月宣布完成 EUR4.3 million 的种子轮融资时，Allstadt 将其定位为一种跨平台的方式，用于异步记录、剪辑和回顾通话。K Fund 领投，Seedcamp、Mustard Seed Maze、another.vc 和 Shilling VC 参与了本轮融资。此后该产品已扩展为一个从对话中提取并分发知识的 AI 系统。

这种扩展提高了授权错误的代价。会议助理正从一次性转录工具转变为可检索的企业记忆库，其中记录可能暴露招聘决策、客户谈判、产品计划和内部争议。tl;dv 的创始人通过降低记录和共享的摩擦来构建分发渠道。他们下一步的运营挑战是证明对这些记录的访问被同等谨慎地限制。