Grok Build 分享子域名暴露敏感应用

AI 生成的应用，即使没有主动公开分享链接，也可能被外人找到。IT之家 11 月 11 日援引安全公司 Claroc 的发现称，Grok Build 将随机分享标识放进子域名，相关地址可被某些被动 DNS 服务收集、检索，导致数千名用户的敏感数据暴露，连开发公司 SpaceXSI 的内部资料也在其中。

这件事值得程序员关注的地方，不只是 AI 工具泄露了数据，而是一个容易误判的安全前提：链接足够随机，是否就能当作访问权限？

链接猜不到，为什么仍然会暴露

Grok Build 使用 4 个随机单词生成分享链接标识，随机性最高达到 38 比特。单看这个设计，开发者可能会把注意力放在「别人能不能猜中地址」上。

但 Claroc 报告的发现途径，并不依赖逐个猜测。

问题出在标识的位置：Grok 将它放在域名前，作为子域名的一部分，而不是放在域名后的网址路径中。DNS 负责把域名解析到对应地址；被动 DNS 服务则可以收集解析记录，并形成可检索的数据库。分享标识进入域名后，也就可能随这些记录被收集。

于是，原本需要别人转发才能拿到的分享地址，有了另一条发现路径。Claroc 把这类页面称为「GhostShares」：外人没有收到分享链接，也能自行找到并访问。

随机地址只能增加猜测难度，不能代替身份认证和访问授权。

原文拿 Gemini 作了对比，称后者将标识放在网址路径中。这能解释两种地址设计在 DNS 记录暴露方面的区别，但不能据此认定路径中的链接天然安全。地址放在哪里，与拿到地址后是否有权读取内容，是两个需要分别处理的问题。

暴露的不只是演示页面，还有仍在使用的业务应用

据 Claroc 披露，SpaceXSI 暴露的内部资料包括新员工入职计划、涉及 594 个重点客户的销售区域分布图、8 份 X 平台广告提案、4 个仍在使用的广告客户账户管理看板，以及两份 X 品牌安全操作手册。其中只有一个应用设置了密码。

「仍在使用」尤其关键。这些页面承载的已经是实际业务资料，分享功能的权限设计也就进入了企业的数据安全边界。

受影响的还包括一家医院集团、一家消防部门，以及 6 家《财富》世界 500 强企业和 26 家员工超过 1000 人的企业。Claroc 估计，约 2% 的应用包含足以评为高危或严重级别的敏感信息。

这里要分清证据层次：具体页面和资料类别，是研究人员报告的发现；约 2% 是他们的估计。报道没有给出完整样本规模、抽样方法或风险评级细节，不能直接把它理解为所有 Grok Build 应用的泄露比例。

原文也没有说明，是否已有其他人利用这些地址获取资料，以及暴露持续了多久。能够公开访问，与已经发生恶意利用，不能混为一谈。

删除 24 个应用，解决到了哪一步

Claroc 表示，他们向 SpaceXSI 和受影响企业通报了问题，部分企业迅速采取措施。SpaceXSI 则直到 Claroc 在 X 上点名马斯克和另一名公司高管后才回应，随后下架了 24 个暴露内部资料的自家应用。

但按报道描述，SpaceXSI 没有对其他用户和机构仍可公开访问的应用采取同样措施。

删除具体页面可以阻止这些页面继续提供内容，却不能证明分享机制已经修复。原文没有交代平台是否调整了链接生成方式、增加默认访问限制，或通知全部受影响用户。因此，目前能确认的是部分暴露应用被下架，不能进一步推断平台层面的风险已经消除。

我的判断

这份报道最有价值的提醒，是把「难以发现」和「有权访问」分开。AI 编程让应用更容易做出来，但只要页面装进客户资料、员工信息或账户看板，发布和分享就需要按正式业务系统处理。

子域名承载随机标识确实扩大了本次事件中的地址发现渠道。不过，把标识移到路径里，也只处理了这个渠道。与单纯隐藏链接相比，登录认证、按用户或组织授权，更直接地回答了「谁可以看」的问题。

密码保护可以成为一道门槛，但原文只说一个应用设置了密码，没有说明密码机制及其效果，不能把「加密码」当作此次事件已经验证有效的完整方案。

这是一份漏洞发现和处置情况的报道，没有提供不同方案的对照数据。可以据此识别设计风险，不能替任何一种替代方案背书。

能拿来做什么

• 检查团队用 AI 工具生成并分享的应用，优先查看包含员工信息、客户资料和业务看板的页面，确认未登录用户实际能读到什么。
• 给前端或 Node 应用设计分享功能时，分别确定链接如何生成、谁有权访问；敏感内容应由服务端校验权限，不能只依赖前端隐藏入口或随机地址。
• 发现页面公开暴露后，先撤销访问或下架页面，再检查同类应用和分享机制；不要把删除已知页面当作整个问题已经解决。