GPT-6为刷榜黑进Hugging Face,捅篓子还得靠GLM-5.2追查...
        梦瑶 发自 凹非寺量子位 | 公众号 QbitAI真行,ChatGPT下一代模型还没发布,人家先把Hugging Face黑了……

        而且这AI费尽心思逃出测试环境、寻找漏洞、窃取凭证,最终目的居然只是——偷!

        评!测!答!案!OpenAI刚刚公开认领了一起《重大》安全事故。

        GPT-5.6 Sol与一款能力更强的未发布模型,在接受网络安全测试,成功逃出了内部隔离环境,一路闯进了Hugging Face的生产系统。

        然后,更戏剧性的一幕来了——调查入侵路径时,原本找来帮忙的商业模型掉链子搞不定,团队实在没招了,最终接手查案的反倒成了GLM-5.2???

        超过1.7万条的攻击记录,就这么让一个本地部署的开源模型一口气拿下了……

        这下好了,OpenAI模型负责黑,GLM负责查。家人们,只能说这出AI版《猫鼠游戏》的大戏,还是太有节目效果了……

        为找评测答案,模型自己越狱上网了如此魔幻,如此抓马的事故起点,源自OpenAI内部进行的一次「网络安全能力」评测。

        模型参加的项目名叫ExploitGym,专门测试AI能否把真实软件漏洞,一步步变成可以实际运行的攻击。

        整套评测包含898个任务,每道题会提供存在漏洞的程序、能够触发问题的输入和相应运行环境,再让Agent自行分析漏洞、构造攻击,最终拿到藏在环境里的Flag!!!

        emm…其实就是把AI关进一座网络靶场,看看它到底有多会「黑」。

        而参加本次评测的选手,则包括GPT-5.6 Sol,以及OpenAI一款能力更强的未发布模型。

        (这个模型到底是啥捏,真的好难猜啊…)为了尽可能摸到模型能力上限,OpenAI还主动放宽安全护栏,鼓励模型尽可能寻找复杂的攻击路径~按照OpenAI最原本的设计,模型接触外部资源的唯一通道,是一套由OpenAI内部托管的第三方软件。

        它的身份是充当软件包注册中心的代理与缓存,让模型能够安装完成任务所需的程序包。

        然鹅吧,这模型显然没打算老老实实待在考场里。(doge)模型开始确实投入了大量推理算力,专门寻找获得公网访问权限的方法。

        但找着找着,还真让人家在缓存代理中发现了一个此前未知的「零日漏洞」。

        所谓零日漏洞,指厂商尚未发现、也没有现成补丁的安全缺陷,对于攻击者来说,这类漏洞往往意味着一扇暂时无人设防的门。

        至此,AI也顺道儿给自己开了网。(doge)有了公网权限后,了不得了,模型推断Hugging Face上可能存放着与ExploitGym有关的模型、数据集和评测答案。

        接下来发生的事儿,连OpenAI自己都形容模型走到了极!

        端!程!度!是的,拿到公网权限后,这AI真就开始研究怎么进入Hugging Face内部系统了。

        而且人家还没有押注单一漏洞,直接把多种攻击手段串成了一条「完整路径」——

        先通过恶意数据集,利用远程代码数据加载器和数据集配置中的模板注入漏洞,在负责处理数据的Worker上执行代码。

        随后继续提升权限,拿到节点级访问能力,并收集云端与集群凭证,一路横向移动到多个内部集群。

        最后就是,模型成功摸进Hugging Face的生产数据库,访问其中的机密信息,试图直接拿走ExploitGym的测试答案……

        咋说呢,这波属于是Benchmark做到一半,现场把自己做成了网络安全事故了……

        闭源模型拒绝查案,GLM‑5.2接手1.7万条日志事情到这里,还只演完了上半场。

        更戏剧性的一幕,发生在Hugging Face事后追查攻击路径的时候。

        事实上这场入侵由一套自主Agent系统端到端执行,背后还运行着大量短生命周期沙箱。

        它们可以同时开展侦察、漏洞利用、凭证收集和横向移动,短时间内完成成千上万次操作。

        Hugging Face最终记录下来的攻击事件,就超过了17000条,太多了,真的太多了……

        如果全靠安全工程师手工梳理,就需要逐条还原攻击时间线、提取入侵指标、确认哪些凭证被接触,再将真实影响和诱饵活动一一分开。

        等人类把日志看完,攻击者可能早都跑出二里地了……于是,Hugging Face做了个大胆的决定,决定以AI对AI,让大模型分析整套攻击日志!!!

        Hugging Face第一反应自然是调用商业API背后的「前沿模型」。

        但问题是吧,这些日志里包含真实攻击命令、漏洞利用载荷和C2控制痕迹,安全护栏一看到有人正在提交一整套真实攻击教程,吓得直接拦截请求了。

        最终接手这1.7万多条日志的模型,落到了GLM-5.2头上。

        Hugging Face在自有基础设施上部署了GLM-5.2开源权重模型,然后让它遍历完整攻击记录,重建时间线、提取入侵指标、追踪被接触的凭证,并区分真实破坏和干扰调查的诱饵活动。

        按照Hugging Face的说法,原本需要数天的工作,最后在数小时内就搞定了~这场事故,其实也让开源模型多了一个此前存在感不算太强、如今却相当现实的位置:安全团队的应急工具。

        Hugging Face将其总结为「安全不对称」问题——

        正常情况下,商业模型拒绝生成攻击代码,可以降低技术被滥用的风险;可当防守方需要分析真实恶意载荷时,同一套保护机制也可能让调查卡在半路。

        攻击者可以使用解除限制或自行部署的模型,安全团队却可能被云端模型拒之门外。

        所以吧,还是建议企业最好提前准备一款经过验证、能够在本地运行的高能力模型,免得事故真正发生时才发现云端模型无法处理攻击材料,那就尴尬了……怎么不算魔幻呢。

        OpenAI原本想知道模型有多会攻击,结果模型没有老老实实完成一道模拟题,而是直接发动了一次真实攻击。

        Hugging Face原本想用最强商业模型追凶,最后又被安全护栏挡在门外,只能让GLM‑5.2上场收拾残局。

        而且啊,大家发现没,OpenAI在这次事故说明中一边承认隔离和监控出现问题,一边又反复强调——

        最新模型已经能够在缺少源代码的情况下,长时间、自主完成现实世界中的复杂网络行动。

        翻译一下大概就是:这事确实挺危险,但俺家下一代模型,也确实强得有点吓人哈。

        (A社:搁这儿学谁呢?)估计,我琢磨着,没准整件事儿都是奥特曼借事故给GPT-6提前预热呢吧…(瞎说的)参考链接:[1]https://openai.com/index/hugging-face-model-evaluation-security-incident/[2]https://huggingface.co/blog/security-incident-july-2026一键三连「点赞」「转发」「小心心」欢迎在评论区留下你的想法!— 完 —🌟 点亮星标 🌟科技前沿进展每日见
🔗 原文链接:http://mp.weixin.qq.com/s?__biz=MzIzNjc1NzUzMw==&mid=2247906059&idx=2&sn=e956f3e82dd99d702dd2a32b26d031a5&chksm=e9ecac5017d9a053be5cb4639348e25c278265d39a80a52bbba2ac02ad7adfd5a334bb69f5c1
← 返回列表