一句话就能做出一个应用，听起来很美好，直到你发现，别人用一句话也能打开你的应用——连同里面装着的全部数据。2026年11月10日星期二，科技媒体Ars Technica报道，安全公司Claroc发现，xAI的编程工具Grok Build存在严重的信息泄露问题：数以万计用户用它搭建的应用无需登录就能被任何人打开，其中甚至包括SpaceX与xAI合并后的公司SpaceXSI自家员工搭建的24个应用，里面装着被标注为机密的销售资料和内部系统信息。这不是一次黑客入侵，也不是某个服务器被攻破，而是一套分享机制从设计上就留出的口子。写代码的人以为自己在做一个私人小工具，实际上却把它放到了公共互联网的货架上。
Grok Build是xAI推出的“氛围编程”工具：用户用自然语言描述想要什么，模型就生成一个可以运行的应用，并给它一个可以访问的网址。这种“说句话就有个应用”的体验，正是它吸引用户的地方，也是这次事故的起点。Claroc的研究显示，问题不在于某个用户点错了按钮，而在于平台把每个应用的随机名字放进了网址的主机名部分，任何一次访问都会在互联网的域名解析记录里留下痕迹，而这些记录又会被专门收集域名解析数据的服务汇总成可以检索的数据库。换句话说，应用的地址本身就是一把挂在门外的钥匙，谁拿到数据库，谁就能挨个试开。
三万五千多个应用，九成以上不设防
Claroc的研究给出的数字相当直观。研究人员通过被动域名解析数据，列出了43601个以grok.me结尾的应用地址，也就是Grok Build发布应用所用的域名。在这些地址当中，37571个在检查时仍然在线，而其中35578个无需任何登录就能直接打开，占比高达94.7%。只有1993个返回了拒绝访问的提示。也就是说，在Grok Build上发布的应用里，绝大多数处于“知道地址就能进”的状态，而不是“需要身份验证才能进”。这个比例本身就说明，泄露不是个别用户的疏忽，而是一种系统性的默认状态。
Claroc进一步估计，大约十分之一的公开应用含有敏感的商业或个人数据，其中约650到800个含有明确的隐私数据。这个估计建立在对样本的人工核查之上。研究人员确认的案例五花八门：有的应用里装着企业的商业计划和广告提案，有的装着员工的姓名和工号，有的装着体检记录，还有一家名人邮轮公司的厨房检查清单。除了SpaceXSI和X之外，Claroc确认了30家组织的内部数据出现在了公开应用中，其中26家拥有1000名以上员工，6家位列财富500强。Claroc没有公开这些组织的名称，但它已经开始逐一通知受影响的机构，到报道发布时已经联系了其中三家。
这些数字值得再读一遍。43601是被发现的地址总数，35578是无需登录即可打开的数量，650到800是确认含有隐私数据的估计范围。它们不是同一口径的数字，却共同描绘出一件事的规模：这不是几个倒霉用户的遭遇，而是一个面向所有用户的平台级问题。当一个工具的默认分享方式就是“知道链接就能看”，而链接又能被批量枚举时，每一个把真实数据放进应用的人，都在不知不觉中参与了一次公开。
泄露是怎么发生的：随机名字藏不住
要理解这次泄露，先要理解Grok Build的网址是怎么构成的。每个用Grok Build发布的应用都会得到一个属于自己的主机名，形式通常是几个随机单词加上grok.me。随机名字本身很难猜到，理论上只有拿到链接的人才能访问。这套逻辑和很多“未公开链接”的分享方式是一样的：地址足够随机，就等于一道密码。然而Grok Build的设计有一个致命的细节：随机名字放在了主机名里，而不是网址的路径部分。
这个区别决定了地址会不会留下痕迹。每当有人访问一个应用，电脑都要先做一次域名解析，把主机名翻译成服务器地址。而被动域名解析服务会收集这些查询记录，汇总成一个可以按模式检索的数据库。任何人只要拥有这类服务的账号，就能搜出所有以grok.me结尾的主机名，相当于拿到了一份完整的公开应用清单。随机名字防的是“猜”，防不住“查”，而被动解析数据库恰恰让“查”变得轻而易举。
Ars Technica在报道中特别做了一个对比：谷歌文档、Claude的公开成品、ChatGPT的分享对话，都把链接中需要保密的部分放在路径里，而域名解析是看不到路径的。也就是说，同样是“知道链接才能看”，别的服务把秘密藏在了域名解析够不着的地方，Grok Build却把它写在了每次访问都会广播的主机名上。Claroc也指出，Lovable、Replit、Bolt等其他应用搭建工具同样会给每个应用分配独立主机名，这个行业通病并不只属于Grok一家，但这次是Grok Build首先被系统性地扒了个底朝天。
自家机密也中招：24个SpaceXSI员工应用
这次事件最具讽刺意味的部分，是连做这个工具的公司自己都没能幸免。Claroc发现了24个由SpaceXSI和X员工搭建的公开应用。SpaceXSI是Ars Technica对合并后的SpaceX与xAI的称呼，也就是Grok背后的公司。这些应用里的内容，比普通用户的个人小工具要敏感得多：一份被标注为机密的新企业销售员工入职计划，列出了内部系统的地址、销售团队使用的工具和19个内部聊天频道，以及一份为期30天的入职安排；一张覆盖594个战略销售客户及其销售进程的客户版图；八份X的广告提案和媒体计划，其中一份是给美国联邦机构的提案，同样标注为机密；还有四个实时广告主看板，带有广告花费数据，以及面向巴西、日本、韩国和泰国广告主的推广报告。
Claroc的联合创始人兼首席技术官阿萨夫·阿普罗兹珀在研究报告中写道，他们感到震惊：做出Grok的公司，自己的内部材料就这样对任何拿到链接的人敞开，而他们从来没有收到过这些材料。Claroc表示，它是在11月8日星期日那天，在一份无人发给它的地址清单中偶然发现了这份入职计划。随后它通过security.txt文件中留下的联系地址向SpaceXSI报告了问题，并在11月9日星期一补充发送了其余22个员工应用的详情。但直到11月10日星期二晚上，Ars Technica核查时这24个应用仍然可以公开访问。SpaceXSI在Ars发去询问邮件后的数小时内开始下线这些链接，到报道发布时，24个应用都已返回“应用未找到”的提示。
需要说明的是，SpaceXSI下线的是自家员工的24个应用，其他用户的公开应用并未随之关闭。Claroc表示，SpaceXSI没有说会不会联系其他公开应用的拥有者，因此它决定自己动手，逐一通知受影响的组织。这个细节很关键：一次针对自家材料的紧急处理，并不等于平台层面的修复。对于那三万多个仍然在线的应用来说，什么都没有改变，知道地址的人依然可以打开它们。
泄露的不只是商业文件，还有体检和密码
如果只看SpaceXSI的24个应用，这件事还只是一家公司的内部管理事故。但Claroc人工核查的样本显示，泄露的范围要广得多，也要私人得多。一家医院集团的员工花名册出现在公开应用里，涉及3500多名员工；一份重症监护病人的简报里有实验室检查结果和呼吸机状态；一个消防部门的实时值班表上列着队员的徽章编号；一家承包商的工时表代码里，竟然以明文保存着18名员工的账号和密码。Ars Technica列出的其他例子还包括：一份特斯拉服务中心的评分表，点名了22名技师的生产效率和奖金状态；一家秘鲁建筑公司3784名工人的体检结果；还有一家挪威芬兰防务集团在美国运营的工厂里，一栋爆炸物建筑的装载板。
这些案例有一个共同点：它们都不是用户刻意要公开的东西。没有人会主动把员工的体检结果、病人的实验室数据或者明文密码放到公共互联网上。它们之所以出现，是因为用户把Grok Build当成了一个私人工作台：把真实数据导进去，让模型帮忙做一个内部工具，以为做完之后只有自己能看到。平台没有在关键时刻拦住他们，没有明确告诉他们这个应用正在被放到公共互联网上，也没有在应用里装着数据库却没有登录保护时发出警告。于是，一份内部工具就这样变成了公开网页。
这也是为什么Claroc的估计值得重视：约十分之一的公开应用含有敏感数据，650到800个含有隐私数据。哪怕这个数字存在误差，它指向的结论也不会改变：当一个工具同时具备“容易上手”和“默认公开”两个特点时，真实数据的泄露几乎是必然的。用户不是安全专家，他们不会去研究主机名和被动解析数据库的区别，他们只会相信产品给出的默认设置是安全的。而这次的默认设置，恰恰是不安全的。
不止是能看，还能改：第二个漏洞
除了无需登录就能查看应用和数据，Claroc还发现了另一个更严重的问题：某些应用甚至允许陌生人修改和删除数据。研究人员自己搭建了两个测试应用来验证这一点。其中一个是团队应用，Grok为它添加了谷歌和X的登录功能。但代码的逻辑写错了顺序：它先把登录的用户加入团队，然后才检查这个人是不是团队成员。结果是，任何一个没有被邀请的谷歌账号登录后，都能读取、编辑甚至删除里面的记录。Claroc表示，它只在自己搭建的应用上做了写入测试，没有动别人的数据。
这个发现把事件的性质从“信息泄露”推向了“越权访问”。前者是别人能看到你的东西，后者是别人能改你的东西。一个内部的团队工具，如果任何人登录后都能删改记录，那它就不只是一个隐私问题，还是一个数据完整性问题。好在Claroc发现的这个逻辑漏洞局限在它自己搭建的测试应用上，研究报告没有说有多少真实用户的应用存在同样的登录逻辑缺陷。但它至少证明了一件事：Grok Build生成代码的质量，同样需要被审视。模型生成的应用不仅可能把数据公开，还可能在权限判断上犯低级错误。
默认设置之争：谁该为公开负责
事件曝光后，争论的焦点落在了“默认设置”上。Claroc说，在它付费账号的发布面板里，分享选项有三个：“知道链接的任何人”“受邀用户”和“仅自己”，其中第一个已经被预先选中。也就是说，用户点发布时如果不特意改动，应用就是公开的。SpaceXSI则对记者表示，Grok的应用在创建者选择分享之前都是私有的，发布需要经过几次点击和一份法律声明，员工账号默认是“仅自己”。被SpaceXSI收购不久的编程公司Cursor的代表也对Ars表示，应用“默认是私有的，除非创建者选择分享，否则什么都不会公开”，但没有回答后续的追问。
两种说法之间的张力，恰恰是这次事件的核心。一种说法强调“用户主动选择了分享”，另一种说法强调“系统预先替用户选好了公开”。从Claroc的实测来看，发布面板预选了最开放的选项，这意味着大量用户可能在没有意识到的情况下就把应用公开了。更何况，即使用户确实点了分享，他们理解的“分享”也往往是“把链接发给想看的人”，而不是“把应用放到一个可以被批量枚举的公共清单上”。当“分享”的实际含义超出了用户的理解，责任就不该只算在用户头上。
Claroc向SpaceXSI提出了四点建议：把应用放在同一个主机的路径下提供服务，而不是每个应用一个主机名；增加仅限组织内部的分享选项；把“仅自己”设为默认选项；当应用带有数据库却没有登录保护时发出警告。这些建议都没有要求什么高深的技术，每一条都是产品设计上可以做出的选择。截至报道发布时，SpaceXSI没有公开回应是否会采纳这些建议，也没有表示会联系其他公开应用的拥有者。Claroc只能自己开始通知受影响的组织，到报道发布时已经发出了三封邮件。
这不是Grok第一次出隐私问题
值得注意的是，Grok Build的隐私问题并不是第一次出现。2026年7月，就有研究人员发现，Grok的命令行工具会把开发者的整个代码仓库，包括提交历史和已经提交的密钥，上传到公司的云存储。马斯克当时表示，上传的数据会被删除。那次事件和这次事件的共同点在于，数据的流向超出了用户的预期：用户以为数据留在本地或者只在自己的账号里，实际上数据被传到了别处，或者被放到了公开的地方。
两次事件放在一起，指向同一个根源：AI编程工具在追求“快”和“方便”的时候，把数据边界的处理交给了默认设置和用户的自觉，而这两样东西都靠不住。写代码的人关心的是功能能不能跑起来，不会逐行检查模型生成的代码有没有把数据库暴露出来，也不会去研究分享链接的域名解析行为。工具越是宣称“零门槛”，用户就越不会去想门槛后面的事。而当工具的默认选项恰好是最开放的那一个时，事故就从“可能发生”变成了“正在发生”。
对普通用户来说，这次事件的教训非常具体。首先，如果你用过Grok Build搭建应用，现在就去检查一下自己的应用是不是公开的，尤其是那些导入过真实数据的应用。其次，不要把真实的客户名单、员工信息、体检记录、密码或者任何带有个人身份信息的数据放进这类工具生成的应用，除非你已经确认它有登录保护，并且只有被授权的人能访问。最后，定期清理不再使用的应用，公开的链接一旦被收录进被动解析数据库，就很难彻底收回，哪怕你事后把它设为私有，历史记录里可能还留着它的地址。
给AI编程工具的一课
对整个AI编程工具行业来说，Grok Build的遭遇是一次公开的压力测试。Lovable、Replit、Bolt等同类工具同样给每个应用分配独立主机名，同样面临被动解析数据库枚举的风险。这次是Grok Build被扒了出来，下一次可能是别的平台。行业需要回答的问题其实很简单：一个面向非专业用户的编程工具，默认状态应该是公开还是私有？分享链接的秘密应该放在主机名里还是路径里？当应用里装着数据库却没有登录保护时，平台应不应该主动警告？
这些问题的答案，在传统软件的世界里早有共识：默认私有、最小权限、敏感操作需要明确确认。但在AI编程工具的赛道上，为了降低使用门槛、加快传播速度，不少产品把这些共识抛在了脑后。Grok Build的发布面板预选了“知道链接的任何人”，就是这种取舍的缩影：它让分享变得毫不费力，也让泄露变得毫不费力。当三万多个应用可以被任何人打开，当其中一家公司的机密销售资料、医院的员工名单和病人的检查结果都赫然在列时，方便的代价就已经写在了账单上。
事件到11月11日星期三为止还没有一个完整的结局。SpaceXSI下线了自家员工的24个应用，但其他三万多个公开应用仍然在线；Claroc开始逐一通知受影响的组织，但通知的速度赶不上枚举的速度；平台层面的修复建议已经摆在桌面上，但是否采纳还没有说法。对于还在使用这类工具的人来说，最现实的做法不是等待平台修复，而是先假设自己做过的每一个应用都是公开的，然后逐一去验证。这个假设听起来悲观，但在这次事件之后，它是最符合事实的假设。毕竟，连做出这个工具的公司自己的机密都没能藏住，普通用户又凭什么相信自己的数据是安全的。
- 最新
- 最热
只看作者