Meta 暂停 Muse 分享功能：6800 个 GhostShares 藏在 DNS 记录里

分享出去的 AI 对话，被 DNS「看」到了

10 月 20 日，Meta 暂停了 Muse AI 的对话分享功能。导火索是安全公司 Claroc 的一份报告：研究员通过被动 DNS（passive DNS）记录，一次查询就枚举出了 6800 多个 Muse 用户的分享链接，其中不少包含本不该公开的商业和个人信息。Ars Technica 率先报道，The Verge 拿到了 Meta 发言人的确认声明。

先说清楚影响范围：出问题的是用户主动选择分享的对话页面，不是所有 Muse 私聊。分享功能会给对话生成一个公开链接——设计上是「知道链接的人才能看」。但 Claroc 发现，这个「知道链接」的假设从一开始就不成立。

错在把标题写进了域名里

技术细节值得每个做分享功能的开发者细读。Muse 把分享内容放在 cf.metaaiusercontent.com 域名下，每个分享链接的主机名由「可读的对话标题 + 随机 ID」拼接而成，比如：

home-sale-budget-9f21c8a3.cf.metaaiusercontent.com
loan-application-draft-a4c9e2.cf.metaaiusercontent.com

随机 ID 本来让暴力猜测变得困难。但问题在于：DNS 查询记录是公开可查的。被动 DNS 服务会记录它观察到的域名解析请求——包括完整的主机名。也就是说，当有人（包括分享者自己、接收者、任何中间网络设备）解析过这个链接，完整的主机名（含标题和随机 ID）就被写进了公共 DNS 历史。Claroc 只需要一次被动 DNS 查询，就拿回了几千条「标题目录」，像翻书的目录页一样按标题列好。

Claroc 把这类「可被发现、但主人没想公开」的页面命名为 GhostShares（幽灵分享）。研究员打开了其中几百个页面核实，发现了：一家营销公司的 CEO 级营收复盘、一份小企业主的贷款申请（含申请金额）、一位房产投资人的完整财务报告（含物业地址和精确收益数字）、一份带部分账号的银行欺诈告警、某公司全年的员工休假表，还有一份为与某前沿 AI 实验室秘密高管寻访通话准备的候选人笔记（含内部联系人和会议时间）。

值得强调的诚实注脚（Claroc 自己写的）：6800 是去重后的分享主机名数量，不等于 6800 个敏感对话——研究员只打开了几百个核实，大部分页面内容普通；也没有证据表明这些信息被恶意利用过；涉及的个人和企业信息已被隐去。

robots.txt 拦不住 DNS

这个案例最精彩的技术教训是：Muse 的 robots.txt 明明要求搜索和 AI 爬虫不要碰分享路径——但这完全没用。因为 robots.txt 管的是爬虫，DNS 记录管的是解析历史，两者是不同层面的东西。爬虫不来，不代表解析记录不存在。

这也不是孤例。之前 ChatGPT 的分享对话就被搜索引擎索引曝光过（本站发过的同类题材）；Grok 的分享聊天也出过类似问题。AI 产品的分享功能正在重复 Web 2.0 时代踩过的坑，只是这一次，用户喂给 agent 的是更敏感、更非结构化的数据：财务记录、人事安排、商业机密。

Claroc 还发现了第二条发现路径：urlscan.io 上有 75+ 个 Muse 分享页面的存档扫描。也就是说，即便 DNS 记录被清理，第三方存档里还留着副本。Meta 暂停功能后，研究员复查 40 个之前能打开的链接已全部失效——但 DNS 历史里的标题删不掉。

扎克伯格一个月前的承诺

颇具讽刺意味的是，就在一个月前，扎克伯格还说 Muse 是「从零开始为隐私和安全构建的」（built from the ground up for privacy and security）。Meta 发言人 Tracy Clayton 给 The Verge 的声明很克制：「我们已暂停该功能，正在审查这份报告，并考虑如何调整这些链接的可发现性。」同时 Meta 表示已开放 Muse 的 bug bounty，欢迎研究员提交更多场景。

