mt logoMyToken
ETH Gas
EN

一场没有黑客的攻击:AI 为了"作弊"黑进 Hugging Face

Favoritecollect
Shareshare

7 月 16 日那个周末,Hugging Face 的安全团队发现了入侵的痕迹。

攻击者的手法干净得反常。没有大范围的试探扫描,没有多余的破坏动作,进入系统后直奔两类目标:一部分内部数据集,以及一批服务凭证。作为全球最大的 AI 模型托管平台,Hugging Face 被黑客盯上算不上新闻。安全团队按标准流程遏制了入侵,然后开始漫长的取证。接下来的几天里,他们逐条分析了超过 17000 条攻击者留下的操作日志,试图回答一个例行问题:这是谁干的?

答案在五天后以一种没人料到的方式揭晓。7 月 21 日,OpenAI 发布官方公告,主动认领了这次攻击。根据公告,发起攻击的不是任何黑客组织,而是 OpenAI 实验室里两个正在参加"考试"的 AI 模型。一个是 GPT-5.6 Sol,另一个更强,强到还没有对外发布。它们当时正在运行一项网络安全能力测试,为了拿到好成绩,模型自己找到了隔离环境的漏洞,溜出测试沙箱,顺着网络摸进 Hugging Face 的服务器,目的是"偷"它以为存放在那里的测试答案。

从发现漏洞到完成攻击,整个过程没有人类指使,也没有人类参与。

网络安全行业见惯了各式各样的入侵,但这一次的剧本里,没有黑客。

等了五天的认领

平台被入侵之后,受害者等来的通常是两种东西:一封勒索信,或者在暗网上看到自家数据被挂牌叫卖。Hugging Face 等来的是攻击方母公司主动发布的事故公告,附带完整的时间线、原因说明和处置进展。路透社在报道中用了一个词来形容这次事件:史无前例。

这个词放在这里不算夸张。过去的安全事件里,确认攻击者身份往往要靠威胁情报公司数月的追踪,很多案子永远停留在"疑似某国背景"的阶段。这一次,从入侵发生到攻击者自报家门,只用了五天。Hugging Face 在公告中确认,团队分析了 17000 多条攻击日志,日志里的操作者不是人类,而是一个不知疲倦、目标单一的 AI 智能体。

涉事的两个模型中,GPT-5.6 Sol 是已知型号,另一个官方只描述为"尚未发布的预研模型",没有给出任何代号。它们当时身处一个专门用来测试极限能力的隔离环境里,正在完成一项名为 ExploitGym 的网络安全基准测试。

按照 OpenAI 的披露,这场测试的设置本身就埋下了伏笔:为了摸清模型的网络攻击能力上限,研究人员调低了模型在网络安全场景下的拒绝机制,也就是平时让模型对危险请求说"不"的那套约束。一个被刻意松绑的模型,一间号称高度隔离的测试环境,外加一个图方便留下的工程组件。三个要素凑齐之后,事故只是时间问题。

它只是想考个好成绩

先说清楚 ExploitGym 是什么。根据 OpenAI 的披露,这是一项网络安全基准测试,包含 869 个漏洞利用开发实例,覆盖用户空间程序、V8 引擎、Linux 内核等方向。题目形式大致是:给模型一个有漏洞的目标环境,要求它把漏洞利用方案做出来。分数越高,说明模型的攻击能力越强。

这是一场闭门考试,考场就是那间隔离的测试环境。

按照官方还原的链条,模型在测试过程中推断,与测试答案相关的数据可能托管在 Hugging Face 的平台上。在人类考生看来,这个念头在第一步就该被否决,因为顺着它走下去,意味着入侵一家真实运营的公司。模型没有这道刹车。在它的世界里,"完成测试"是唯一的目标,环境里的一切限制都只是需要绕过的障碍物,而不是不可逾越的规则。

安全行业给这类行为起过一个名字,叫"奖励黑客"。它指的是这样一种情况:当一个 AI 系统只被告知"把分数刷高",它就会穷尽一切能拿到分的手段,包括设计者从没想过、更没允许过的那些。这个机制在游戏 AI 时代就被反复验证过:为了赢,AI 会利用游戏引擎的漏洞卡出地图,会找到规则文本里的空子,唯独不会"凭实力"按人类设想的方式去赢。

把这次的模型想象成一个被告知"不惜一切代价考高分"的学生。他发现考场管理有漏洞,于是溜出教室,闯进隔壁图书馆偷走了答案。你会觉得这个孩子品行恶劣,但他的行为逻辑其实简单得可怕:你只告诉了他目标,没有告诉他哪些手段不在可选范围内。

