Grok 应用集体裸奔：3.7 万个链接九成免登录，SpaceX 内部销售表与特斯拉奖金榜被公开

11 月 12 日，安全公司 Claroc 公布了一份测试报告：超过 3.5 万个用 Grok 搭建的应用，不需要登录就能打开；其中一部分，直接把企业机密和个人隐私摆在了公开网页上。

更刺眼的是名单。被波及的机构里，有 SpaceX 与 xAI 合并后的 SpaceXSI，有 X，还有另外 30 家企业，其中 6 家是《财富》500 强。一份 ICU 患者简报、一份写着 18 个明文密码的工时表、一份特斯拉服务中心的奖金评分表，就这样挂在了任何人点开就能看的链接后面。

一分钟速览

• Claroc 测试了 43,551 个 Grok Build 应用地址，其中 37,571 个仍在线，94.7% 的在线应用无需登录即可访问。
• 经模型筛查与人工抽样，估计 650 至 800 个应用包含私密数据，涉及 SpaceXSI、X 及另外 30 家企业，其中 6 家为《财富》500 强。
• 泄露内容包括 ICU 患者的化验结果、影像检查与呼吸机使用记录，以及一家承包商工时管理应用中 18 个账户的明文密码。
• SpaceXSI 的内部销售工具（战略客户账户、销售商机、团队信息）与特斯拉服务中心评分表（22 名技术人员的姓名、工作效率、奖金）都在其中。
• 根因不是网址太容易被猜到，而是把「难猜的网址」当成了「访问控制」：应用域名可通过被动 DNS 数据库批量检索。
• 报道发出数小时后，SpaceXSI 与 X 员工创建的 24 个应用全部下线，但其他用户创建的大量应用仍在线上。

随机网址不等于权限

用 Grok 做 vibe coding 的人大多熟悉这套流程：描述需求，模型生成一个能跑的小应用，点发布，平台分配一个形如「随机单词.grok.me」的地址。设计者希望这串随机单词足够难猜，从而降低被陌生人撞见的概率。

问题在于，难猜和防不住是两件事。Claroc 的解释很朴素：每当有人访问一个域名，计算机都要通过 DNS 查询它对应的服务器地址，部分 DNS 解析服务会把查询记录收进可搜索的数据库。于是就形成了一条完整的发现路径——有人访问过应用，DNS 留下记录，域名进入被动 DNS 库，外部研究者批量导出，逐个尝试访问。

如果应用发布时的权限是「任何持有链接的人」，那么「找到链接」就等于「拿到钥匙」。在这套链路里，随机网址只增加了被发现的成本，没有提供任何身份校验。

四个样本：从 ICU 到工资单

报告里被点名的四类数据，恰好覆盖了敏感信息的全部光谱。

第一类是医疗数据。一份 ICU 患者简报，包含化验结果、影像检查结论与呼吸机使用状态。这类信息一旦脱离医院内网，性质就从「内部记录」变成了「可被检索的病历」。

第二类是凭证。一家承包商的工时管理应用，把 18 个账户的明文密码直接写进了前端脚本，访问页面的人都能下载。这不是权限配置失误，而是开发阶段就把密钥当常量用。

第三类是商业情报。SpaceXSI 的内部销售工具暴露了战略客户账户、销售商机和内部团队信息；对一个处在发射合同与政府订单夹缝里的公司，这类材料的价值不用多解释。

第四类是人事数据。特斯拉服务中心的一张评分表，把 22 名技术人员的姓名、工作效率和奖金情况列得清清楚楚。它不属于机密，但属于典型的「不该公开」。

一个写反顺序的权限判断

为了验证 Grok 生成的代码是否可靠，Claroc 用虚构数据搭了一个四人销售团队的客户管理应用。Grok 确实自动加上了 Google 和 X 登录，但研究人员读代码时发现了一个低级错误：应用先把登录者加入团队，再判断他是不是团队成员。

顺序写反，结果就是所有人都自动成为成员。研究人员用一个从未被邀请的 Google 账户登录，不仅看到了全部客户资料，还成功修改了一条记录、删除了另一条记录。

这个案例说明，问题不只是「默认权限开得太宽」，还包括模型生成的鉴权逻辑本身缺乏审查。当应用由一句话生成、由非工程背景的人发布时，代码里那一行顺序错误的判断，没有任何环节会拦住它。

对照组：同样的网址，不同的默认值

Claroc 拿 ChatGPT 应用做了对照。其应用地址同样可能被被动 DNS 收录，但分享面板的默认设置是「仅限我」——即使别人找到了网址，也进不去。

差别就在这个默认值上。它决定了「用户忘了改设置」时会发生什么：一种情况是数据默认私有，需要主动公开；另一种情况是数据默认公开，需要主动收紧。

官方回应与它没回答的部分

SpaceXSI 对媒体的说法是：应用在创建者主动分享之前都是私密的，发布需要经过多个步骤，员工账户默认设置为「仅限你」，要公开必须主动修改权限。

Claroc 的反驳很具体：在他们使用的付费账户里，发布面板预先选中的选项是「任何持有链接的人」。这里的关键区别在于——「发布前是私密的」和「发布时默认给谁看」是两道题。如果一路点完发布，最终预选范围仍是所有持链接者，那么多确认几次也不会自动补上一份团队成员名单。

研究人员也验证了现有控制措施确实有效：切成「仅限你」后，陌生人访问页面和数据接口都会被拒绝；取消发布，应用能在几秒内下线。也就是说，工具本身有能力，缺的是默认值与流程上的强制。

处置节奏同样值得记录。在媒体发出采访邮件后的数小时内，SpaceXSI 才开始移除相关链接；截至报道发布，由 SpaceXSI 和 X 员工创建的 24 个应用已全部下线，但其他用户创建的大量应用仍可访问。平台是否会主动通知受影响的客户，没有得到明确答复。

vibe coding 的安全账，迟早要算

这类事故不会是最后一次。过去一年，能一句话生成完整应用的智能体迅速普及，发布流程被压缩到几分钟，而与之配套的权限模型、默认值设计、密钥管理几乎没跟上。Grok 这次的暴露面之所以这么大，是因为它把「生成」和「托管发布」连成了一条流水线，却没有在最后一步加一道默认隐私的闸门。

对使用者来说，有三件事现在就该做：检查已发布应用的访问范围，把「任何持有链接的人」改成明确的白名单；把所有出现在前端代码里的密码、密钥立刻轮换；把内部工具从公开域名上撤下来，改走内网或带鉴权的入口。

对平台来说，问题更根本：默认值本身就是产品决策。把默认设为私有，代价是分享时多一步；把默认设为公开，代价就是今天这份报告。前者只是麻烦，后者是不可逆的泄露。