Claroc 的报告 10 月 8 日就通过 bug bounty 交给了 Meta（10 月 7–8 日验证的页面）。从提交到暂停用了 12 天——不算慢，但 6800 个链接在 DNS 历史里躺了更久。

vibe 项目做分享功能时的 5 条铁律

分享链接是 vibe 项目的标配功能（分享一个 AI 生成的页面、报表、对话），GhostShares 给所有独立开发者上了一课：

• 1. 永远不要把可读信息放进主机名或 URL 路径的可枚举部分。标题、用户名、项目名都不行。用纯随机、足够长的 token（如 128 位），且 token 只出现在 path 或 query 里，不出现在子域名里。
• 2. 「不可猜测」不等于「不可发现」。威胁建模时要问：这个链接会经过哪些会被记录的系统？DNS、CDN 日志、浏览器历史同步、urlscan 这类存档服务，都是「发现面」。
• 3. robots.txt 不是访问控制。它只是对善意爬虫的请求。真正的保护靠鉴权：分享链接要么需要登录态，要么做成一次性/阅后即焚，要么至少让创建者能随时吊销。
• 4. 给分享链接加过期和吊销。Muse 的教训之一是链接一旦出去就收不回。让分享默认 7 天过期、创建者一键吊销，能大幅缩小暴露窗口。
• 5. 在分享前做一次「敏感信息提示」。当用户点击分享、而对话里含疑似敏感内容（金额、账号、身份证号模式）时，弹一次确认。这是从产品层面补对齐的课：用户往往意识不到「分享」等于「发布」。

Claroc 给企业的建议更直接：把「员工创建 AI 分享链接」当作一次数据外发来监控；在管控不足的环境下，直接在代理或 DNS 层屏蔽 muse.ai 和 metaaiusercontent.com。对个人用户，结论更简单：凡是进过 AI 对话的敏感信息，默认它已经离开了你的电脑——分享链接只是让它离开得更远了一点。

被动 DNS：互联网的「通话记录」

要理解 GhostShares，得先理解被动 DNS 是什么。正常 DNS 是「问路」：你输入一个域名，DNS 服务器告诉你它对应的 IP。被动 DNS 是「记账」：一些安全公司和研究机构在全球部署传感器，默默记录它们观察到的每一次「问路」——谁在什么时候问了哪个域名。

这些记录本来的用途是正面的：追踪僵尸网络、发现钓鱼域名、做威胁情报。但 Claroc 这次展示了它的另一面：只要你的「秘密」曾经以域名的形式被解析过，它就进了公共账本。Muse 的分享链接恰恰是这种形态：标题写进子域名 → 用户/接收者/中间设备解析 → 完整主机名被传感器记下 → 任何人用一次查询就能翻出来。

关键点在于「被动」二字：攻击者不需要扫描、不需要猜测、不需要入侵 Muse 的服务器，只需要查询历史。Claroc 描述为「一次被动 DNS 查询带回几千条，像目录一样按标题列好」。这就是为什么随机 ID 救不了它——随机 ID 防的是「猜」，防不了「记」。

给开发者的启示很直接：凡是会出现在 DNS 查询里的字符串，默认都是公开的。子域名、甚至某些场景下的 SNI（TLS 握手时的明文域名），都不能承载秘密。秘密只应该出现在加密通道内的 path/query/body 里。

Claroc 是怎么查的：方法与边界

Claroc 的调查手法值得细说，因为它定义了「负责任披露」的样子：

• 枚举：用被动 DNS 数据源按 *.cf.metaaiusercontent.com 模式检索，去掉通配符扫描的噪音后，得到 6800+ 分享主机名；
• 抽样验证：只打开了几百个页面确认内容，没有批量爬取——「能证明问题存在」和「把所有人都看光」之间，他们选了前者；
• 止损线：遇到一个要求密码的页面就停手；不联系受影响的个人/企业（无法确认对方是否真想公开）；报告里隐去所有可识别信息；
• 披露路径：10 月 8 日走 Meta 的 bug bounty 提交，而不是先发博客吃流量；10 月 20 日 Meta 暂停功能后才公开报告。