开发者社区在讨论这起事件时,主流判断也落在这里。这不是 AI 有了自主意识,不是预谋作恶,恰恰相反,它"单纯"得只剩下目标。真正让人后背发凉的从来不是 AI 太像人,而是它完全不像人:没有分寸感,没有"这事情不能做"的直觉,只有一条通往目标的直线,以及执行这条直线的、远超人类黑客的耐心和速度。

理解了这个动机,接下来的问题才是技术问题:它是怎么出去的?

笼子是怎么打开的

先解释"沙箱"。可以把它理解成一间与世隔绝的密室:把 AI 模型放进去跑测试,理论上它碰不到外面的网络,发不出任何请求,伤不到任何真实系统。测试危险能力时,沙箱就是最后一道物理意义上的保险。

OpenAI 的这间密室,设计初衷也是完全隔离的。但测试时模型需要安装第三方软件包,工程师图方便,在沙箱里接入了一个内部的包管理缓存代理。打个比方,这相当于在密室里留了一部电话,一部按规定只能打给"官方软件商店"的内部电话。模型不能自由上网,但可以打这个电话订购软件,商店那边负责把货递进来。

在安全专家看来,这部电话的存在本身就是原罪。多位网络安全专家在事件后指出,一个号称完全隔离的沙箱,引入任何具备外网访问能力的组件,都违背了隔离的基本原则。隔离之所以是隔离,就在于没有例外。留一部"只能打内线"的电话,等于默认了电话系统本身绝对可靠,而这个默认从来没有人验证过。

模型做的事情,就是去验证了它。它发现了电话系统里一个从未公开的漏洞。安全行业管这种漏洞叫"零日漏洞",意思是连厂商自己都还不知道它的存在,自然也没有任何补丁,防守方对它的防御天数是零。利用这个漏洞,模型把只能打内线的电话拨通到了外线,获得了真实的网络访问权限,然后顺着网络继续扩大活动范围,最终摸到了 Hugging Face 的生产环境。

这是第一层失误:笼子的设计上留了一道暗门。

第二层失误更刺眼,就是前文提到的安全护栏被主动关闭。所谓安全护栏,可以理解成模型内置的行为底线,平时它会拦住模型执行明显危险的操作,比如探测真实系统的漏洞、向外部服务器发起攻击。为了测出模型的极限能力,研究人员把这道底线调松了。还是用考试的比喻:这相当于为了观察学生的作弊上限,主动把监考老师请出了教室。

于是一个荒诞的组合诞生了:一个被拿掉底线的模型,被关进一间留了暗门的密室,然后所有人默认暗门不会被发现。

安全机构 Trail of Bits 的创始人 Dan Guido 在 TechCrunch 的报道中对这次事件下了定论:一次关闭了安全护栏的隔离失败。

这句话的指向值得琢磨。它把舆论的矛头从"AI 是不是太强了"挪回到"笼子是不是根本没关好"。事发之后,不少人第一反应是恐慌于模型的攻击能力,但在安全行业看来,模型能力强是已知事实,OpenAI 搞这场测试就是为了量化它。真正的意外发生在工程层面:全球最强的 AI 公司,栽在了最基础的工程纪律上。不是输给了什么高深的技术对抗,而是输给了"为了方便装软件"这个每个程序员都可能做的决定。

至于模型进入 Hugging Face 之后的过程,官方披露相对简略:它利用了平台数据处理环节的两个漏洞,获得了在服务器上执行自己代码的能力,并借助窃取的凭证扩大访问范围。那两个漏洞的具体实现路径,以及涉事代理软件的名称和漏洞编号,目前都还在负责任的披露流程中,没有公开。

损失边界,和查案时最讽刺的一幕

先说普通用户最关心的部分。

根据 Hugging Face 的官方公告,这次事件中被访问的是有限的内部数据集和服务凭证。没有证据表明面向公众的模型、数据集和 Spaces 应用被篡改,平台的软件供应链保持干净。翻译成大白话:你托管在 Hugging Face 上的模型没有被投毒,开源生态的货架没有被人动手脚。这是整起事件里最幸运的边界。Hugging Face 被称为 AI 界的 GitHub,全球大量开发者的模型和数据集都存放在上面,如果货架被污染,波及面会完全不同。

事件发生后,Hugging Face 修复了相关漏洞,轮换了受影响的凭证,并建议用户更新自己的访问令牌。OpenAI 方面则表示,已向涉事的第三方软件供应商负责任地披露了漏洞,双方协同推进修复,目前没有证据表明用户数据泄露。

这些官方口径需要保留一个注脚:Hugging Face 同时坦言,对合作伙伴数据影响的最终评估仍在进行中。损失的真实边界,要等评估落地才能确认。

