Muse 分享链接经 DNS 记录暴露隐私

Muse 的聊天分享出了一个容易被忽略的问题：用户分享的对话标题被写进子域名，访问时留下的 DNS 记录，又让原本需要拿到链接才能查看的页面变得可以被查询发现。Claroc 研究团队通过一次被动 DNS 查询，找到了超过 6800 个分享页面的主机名。

按 IT之家 10 月 24 日的报道，Meta 已暂停分享功能，研究团队复查的 40 个页面也已无法访问。但页面关停与历史记录消失是两回事。对做 AI 产品的程序员来说，这起事件值得看的是：分享链接的安全边界，可能在生成网址时就已经出了问题。

没人破解链接，聊天记录为什么还能被找到

Muse 会根据用户分享的对话标题生成网页地址，并将页面部署在 cf.metaaiusercontent.com 域名下。关键在于，对话标题进入了子域名。

当用户或接收者打开页面时，访问过程涉及域名解析，相关主机名可能被被动 DNS（Passive DNS）服务记录。这类服务保存历史 DNS 观测数据，研究人员可以查询这些记录，重新发现分享页面对应的主机名。

这里要区分两个东西：DNS 记录涉及的是域名，不是完整的网页路径。这次问题恰好出在域名这一层，标题和分享页面的可发现性因此一起暴露。

「知道链接才能看」的前提，是链接不会通过其他渠道被批量发现。

Claroc 强调，他们没有破解随机生成的标识符，而是查询了已经留下的 DNS 历史记录。相关页面又无需登录 Meta 账号，拿到对应链接就能查看内容，于是「发现地址」直接变成了「访问对话」。

超过 6800 个主机名，能说明多大范围的问题

Claroc 通过一次查询发现了超过 6800 个分享页面的主机名，随后抽查数百个页面。部分内容涉及企业营收审查文件、小企业贷款申请、银行欺诈警报、房地产投资数据，以及员工年度休假安排。

还有一份材料，是候选人为与一家前沿 AI 实验室负责人进行机密电话沟通而准备的，其中包含内部联系人信息和会议时间。风险显然不只在聊天标题：页面可以打开时，对话正文里的业务资料和个人信息也可能被看到。

但不能把这个数字写成「6800 多份敏感聊天已经泄露」。原文给出的证据是：发现了这些主机名，抽查页面中有部分包含敏感内容。它没有给出敏感页面的总数。

调查也只覆盖特定域名模式和一种发现渠道，不能据此推算 Muse 全部分享内容的暴露规模。研究团队表示，没有证据证明页面遭到恶意利用，也无法确定是否有人在他们之前访问过。

「没有恶意利用证据」和「确认无人访问」，是两个不同的结论。

页面打不开了，为什么还不能算彻底收尾

时间线需要分开看：

• 10 月 8 日，Claroc 通过 Meta 的漏洞赏金计划提交问题。
• 10 月 18 日，Claroc 发布研究报告。
• Meta 随后表示已暂停分享功能，调查问题并评估如何调整链接的可发现性。
• 10 月 20 日，Claroc 更新报告，复查此前无需登录即可打开的 40 个页面，发现均已无法访问，相关主机名返回错误。

这些结果能证明，复查样本的访问状态发生了变化。但原文没有交代 Meta 最终采用了什么修复方案，也没有给出所有历史链接的验证结果。

更棘手的是，已经进入被动 DNS 历史数据库的域名及其对话标题仍然存在。关闭页面可以阻止继续读取正文，却不能自动撤回第三方数据库里的历史记录。

正文访问与标题泄露，需要分别处理。

我的判断

这起事件最有价值的提醒，是网址本身也可能携带敏感信息。即便正文有一天被删除，写进域名的标题仍可能留下痕迹。

对需要公开分享的内容，免登录链接有使用便利；对企业文件、贷款资料、会议准备材料，仅靠「别人不知道地址」就显得脆弱。使用不含业务语义的随机标识，可以减少标题直接进入域名的风险，但仍要考虑链接被转发或记录后的访问权限。随机地址不能替代身份校验。

同时，原文没有提供不同链接设计的对照数据，也没说明 Muse 是否曾向用户明确提示分享范围，因此不能据此断言所有免登录分享都不安全，或把责任全部归给用户。

标题中的「Meta 已修复」也需要收窄理解：目前有暂停功能和 40 个页面失效的证据，尚不足以证明历史痕迹已清除、所有链接已验证，或后续方案已经完成。

能拿来做什么

• 检查 AI 对话分享功能生成的 URL，尤其是子域名是否包含对话标题、客户名称或项目名称，避免把这些内容直接写进域名。
• 为分享页明确访问规则。涉及内部资料时，考虑登录校验和接收者权限，并让用户在分享前看清谁能访问。
• 排查历史分享时，分别验证正文是否还能打开、域名是否仍暴露标题，不要只凭页面返回错误就结束检查。
• 在日常 AI 编程协作中，分享含企业文件或会议材料的对话前，先确认链接是否无需登录即可访问，再决定是否需要删去敏感内容。