事件概述

Meta 近期推出的 AI 助手 Muse 在分享功能上出现严重隐私缺陷。用户生成的对话分享链接容易被陌生人枚举发现，导致个人及商业机密泄露。安全公司 Claroc 发布报告称，他们成功枚举出约 6,800 个 Muse 用户创建的分享链接，并从中打开了数百个包含敏感信息的对话。

面对该问题，Meta 已紧急暂停了 Muse 的分享功能。据称，漏洞根源在于一项设计决策：分享链接的标题被直接写入 URL，且通过一次 DNS 查询即可暴露相关记录（原文提及域名前缀为 cf.metaaiusercon...）。这种可实现批量发现的结构，使得原本应为私有的对话处于公开可访问状态。

技术机理简析

从已有信息看，该漏洞结合了两种风险：

  • URL 可预测性：将对话标题或易猜解标识放入链接路径，便于人工或脚本构造。
  • DNS 枚举可行性：分享域名下的子域名或记录可通过 DNS 查询被遍历，攻击者无需破解权限即可收集大量有效链接。

DNS 枚举基础

DNS 作为互联网基础协议，其查询机制本用于解析域名到 IP。但当企业为用户生成大量子域名且命名规律明显时，攻击者可通过字典爆破、证书透明化日志或区域传送配置不当等方式收集记录。Muse 案例警示：标题写进 URL 且分享域名固定，意味着只需针对该域发起查询即可获取大量有效分享节点。

对读者的意义 / 技术解读

对于运维、SRE 与平台开发者而言，此事件提供了关于“分享型功能”安全设计的反面教材。在设计任何用户内容对外分享机制时，应注意：

  1. 避免使用具有语义或可枚举规律的字符串作为公开 URL 标识，应生成高熵随机令牌（如 UUIDv4 或加密哈希）。
  2. 若使用独立子域名或特定 DNS 记录承载分享服务，需评估 DNS 区域传送、暴力枚举或证书透明日志带来的暴露面；必要时限制解析记录公开性，或采用非标准域名后缀增加发现成本。
  3. 敏感内容分享应默认携带访问控制（如一次性令牌、有效期、密码），而非依赖链接隐蔽性。
  4. 在微服务与 AI 平台集成中，前端生成分享链接的逻辑必须经过安全评审，防止将内部标题、用户 ID 等直接拼接至公网可触达地址。

从网络诊断视角，运维人员可利用 DNS 查询与子域名枚举手段，定期审计自身业务域名的暴露面；HTTP(S) 测速与路由追踪同样可用于发现异常访问路径。更多事件背景见 开源中国报道。

“一次 DNS 查询全暴露”警示我们：任何写入基础设施的配置，都可能成为攻击入口。

总之，AI 能力快速迭代不应以牺牲基本隐私边界为代价。相关团队需将安全测试左移，避免重蹈 Muse 覆辙。