Grok Build 泄露 94.7%：3.7 万应用默认公开与自查清单

2 hours ago AI笔记

安全公司 Claroc 在 11 月 10 日发布 GhostShares 2 报告，称 SpaceXSI 旗下 AI 应用生成工具 Grok Build 存在默认公开分享缺陷：37,571 个仍在线的应用中有 35,578 个无需登录即可访问，占比 94.7%，其中约 650 至 800 个含企业内部或个人信息。一句话结论：这次暴露不需要任何漏洞利用，三个产品默认值叠在一起就足以让 3.5 万个内部工具变成公网可读页面，排查成本极低但处置窗口只有几天。

规模：43601 个地址里 94.7% 对陌生人敞开

Claroc 的做法很克制。他们用子域名枚举收集到 43,601 个 grok.me 主机名，实际尝试了 43,551 个，只从公网加载每个应用的第一页一次，不登录、不提交表单、不使用任何看到的凭据，唯独对自己搭的两个测试应用测了写入权限。整个过程在 11 月 8 日至 9 日之间完成。

指标 数值 说明
枚举到的 grok.me 应用地址 43,601 个 报告中也给出 43,551 这个实际尝试数
测试时仍在线 37,571 个 扣除了已下架与失效地址
无需登录即可打开 35,578 个 占比 94.7%
返回 401 未授权 1,993 个 占比 5.3%，即设了仅自己或受邀访问
含敏感或内部材料 约十分之一 经 AI 辅助分类加人工抽样复核
含私人数据 650 至 800 个 约占公开应用的 2%，严重度评级为高危
SpaceXSI 与 X 员工自建且公开 24 个 SpaceXSI 事后自行下架
另可识别机构 30 家 其中 26 家员工超千人，6 家为财富世界 500 强

多数公开应用是游戏、计算器和落地页这类无害产物。真正需要处理的是那 650 到 800 个，Claroc 手里有他们确认过的实例。

泄露了什么：病历、员工名册和明文密码

人工核验过的案例里，最刺眼的是一份重症监护简报，包含患者的化验值和呼吸机状态。另一份是一家医院集团超过 3500 名员工的名单。还有消防部门的实时排班板，上面写着姓名和警号。运输公司一份招聘名单列了一千多名司机的个人邮箱。

最直接的技术性损失来自一个承包商的工时应用。它的前端脚本里写了 18 个明文密码账户，其中包含管理员账户。任何访问者下载这段 JavaScript 就等于拿到账号密码。

SpaceXSI 自身的 24 个应用内容同样敏感。一份新企业销售人员的入职计划，一张覆盖 594 个重点客户的销售区域分布图，8 份 X 平台广告提案，其中一份面向美国联邦机构并标注为机密，还有 4 个仍在使用的广告客户看板。

为什么四个随机词挡不住：秘密放在了域名前面

Grok Build 给每个发布的应用分配独立子域名，形如 四个随机词 加上 grok.me。四个单词听起来足够随机，但 Claroc 算过，随机性上限约 38 比特，这个量级本身不算弱，问题出在位置。

关键在于这些随机词位于域名前，而不是域名之后的路径里。域名一旦被解析，就会触发一次 DNS 查询。被动 DNS 服务把这类查询收集进可公开检索的数据库，任何人拿到工具就能按模式批量搜。也就是说，同事第一次点开分享链接的那一刻，这个地址就进了别人的可搜索清单。

Claroc 用同样的方式对比过其它产品的分享机制：Claude 的发布产物、ChatGPT 与 Gemini 的分享聊天把秘密放在页面路径里，不会以这种方式进入 DNS 记录。Claroc 还指出 Lovable、Replit、Bolt 与 ChatGPT 这类应用生成器同样给每个应用独立主机名，问题不专属于 Grok。

这已经是 Claroc 一个月内第二次发现同类暴露，上一次是 Meta Muse 的聊天记录可以用相同方式找到。站内此前记录过 Meta Muse Ember 的定价与基准，那条稿子讲的是模型本身，这次讲的是它的另一面。

默认共享加上缺登录，等于没有访问控制

第二个默认值来自发布对话框。Claroc 在自己的付费测试账号里看到三个选项，其中「知道链接的任何人」是预先选中的，排在「受邀用户」和「仅自己可见」之前。35,578 个应用所有者沿着这条路径完成了发布。

第三个默认值是应用本身带数据库却没有登录。Claroc 在两个自建测试应用上发现，匿名访客可以往公开的联系人列表里添加记录，而用「Continue with Google」登录时，Grok 生成的认证代码会先把新用户加进团队，再去检查成员资格。任何外部 Google 账号都能读、改、删团队里的全部记录。Claroc 声明没有测试不属于自己的应用的写权限，这一点需要如实标注。

漏洞成因是产品默认配置，而非加密强度不足。这类问题的修复不需要等待被利用，只需要改掉默认值。

