Meta 的 Muse 是一个旨在执行预约和管理日历等任务的通用 AI 智能体,但其对话共享功能中的一个隐私漏洞引起了广泛关注。尽管 Meta 将该助手宣传为“从底层构建以保障隐私和安全”,但来自安全公司 Claroc 的研究人员发现,Muse 构建可共享 URL 的方式使得未经授权的第三方能够发现并访问私人对话。

文章介绍了 Meta 的 Muse 作为一个旨在进行任务管理和个人协助的通用 AI 智能体。

文中讨论了 Meta 关于 Muse 助手隐私和安全架构的营销主张。
该漏洞源于一个特定的架构选择:Muse 将对话标题直接包含在 URL 的子域名中。例如,一个链接可能显示为 `loan-application-draft-a4c9e2.cf.metaaiusercontent.com`。由于这些子域名注册在公共域名上,它们会被记录在被动 DNS 系统中——即存储历史 DNS 解析记录的数据库。研究人员能够通过单次查询枚举出 6,800 个此类链接,揭露了包括机密高管搜索笔记、内部收入审查、贷款申请和房地产业绩报告在内的敏感数据。
针对这些发现,Meta 表示已暂停共享功能,同时正在审查报告并考虑更改这些链接的发现方式。此次事件引发了关于需要深度访问用户个人账户和数据的 AI 智能体安全性的质疑。虽然当前的威胁已通过暂停该功能得到缓解,但该漏洞凸显了共享便利性与存储在子域名名称中的信息安全性之间的重大权衡,因为子域名比标准 URL 路径更容易被公共监控工具发现。
Claroc 的研究人员将这些称为“GhostShares”——即任何能找到 URL 的人都可以访问的页面,即使预期的接收者从未获得该链接。这一发现强调了 AI 开发中一个反复出现的挑战:确保诸如一键共享之类的便利功能不会无意中绕过平台承诺提供的隐私保护。在 Meta 实施更模糊的唯一标识符生成方法之前,公共发现的风险仍是平台用户的首要担忧。
此问题加剧了此前关于 Muse 的安全担忧。在其发布后不久,发现了一个零日漏洞,可能允许设备上的其他应用程序获取用户 Muse 账户的控制权。虽然 Meta 淡化了该特定漏洞的严重性,但共享链接易于被发现的特性增加了关于该助手的高级别系统访问权限是否得到了充分安全措施平衡的持续辩论。
目前,主要的发现机制是通过商业服务进行的被动 DNS 搜索。通过将对话标题从 URL 路径移动到子域名,Muse 无意中使其私人内容可被任何监控 DNS 流量的实体搜索。Meta 暂停该功能的举措表明,重新设计 URL 结构——很可能转向不包含描述性标题的长、不可猜测的字符串——是恢复用户对话隐私所必需的。
最终,这一事件提醒人们,即使 AI 智能体在设计时将隐私作为核心支柱,特定的实施细节(如 DNS 架构)仍可能创建意外的后门。对于用户来说,直接的启示是,任何通过 Muse 链接共享的内容都可能被任何能够查询公共 DNS 记录的人看到,Meta 目前正通过完全禁用该功能来应对这一风险。