这个流程对安全研究员是范本，对产品方也是提醒：bug bounty 不是摆设。Meta 的 bounty 通道 12 天内推动了一个功能级下线——说明通道是通的。你的 vibe 项目如果开始有真实用户，也该放一个 security.txt + 漏洞报告邮箱。Claroc 这类研究员，可能是你免费的最强 QA。

完整时间线

• 更早：Muse 上线分享功能（Meta 上月发布 Muse 时引入）；
• 10 月 7–8 日：Claroc 验证页面，确认可通过被动 DNS 枚举并打开；
• 10 月 8 日：Claroc 经 Meta bug bounty 提交报告；
• 10 月 20 日：Claroc 公开报告；Meta 向 The Verge 确认「已暂停该功能」；研究员复查 40 个历史链接，全部失效；
• 10 月 21 日：Ars Technica、Cyber Security News、TechBriefly、Digit 等多家跟进报道。

从提交到暂停 12 天。横向对比：2023 年三星员工把代码粘进 ChatGPT、三星 3 周后下禁令；这次 Meta 的反应速度算快的。但 DNS 历史里的标题是删不掉的——响应的快慢，追不回已经进账本的数据。

历史对照：AI 分享链接的三次翻车

• ChatGPT（2023–2024）：用户分享的对话被搜索引擎索引，直接 Google 可搜。病因：分享页允许爬虫索引。Meta 这次吸取了教训，robots.txt 写了 disallow——但病根换了地方；
• Grok（2025–2026）：分享聊天同样出现超范围可见。病因类似：链接可发现性设计不足；
• Muse（2026-10）：robots.txt 防住了爬虫，没防住 DNS。病因升级：从「应用层可发现」变成「基础设施层可发现」。

三次翻车的共同病根：产品经理把「分享」理解成了「发个链接」，而安全视角下「分享 = 发布」。每次都是用户以为的「点对点」和实际的「全网可发现」之间存在落差。vibe 项目做分享功能时，第一行需求文档就该写：这个链接的「可发现半径」是多大？

企业安全团队的应对 playbook

Claroc 给企业的建议可以扩展成一份 playbook：

• 1. 先盘点：员工在用哪些 AI 产品的分享功能？Muse、ChatGPT、Claude、Grok……列清单。很多人不知道自己公司的销售已经在用 AI 分享报价单了。
• 2. 定分级：什么能分享（公开资料、脱敏 demo），什么绝不能（客户数据、财务、HR 信息）。写进员工手册，一页纸就行。
• 3. 技术管控：在代理/DNS 层对 muse.ai、metaaiusercontent.com 等分享域名做策略——要么阻断，要么审计日志。Claroc 的原话是「把创建分享链接当作一次数据外发来监控」。
• 4. 演练一次：用被动 DNS 查一下自家域名有没有「不该出现的子域名」。很多公司第一次查，都会被结果吓一跳。

对个人用户，playbook 只有一条：分享前，假设链接会被陌生人打开。如果这个假设让你不适，就别分享——或者先删掉敏感内容再分享。

分享链接威胁建模：一张表自查

把 GhostShares 的教训抽象成一张威胁建模表，下次设计分享功能时逐行过一遍：

• 链接里有什么可读信息？标题/用户名/项目名 → 全部移出，换成纯随机 token；
• token 有多长？至少 128 位随机，来自密码学安全的随机源，不要用自增 ID、时间戳、MD5(标题)；
• 链接会经过哪些「记账」系统？DNS（子域名！）、CDN 日志、邮件网关（如果分享走邮件）、urlscan 等存档站、浏览器历史同步——逐个问「它记下来怎么办」；
• 默认可发现吗？分享页的 meta 标签有没有 noindex？robots.txt 只是起点，还要考虑 DNS 层和存档站；
• 能吊销吗？创建者能不能一键让链接失效？有没有默认过期时间？Meta 这次是整个功能暂停——说明它连「单个吊销」的粒度都没准备好；
• 访问要鉴权吗？「有链接就能看」是最弱的一档；至少给敏感分享加上「需登录」或「阅后即焚」选项；
• 用户知道自己在「发布」吗？UI 上有没有明确告知「此链接可被转发，内容将公开可访问」？Muse 的用户显然没意识到标题会进 DNS。