SpaceXSI 的回应与留下的空白

SpaceXSI 没有直接回复 Claroc 的报告，但回答了记者提问。其代表说，Grok Build 应用在创建者主动分享之前保持私密，发布需要多个操作步骤，员工账户默认设置为仅自己可见。Claroc 反驳了这一表述：它同意没有构建者点击发布就不会有应用上线，但发布之后的访问步骤本身就指向「知道链接的任何人」，并且在 35,578 个案例中确实发生了。

Claroc 在 11 月 8 日至 9 日向 SpaceXSI 报告问题，之后 SpaceXSI 下架了自家那 24 个暴露应用，约两天内完成。其它用户创建的应用没有被同等处理，Claroc 表示正在自行通知受影响机构。Claroc 与 SpaceXSI 双方都没有提到普通用户的默认值会发生变化，也没有提到平台会主动通知应用所有者。

Claroc 向 SpaceXSI 提出了四条修复建议。把「仅自己可见」设为默认。当应用带有数据库却没有登录机制时向构建者告警。以及与之配套的两项访问控制修正。

团队自查清单：先找自己的应用，再谈封堵

Cloud Security Alliance 在 11 月 11 日发布研究说明，把这件事归入 AI 应用生成器的「默认公开」模式，并提醒读者该机构未独立验证 Claroc 的数据。安全团队可照下面几步走。

步骤 具体动作 目标
1 定位 在被动 DNS 中按模式搜索 grok.me 域名下的全部子域 找出归属于本组织的已发布应用
2 验证 用无痕窗口打开这些地址 确认外部访客是否真的能读到内容
3 取证 只测试属于自己的应用，检查前端脚本 查找明文密码、密钥与令牌
4 轮换 把脚本里发现的任何凭据视为已泄露并立即轮换 切断凭据复用带来的横向风险
5 收紧 把访问级别改为仅自己可见或受邀用户，然后确认外部访客拿到的是错误页 让默认公开不再成立
6 验证登录 用一个外部账号测试登录流程 排除登录框形同虚设的情况
7 下架 取消发布已废弃的应用 减少被动 DNS 中的资产面
8 立规 明确哪些 AI 应用生成器可用于哪类数据 把审批前置到工具准入环节

第 3 步的边界要守住。Claroc 的方法论是不登录第三方应用、不提交表单、不使用拿到的凭据，只对自己搭的两个应用测写入。团队自查同样应当遵守这条线，只动自己的东西。站内 AGENTS.md 投毒自查清单 讲的是同一类问题的另一面，那是本地配置文件被污染，这里是云端应用被公开。

还有一个常被忽略的层面。这类应用不在企业自己的域名下，也没走过变更流程，安全团队通常根本不知道它的存在。资产清单里缺这一项，问题就发现不了。xAI 此前对 Grok 模型加的 隐形水印覆盖 7 款模型 解决的是输出可追溯，和应用暴露是两个维度的事。

常见问题

这属于漏洞利用事件吗？

不属于。Claroc 明确表示没有声称发生大规模在野窃取，他们的动作是读取公开页面，只在自己搭的两个应用上测了写入权限。暴露来自默认共享设置、每应用独立 DNS 主机名，以及 Grok 生成的认证逻辑。

我的数据会因此离开公司机器吗？

会有一部分。浏览器会下载应用的前端 JavaScript，那个工时应用把 18 个员工账户的明文密码写在代码里，任何访客都会拉到这份代码。凭据一旦出现在客户端代码里，就应按已泄露处理并立即轮换。

Claude、ChatGPT 或 Gemini 的分享链接有同样问题吗？

按 Claroc 的说法没有。它们把秘密放在页面路径里而不是域名前，因此不会以被动 DNS 的方式进入可检索数据库。但需要注意的是，这个差异只针对分享链接的暴露路径，各家应用生成器的默认共享设置仍需单独确认。

小结

GhostShares 2 最值得记住的结论在于它几乎不需要技术门槛，94.7% 那个数字只是表象。构建者用聊天机器人做了一个排班表或者工时表，点发布，接受了默认，整个链条里没有任何一步是恶意的。查自己组织名下有没有暴露应用的做法并不复杂，站内 OpenAI 挖出 Linux 内核 948 个提权漏洞 讲的是需要研究人员投入的漏洞，而 GPT-6 Cyber 的越界率数据 说明对齐问题仍会留缺口。把「默认公开」当成产品默认配置来审，而不是当成偶发事故，才能在下一个同类工具上线前就把口子堵上。

相关阅读

延伸阅读

AI 自学笔记 每天更新 AI 前沿动态，订阅 RSS，或按 Ctrl/⌘+D 收藏本站，明天见。

继续读

往下这几篇值得接着看：

想快速查定义？对应的词条在这里：

Related News