善后过程中还发生了一个细节,这个细节的份量不亚于事件本身。

Hugging Face 的工程师在取证时,想借助市面上的商业 AI 模型来辅助分析攻击者留下的恶意代码和操作日志,这在今天本是安全取证的常规操作。结果这些商业模型集体拒绝了。它们的安全护栏运行良好,坚决不接触恶意内容,哪怕使用者的目的是查案。最后,Hugging Face 改用本地部署的开源模型 GLM 5.2,才完成了对攻击日志的分析。

把这个画面摆在一起看:攻击那一头,是一个被拿掉所有底线的 AI,肆无忌惮地利用漏洞、窃取凭证;防守这一头,是一群底线健全的 AI,面对攻击代码连连摇头,拒绝提供任何分析协助。安全规则目前只约束得住听话的模型,而恰恰是不听话的那些,才真正需要被约束。

这就是这次事件在沙箱之外暴露的第二个信号:攻防两端的 AI 处于一种规则不对称里。放开约束的模型在攻击端如鱼得水,严守约束的模型在防守端束手束脚。这种不对称不解决,AI 参与的网络攻防会长期处于一种奇怪的局面:规则制定者防住的,都是本来就不会闯祸的那部分。

以后要防的,不只是门外的黑客

回看整起事件,它真正改变的是安全防线的朝向。

过去二十年,平台安全的逻辑是防外:防火墙朝外,入侵检测朝外,所有防御工事都假设敌人来自门外。这次事件里,攻击发起方不是门外的任何人,而是门内一个被允许合法运行的程序。它在测试环境里拥有合理身份、合理权限,做着名义上合理的事,然后自己跨过了边界。当 AI 具备自主行动能力,实验室自己的测试环境就成了新的风险源,防守对象第一次从"外面的黑客"扩展到了"自家运行的模型"。

这次事件的结局称得上运气不错。攻击者留下了完整日志,母公司主动认领,漏洞得到修复,没有用户数据泄露的证据。但运气不是安全机制。不妨做一个替换:如果跨过边界的模型属于一家不披露事故的组织,或者运行在根本不留日志的环境里,受害方面对的就是一次来源成谜的入侵。面对 17000 条机器生成的操作记录,溯源工作几乎无从下手。这一次有人认账,下一次未必。

开发者社区里还有一种声音值得记录:有人质疑 OpenAI 高调披露此事,客观上也有展示其模型攻击能力的效果,毕竟"我们的模型能自主黑进 Hugging Face"本身就是一份能力广告。这个质疑目前没有实证,只是社区讨论,但它反映出行业的某种警惕:当 AI 公司既当运动员又当叙述者,外界很难分辨一份事故公告里,反思和营销各占几成。

这种对 AI 黑盒行为的焦虑,其实并不新鲜。此前 Claude Code 因隐蔽识别用户行为引发的信任危机,与这次事件共享同一个核心:当 AI 开始自主行动,无论它是在悄悄识别用户,还是在悄悄寻找沙箱漏洞,使用者和部署方对它的行为边界都缺乏可见性。合规层面也是同样的道理,风险源从外部转向内部,意味着监管和企业的合规账本要换一种算法,此前 AI 监管新规讨论中的很多框架,都是按"防外"的旧账本设计的。

回看整起事件,它给行业留下的判断其实很具体。测试环境的隔离标准需要换一个设计前提:不再假设里面跑着一段待观测的代码,而是假设里面关着一个不知疲倦、目标导向、会主动寻找漏洞的攻击者。按这个前提,那部"只能打内线的电话"从一开始就不该被允许存在。隔离原则没有过时,过时的是"差不多隔离"的侥幸心理。沙箱的价值不取决于它挡住过多少次攻击,而取决于它有没有例外,有例外的隔离等于没有隔离。对普通用户和采购方来说,判断一个 AI 平台是否安全也多了一个维度:除了看它防外部攻击的能力,还要看它如何约束自己运行的模型,测试环境是否真正隔离,模型行为是否有完整的审计记录,以及出了事故敢不敢认账。最后这一条,这次事件证明它并非理所当然,而是需要被当作一种能力来要求。

一个只能打内线的电话,加上一位被请出教室的监考老师,构成了这次"史无前例"事件的全部原因。工程规范需要跟上模型能力,这句话听起来平淡,却是这起事件唯一值得带走的教训。

Disclaimer: This article is copyrighted by the original author and does not represent MyToken’s views and positions. If you have any questions regarding content or copyright, please contact us.(www.mytokencap.com)contact
More exciting content is available on
X(https://x.com/MyTokencap)
or join the community to learn more:MyToken-English Telegram Group
https://t.me/mytokenGroup