Grok Build 公开访问应用排查：分享链接可被被动 DNS 检索，内部资料暴露事件梳理
安全公司 Claroc 披露，SpaceXSI（原 xAI，与 X 同属马斯克体系）旗下 AI 应用构建工具 Grok Build 发布到 grok.me 的大量应用无需登录即可打开，35,578 个可访问应用中包含 SpaceXSI 与 X 员工构建的 24 个内部应用，涉及销售入职计划、594 个客户的销售区域地图、广告提案与活动看板等内部资料，另有医院名册、患者简报、员工工时表等敏感个人与业务数据被发现。问题的直接成因是：应用链接以子域名形式承载，随机标识会被被动 DNS 服务收录进可检索数据库，而发布面板默认选中 "知道链接即可访问"，内部应用没有被默认加上组织登录或成员校验。Claroc 在未登录、未提交表单、未测试任何凭据的前提下完成外部观察，所有写入验证只在自己搭建的测试应用上进行；目前没有证据表明发现的明文密码等凭据已被验证可用或被实际利用。事件披露后，SpaceXSI 下架了自家员工构建的 24 个应用，其他用户和机构仍在线的应用尚未由平台统一处置，Claroc 已开始自行通知受影响组织。
一、事件基本情况
| 项目 | 情况 |
|---|---|
| 涉及工具 | Grok Build，SpaceXSI 旗下 Grok 助手的应用构建模式，聊天描述即可生成应用并发布到 grok.me |
| 发现方 | 安全公司 Claroc（研究员 Asaf Aprozper），研究结果经 Ars Technica 报道并发布官方博客 |
| 发现时间 | 2026 年 11 月 8 日开始排查，11 月 10 日发布研究博客 |
| 排查方式 | 公开网络、未登录、隐身窗口访问；未提交表单、未调用服务端函数、未使用所见密码或密钥 |
| 暴露形态 | 已发布的 grok.me 应用对任何找到链接的人开放页面与数据 |
| 处置现状 | SpaceXSI 下架了 24 个自家员工构建的应用；其他用户与机构的开放应用尚未由平台统一处理 |
二、暴露规模与数据分层
1. 应用数量口径（Claroc 统计）
| 层级 | 数量 | 说明 |
|---|---|---|
| 子域名发现清单 | 43,601 个 grok.me 名称 | 通过常见子域名发现技术列出 |
| 测试时仍在线 | 37,571 个 | 研究发起访问时仍有响应的应用 |
| 无需登录即可打开 | 35,578 个，占 94.7% | 仅 5.3% 返回 401 未授权错误 |
| 人工确认含私密数据 | 150 个 | 模型初筛后人工逐条阅读确认 |
| 估算含私密数据总量 | 约 650–800 个 | 模型对照随机抽样后的估计区间，非确数 |
- 多数开放应用是游戏、落地页、计算器等普通页面；约十分之一含敏感材料、内部业务数据或个人数据，估算约 2% 达到高危或严重级别。
- "35,578 个可打开应用" 不等于 "35,578 个泄露敏感数据的应用"，敏感数据数量以人工确认 150 个和估算区间 650–800 个为准。
2. 可识别归属的外部组织
- 除 SpaceXSI 与 X 外，可识别归属的组织共 30 家：26 家员工规模超 1000 人，其中 6 家为财富 500 强企业。
- 地域：18 家位于美国，12 家分布在其他 11 个国家。
- 行业分布：建筑与地产 7 家，能源与公用事业 5 家，科技与 IT 4 家，医疗与医疗器械 3 家，交通与汽车 3 家，旅游、酒店与餐饮 3 家，国防 2 家，制造与广告各 2 家，汽车金融 1 家。
- Claroc 在公开博客中未点名这些外部机构。
三、SpaceXSI 与 X 自家暴露的 24 个应用
| 类别 | 暴露内容 |
|---|---|
| 销售入职计划 | 新企业销售员工的机密入职方案：首周需接入的系统、内部系统地址、销售工具、19 个内部聊天频道、需对接的同事与 30 天计划 |
| 销售区域地图 | 594 个战略客户的区域分布与销售管线 |
| 广告提案 | 8 份 X 广告提案、媒体计划与提案书，含预算档位；其中一份面向美国联邦机构并标注机密 |
| 广告账户看板 | 4 个在线广告客户账户看板，含投放花费；其中一个追踪 160 万美元销售目标进度 |
| 活动报告 | 7 份面向巴西、日本、韩国、泰国广告主的活动报告，多份标注机密或内部使用 |
| 内部手册 | 2 份 X 品牌安全操作手册，标注为内部销售枢纽 |
- 这批应用中只有 1 个流媒体广告测量研究档案要求输入密码，其余均未设置访问限制。
四、其他人工确认的敏感案例
- 医院集团员工活动应用：可检索 3500 多名员工的名册。
- 单一 ICU 患者简报：包含化验结果、影像与呼吸机状态。
- 邮轮厨房检查清单：列出船员全名与员工编号。
- 消防部门实时排班板：显示消防员姓名、警号与值班时长。
- 货运公司驾驶员招募名单：千余人的法定姓名与个人邮箱。
- 承包商员工工时表：前端脚本中包含 18 个账号的明文密码，含管理员账号。
需要注意：上述明文密码案例仅被发现存在于可下载脚本中，研究方未尝试登录验证，不能据此认定这些凭据仍然有效或已被利用。
五、问题出在哪：链接机制与默认设置
1. 子域名链接被被动 DNS 收录
- Grok Build 给每个发布应用分配独立主机名，格式为 <名称>.grok.me，标识通常由 4 个随机单词组成，随机性最高约 38 比特。
- 标识放在域名之前的子域名位置，而不是域名之后的网址路径。目标用户首次访问时，解析该子域名会触发 DNS 查询；被动 DNS 服务收集这些查询记录后，形成可按模式检索的商业数据库。
- 也就是说，标识虽然难以猜测，但不需要被猜中：链接第一次被正常使用，名称就可能进入公开可检索的 DNS 数据集。
- 作为对照，研究方提到 ChatGPT 发布的应用虽也使用独立主机名，但默认设为 "仅自己"；路径形式的分享链接同样不私密，仍可能被搜索引擎索引或链接扫描器抓取。
2. 访问权限默认偏向公开
- Claroc 使用的付费账号中，发布面板提供三档：知道链接即可访问、受邀用户、仅自己；默认选中的是 "知道链接即可访问"。
- 平台本身具备 "仅自己" 设置：切换后陌生人访问页面和数据接口都会返回 401；下架应用后地址几秒内即可离线。问题在于该选项不是默认值，发布前也没有明确提示构建者收紧权限。
- 团队应用的登录校验存在缺陷（仅在 Claroc 自建测试应用上验证）：Grok 自动接入 Google 登录，但代码先把登录者加入团队、再校验是否在名单内，校验恒通过；一个未受邀的 Google 账号可以查看全部客户记录、修改记录并删除记录。
3. 流程层面的放大因素
- AI 应用在聊天窗口内几分钟即可发布，不需要提交 IT 申请或安装受控系统，销售地图、排班表、午餐投票共用同一个发布按钮。
- 应用会随后续提示不断漂移：昨天只是无害页面，下一轮提示加入表格、登录方式或分享链接后，今天可能已经存放客户记录。
六、通报时间线与双方口径
| 时间 | 进展 |
|---|---|
| 11 月 8 日 | Claroc 按 security.txt 地址向 SpaceXSI 报告，附应用数量、两个测试应用与四项修复建议，提议私下共享完整地址清单；同时告知入职计划与联邦机构广告提案两个自家开放应用 |
| 11 月 9 日 | 补充报告其余 22 个 SpaceXSI/X 员工应用及 150 个人工确认的暴露案例 |
| 11 月 10 日 | SpaceXSI 回答记者提问；报告后下架了 24 个员工构建的应用，但未对其他用户和机构的开放应用采取同样措施 |
| 11 月 10 日起 | 因平台未表示会联系应用所有者，Claroc 开始自行通知受影响组织；发稿前已邮件通知 3 家，其余通知在进行中 |
SpaceXSI 口径：应用在创建者主动选择分享前为私有；发布需要多步操作 —— 点击发布、选择地址、再次发布、在 "仅自己" 与 "知道链接即可访问" 间选择、接受法律声明并最终确认；员工账号默认 "仅自己"，公开需要主动切换，步骤多于 Lovable 等同类工具。
Claroc 回应：认可不点发布就不会公开，但认为访问步骤的默认选项已经是 "所有人可见"，路径上多几次点击并不能保护数据；员工账号默认仅自己的设置，也没有挡住自家 24 个开放应用。
Claroc 提出的四项修复建议
- 共享应用放在同一主机下的难猜路径中，让链接不成为独立 DNS 名称。
- 增加 "仅本组织成员" 选项，按企业邮箱域名限制访问。
- 把 "仅自己" 设为默认，并在上线前明确展示谁可以打开应用。
- 发布时检测 "有数据库却无登录" 的情况并告警；描述团队场景时直接生成邀请名单。
七、用户与企业侧自查清单
- 摸清工具使用范围：盘点员工在用的 AI 应用构建器，包括 Grok、Lovable、Replit、v0、Bolt、Base44、Google AI Studio 等；这类工具通常无需 IT 部署和企业账号即可使用。
- 检索自有应用：通过被动 DNS 检索各构建器域名，在隐身窗口中逐个打开自查。
- 核对访问设置：存放内部信息的应用应设为 "受邀用户" 或 "仅自己"，陌生人访问应看到错误页面。
- 外部账号实测登录：用非公司账号尝试登录，若能进入，说明应用缺少成员名单校验。
- 检查前端脚本：浏览器会下载应用加载的脚本，需排查其中是否含姓名、邮箱、密码等敏感信息；无人认领的应用及时下架，下架可让 grok.me 应用立即离线。
- 凭据处置顺序：若发现脚本或历史记录中存在密码、密钥，先轮换相关凭据，再清理当前页面与历史副本；仅删除当前文件不足以消除历史版本和副本中的记录。
【常见问题】
问题 1：Grok Build 这次暴露的是什么，和代码仓库被上传是一回事吗？
回答 1：这次暴露的是 Grok Build 发布到 grok.me 的已生成应用：内部资料、客户记录和个人数据通过公开可访问的应用页面呈现，链接可被被动 DNS 检索到。它与 AI 编程工具静默上传 Git 仓库属于不同性质的问题，本事件不涉及仓库历史被批量上传的结论；具体暴露范围以 Claroc 研究和平台后续说明为准。
问题 2：Grok Build 有多少应用被公开打开，其中多少含敏感资料？
回答 2：Claroc 列出 43,601 个 grok.me 子域名，测试时 37,571 个在线，其中 35,578 个（94.7%）无需登录即可打开；人工确认含私密数据的有 150 个，模型抽样估算总量约 650–800 个。可打开应用数不等于敏感数据应用数，敏感部分以后者口径为准。
问题 3：SpaceXSI 自家哪些 Grok Build 应用资料被暴露？
回答 3：共发现 24 个 SpaceXSI 与 X 员工构建的开放应用，包括新销售员工机密入职计划、594 个客户的销售区域地图、8 份广告提案、4 个广告账户看板、7 份海外广告主活动报告和 2 份品牌安全手册；其中只有 1 个应用设置了密码。事件披露后这 24 个应用已被下架。
问题 4：Grok Build 的分享链接为什么会被外人找到？
回答 4：应用链接采用子域名形式，随机单词标识放在域名前；首次访问触发的 DNS 查询会被被动 DNS 服务收录，形成可检索的公开数据库，所以不需要猜中随机标识也能找到应用。同时发布面板默认选中 "知道链接即可访问"，内部应用没有默认加上组织登录或成员校验。
问题 5：发现 Grok Build 应用里有密码或内部资料，现在应该怎么处理？
回答 5：先把应用访问权限改为 "受邀用户" 或 "仅自己"，用外部账号实测能否进入；检查前端脚本中的姓名、邮箱和密码，存在密码或密钥的先轮换凭据再清理记录；无人使用的应用直接下架。企业还应盘点员工使用的 AI 应用构建器，并通过被动 DNS 检索自有应用地址，避免内部资料长期挂在公开链接上。
【参考资料】
- [2026-11-11]（大水冲了龙王庙？AI 编程工具 Grok Build 漏洞导致 SpaceXSI 敏感资料暴露）腾讯新闻（IT 之家）
- [2026-11-11]（Grok Build left 35,000 apps open to anyone, including SpaceXSI's own confidential sales plans）MadRobot
- [2026-11-11]（Grok Build Leak Exposes Sensitive Data From Thousands Of Users）Dataconomy
- [2026-11-10]（GhostShares 2: Grok Apps Exposed xAI's Business Secrets and People's Private Data）Claroc Blog
【免责声明】
本文基于安全研究方公开博客、媒体报道与平台回应整理，应用数量、敏感案例与组织归属均为 Claroc 在特定排查时间点的统计口径，研究方未对所见凭据做可用性验证，文中不构成 "凭据已泄露可用" 或 "已被利用" 的结论；平台后续修复、下架范围与受影响主体认定以 SpaceXSI 官方公告和监管披露为准。本文仅作安全信息梳理与自查参考，不构成投资、法律或采购建议。