这张表贴在需求文档旁边，GhostShares 式的事故至少能防住 80%。剩下的 20% 是未知攻击面——那是 bug bounty 和外部研究员的活，给他们留好通道（security.txt），比什么都重要。

再补一个很多人忽略的细节：Claroc 发现 Muse 的分享页是「先返回标题、再用 JavaScript 加载对话内容」。这意味着用简单的 curl 抓取只能看到标题，看不到正文——但研究员用的是「普通浏览器会话」，内容照样加载。这对防御者的启示是：不要指望「前端渲染」能当访问控制。真正敏感的内容，必须在服务端做鉴权，而不是靠「JS 动态加载所以爬虫看不到」这种幻觉。GhostShares 的标题泄露已经够糟，但如果鉴权再弱一档，泄露的就是全文。

一句话收尾：分享链接的本质是「把访问能力编码进一个字符串」，而字符串会流经 DNS、日志、存档、聊天记录——每一个经手者都是潜在的「公开者」。设计分享功能时，先假设这个字符串明天就会出现在 GitHub 公开仓库里，再倒推你能往里面放什么、不能放什么。通过这道思想实验的设计，才配叫「分享」。

名词解释

被动 DNS（passive DNS）：记录「谁在何时解析了哪个域名」的历史数据库。 originally 为威胁情报而建，这次成了枚举分享链接的钥匙。记住：它记的是「解析行为」，不是「网页内容」——但 Muse 把标题写进域名，等于把内容摘要亲手送进了行为记录。

SNI（Server Name Indication）：TLS 握手时明文传输的域名信息。即使网站全站 HTTPS，SNI 里的域名仍可能被中间设备看到。原理和这次事件相通：域名层面的信息，默认都是公开的。

urlscan.io：公开的网站扫描存档服务，任何人提交 URL 扫描，结果公开可查。Claroc 在上面找到了 75+ 个 Muse 分享页面的存档——说明「分享链接被提交扫描」本身就是一条泄露路径。你的用户里，一定有人手贱把链接贴进过这类工具。

特别提醒：vibe 项目的「分享 AI 生成内容」是重灾区

为什么这条新闻要发在 VibeFix？因为「分享 AI 生成的东西」正是 vibe 项目的标配功能：分享 agent 生成的报表、分享一次 AI 对话、分享一个 AI 做的页面。v0、Lovable、Bolt 这类工具早就把「一键分享部署链接」做成了核心卖点。而 GhostShares 证明：分享功能的安全水位，决定了整个产品的安全水位。

vibe 场景有三个放大风险的因素。第一，内容更敏感：用户让 agent 处理的往往是工作文档、数据报表、代码——比闲聊敏感一个数量级。Muse 泄露的贷款申请、财务报告就是例证。第二，用户更不懂：vibe 产品的用户很多是非技术人员，他们对「分享链接」的理解就是「发给朋友看看」，根本想不到 DNS、存档站这些概念。第三，开发者更容易偷懒：分享功能经常是「让 agent 顺手写一个」，agent 生成的分享链接大概率是「标题拼进 URL + 自增 ID」——正是 GhostShares 的翻版。

所以，如果你正在用 AI 给自己的产品写分享功能，现在就去检查它生成的链接格式：URL 里有没有可读标题？ID 是随机的还是自增的？有没有过期时间？这三问，5 分钟就能验证。而 Meta 用 6800 个泄露链接告诉我们：不验证的代价，是整个功能下线。

最后留一个开放问题：Meta 选择「暂停整个功能」而不是「修 URL 方案」，说明什么？VectorWire 的分析认为，这暗示修复不只是换个 URL 格式那么简单——可能涉及分享架构的重做（鉴权体系、历史链接的迁移、DNS 历史的不可清除性）。对 vibe 团队的启示是：分享功能的第一版架构就要按「可吊销、可过期、可审计」来设计，事后改，成本是重写级的。GhostShares 付过的学费，你不用再付一遍。

GhostShares 泄露链路示意图：分享链接 → 子域名 → 被动 DNS → 6800+ 可枚举