181874 条会议记录泄露：Firestore 安全规则缺失的教训

一名化名为 bobdahacker 的安全研究员本月披露了 tl;dv 的漏洞——这是一款接入 Zoom、Meet 和 Teams 会议的 AI 笔记工具：来自 84,312 名用户的 181,874 条会议记录可以被任意已认证用户读取。不是通过什么复杂的攻击链——而是一条缺失的 Firestore 安全规则。据该研究员所述，部分记录甚至包含了陌生人可以直接加入的实时会议录音，而这次披露在经过约六个月的跟进后仍未得到修复。

这个漏洞本身几乎平淡无奇——这恰恰是它值得一写的原因。

平淡的技术细节

tl;dv 的客户端完成认证后，用会话凭证换取 Firebase token，直接与 Firestore 通信——这是一种完全标准化的无服务端架构。在这类架构中，每个租户的隔离依赖于安全规则，逐集合配置。tl;dv 的大部分集合都有正确的规则，唯独 meetings 集合缺失了——因此任何已登录用户都可以列出所有租户的文档。

就差一条规则。这就是整个漏洞。Firestore 的整个模型将授权集中在声明式规则中，恰恰是为了防止它散落在应用代码各处——但集中化是一把双刃剑：一次遗漏就变成了一次彻底的、可查询的泄露，而唯一的要求就是持有一个有效 token。如果你基于 Firestore、Supabase 或任何客户端直连数据库的平台构建，"以普通已登录用户身份列出所有集合的文档"应该进入你的 CI 测试，而不是事后的复盘。它是世上最廉价的安全测试之一。

与 AI 工具相关的部分

这就是它不止于一起普通 SaaS 数据泄露故事的原因。AI 会议笔记工具不是你使用的一个应用；是你邀请进来的一个 Agent——进入董事会、销售谈判、站会、一对一。它全部的价值主张就是拥有所有内容的访问权并记住一切。这意味着它的爆炸半径不是抽象的"用户数据"；而是来自 35,003 个不同组织的对话原文，被索引和转录，方便泄露。

我们正以极快的速度将 AI 工具接入日历、收件箱、代码库和会议，而围绕它们的安全讨论集中在模型层面——提示词注入越狱、提示词规避、训练集中的数据。tl;dv 的漏洞与 AI 毫无关系。它是 2015 年水准的访问控制遇上了 2026 年水准的数据集中度。模型风险是真实存在的，但那些枯燥的风险先到了，而且它们随着我们授予这些工具的访问权限增长而扩大——而这些工具的权限，正在越来越大。

六个月的披露时间线值得单独提一句：一位研究员报告了"你们所有会议都是公开的"并反复跟进，却始终未能得到解决——这是流程层面的失败，和漏洞本身一样严重。客观地讲：tl;dv 随后已修补了该漏洞并公开承认，描述为两个独立漏洞。好——但根据现有记录，修复是在 8 月初公开披露前后才上线的，而不是 1 月份的报告，这个时间差才是值得记住的部分。

三件事，都不惊天动地。在评估任何处理敏感材料的 AI 工具时，问清楚授权在哪里执行——客户端规则、API 层、行级安全——以及他们是否做过测试；回答含糊的公司其实已经回答了。优先选择可以限定录制/保留范围的工具：一款看不到会议记录的工具不会泄露它，默认录制一切是一种风险姿态而非功能。在你自己的组织内部，把"哪些 Agent 拥有对什么的常设访问权限"当作一份实际的资产清单来管理，就像你追踪服务账号的方式一样——因为这些工具本质上就是服务账号。

这不是反对 AI 工具链；我自己的工作流有一半依赖 AI 笔记工具的输出。这是在呼吁保持适度：拥有最深访问权限的工具正在受到最浅层次的审查，而 tl;dv 的这次披露就是当有人终于去检查时看到的样子。

如果你的团队有一份专门针对 AI 工具的供应商安全检查清单，我很乐意看看上面写了什么。

研究和起草过程有 AI 辅助；所有测试、观点和最终编辑由本人完成。