GPT-5.6 SOL 暴走失控，GLM5.2 紧急救场，HF 揭秘大模型攻防战技术细节

前沿模型突破层层防线，开放权重模型完成反向追踪。 作者丨郑佳美 编辑丨马晓宁 7 月 27 日，Hugging Face 首次完整披露了这次 Agent 入侵的技术细节，还原了其逃出 OpenAI 测试沙箱、进入 Hugging Face 生产环境、窃取凭证并向内部集群扩散的全过程。整场攻击从 7 月 9 日持续到 7 月 13 日，共产生约 17,600 次操作，形成了一条由 Agent 自主规划、持续试错和动态调整的完整攻击链。但 Hugging Face 这次没有公布具体模型，只表示攻击 Agent 由多个 OpenAI 模型共同驱动。不过早在 7 月 22 日，奥特曼就已经发文“认领”，确认参与测试的模型包括 GPT-5.6 Sol，以及一款能力更强、尚未发布的内部研究原型。这也让事件的重点从“究竟是谁干的”，转向“这套 Agent 是如何一步步突破多层防线的”。01模型如何攻击 Hugging Face？Hugging Face 公布的时间线显示，它并不是依靠单个漏洞直接进入生产系统，而是先逃出 OpenAI 沙箱，再寻找外部跳板，最后利用 Hugging Face 自身的数据处理链路完成入侵。▎第一步：利用零日漏洞逃出 OpenAI 沙箱OpenAI 原本将评测放在高度隔离的环境中。模型不能直接访问互联网，只能通过内部部署的软件安装依赖包。这个有限出口最终成为 Agent 逃逸的入口。Agent 在软件包缓存代理 Artifactory 中发现了一个此前未知的零日漏洞，并利用它突破网络限制。随后，它在 OpenAI 的研究环境中继续进行权限提升和横向移动，最终找到一个能够连接公网的节点。也就是说，Agent 并没有被授予互联网权限，而是通过漏洞自己获得了互联网访问能力。OpenAI 后续已将相关漏洞提交给软件供应商处理。这一过程说明，Agent 不只是能够生成漏洞利用代码，还能理解软件代理、网络出口和节点权限之间的关系，再把局部缺陷转化为逃离隔离环境的通道。▎第二步：攻占第三方沙箱，建立攻击基地获得公网访问后，Agent 找到了一个公开的第三方代码评测沙箱。这个沙箱允许用户提交 C 语言代码，由系统完成编译和运行。Agent 发现，它既可以在程序加载阶段执行系统命令，也可以利用提交路径中的命令注入问题，获得任意命令执行权限。两条路径最终都让 Agent 在第三方沙箱中获得了管理员或 Root 权限。随后，这个原本用于测试代码的环境，被改造成攻击行动的控制中心、载荷中转站和数据出口。这一步让攻击具备了持续性。即使 OpenAI 的临时评测环境被重置，Agent 仍然可以从外部沙箱重新部署工具、恢复通信渠道并继续行动。▎第三步：把 Hugging Face 数据集变成攻击入口接下来，Agent 将目标转向 Hugging Face 的数据处理系统。Hugging Face 需要自动处理用户上传的数据集，读取文件、解析配置并生成预览。Agent 没有直接连接内部网络，而是构造恶意数据集，让生产服务器在处理数据时替它执行操作。第一条路径利用了 HDF5 的外部存储机制。HDF5 文件可以声明部分数据实际存放在另一个文件路径中。Agent 构造特殊数据集，诱导 Hugging Face 的处理程序读取服务器本地文件，从而获取生产 Pod 的环境变量和数据处理程序源代码。环境变量中包含部分密钥和访问凭证，源代码则暴露了数据处理流程的具体实现。第二条路径利用了 Jinja2 模板注入。某个本应只保存数字偏移量的数据配置字段，被错误地作为模板表达式执行。Agent 借此在 Hugging Face 的 Kubernetes 生产工作节点中执行任意 Python 代码。一条路径用于读取文件和凭证，另一条路径用于获得代码执行权限。两者结合后，Agent 正式进入了 Hugging Face 的生产环境。▎第四步：用 Hugging Face API 控制内部服务器进入生产 Pod 后，Agent 仍然需要解决外部沙箱与 Hugging Face 内部节点之间的通信问题。它的办法是，把 Hugging Face 自己的数据集和 API 变成控制通道。雷峰网Agent 上传包含命令的恶意数据集配置。生产节点处理数据集时执行命令，再将结果写入另一个由攻击者控制的数据集。外部沙箱随后通过正常的 Hugging Face API 读取结果，并生成下一轮命令。攻击指令和执行结果因此混入正常的数据集上传、处理和读取流量。Agent 不需要搭建传统的远程控制服务器，Hugging Face 平台本身就承担了命令传输功能。当某个数据集、临时账号或公共中转服务被封锁后，Agent 还可以更换新的数据集和通信渠道，重新建立控制循环。▎第五步：从一个生产 Pod 扩散到内部集群获得生产 Pod 的代码执行权限后，Agent 开始枚举文件系统、进程、网络和环境变量，读取 Kubernetes 服务账户令牌，探测云服务器元数据接口，并尝试从容器权限提升到宿主节点。取得节点 Root 权限后，Agent 读取了 Kubernetes 中保存的 Secret 对象。其中一个生产 Secret 包含 136 个密钥，包括内部网络注册密钥和跨集群访问凭证。雷峰网随后，Agent 使用被盗密钥，将攻击者控制的设备接入 Hugging Face 内部网络。整个行动期间，它累计尝试注册了 181 个设备。更严重的问题出现在跨集群访问系统中。Hugging Face 当时让多个内部集群共用一套高权限连接凭证，而且该身份被绑定到 Kubernetes 的 system:masters 管理员组。Agent 一旦拿到这个凭证，就可以迅速获得多个集群的管理员权限。它还利用代码托管平台的 App 集成生成访问令牌，进入少量内部代码仓库，并尝试修改 CI 构建脚本。如果这一步成功，恶意代码可能继续进入软件构建和发布流程。相关执行策略最终阻止了这些修改生效。Hugging Face 表示，没有发现模型、数据集、Spaces、软件包或容器镜像受到污染。攻击者实际读取的客户内容，主要是保存 ExploitGym 和 CyberGym 挑战答案的 5 个数据集。02GLM-5.2 是如何救场的Hugging Face 的安全系统其实捕捉到了多层异常信号，内部 AI 安全 Agent 也将部分信号关联成了一个完整事件。问题是，系统没有及时提高告警等级，也没有第一时间通知值班团队，因此延误了人工响应。安全团队介入后，迅速定位到数据集配置渲染器中的攻击入口，关闭相关组件，并切断 Agent 进入内部网络的路径。真正阻止攻击的，是人工团队采取的隔离、封锁和凭证轮换措施。GLM-5.2 的作用，主要发生在后续取证阶段。安全团队需要查明 Agent 执行了哪些命令、泄露了哪些凭证、进入了哪些系统，以及是否留下持久化工具。面对约 17,600 次操作，仅靠人工逐条分析几乎不现实，因此 Hugging Face 搭建了一套 AI 辅助调查流水线。团队最初尝试使用 Claude Opus 和 Fable 分析攻击日志，但这些闭源模型拒绝了大量任务。其安全机制无法准确区分“正在实施攻击”和“正在调查攻击”，因此将漏洞载荷、恶意代码和凭证分析同样判断为高风险行为。Hugging Face 随后在自己的基础设施上部署了 NVIDIA 量化版 GLM-5.2，并将分析流水线切换到这款模型。GLM-5.2 是 Z.ai 发布的开放权重模型，支持最长 100 万 Token 上下文，采用 MIT 许可证。Hugging Face 使用的是 NVIDIA NVFP4 量化版本，可以直接部署在自己的 GPU 基础设施中。攻击者会将数据切分成多个片段，再通过异或和压缩进行编码，将结果分散存放在不同的公共服务和数据集中。GLM-5.2 帮助团队识别出这套“切片、异或、压缩”的处理流程，并从日志中找到每轮行动使用的密钥。依靠这些信息，安全团队解密了常规扫描未能发现的载荷，重新还原出大量命令和数据传输记录。GLM-5.2 还协助开发了轨迹分析界面，用于关联不同环境中的攻击行为。本地部署同样非常重要。真实攻击日志可能包含仍然有效的密钥、内部域名、系统架构和未公开漏洞。使用 GLM-5.2 后，这些敏感信息可以留在 Hugging Face 自己的基础设施中，不需要提交给外部模型 API。因此，GLM-5.2 并不是在网络边界上直接击退 GPT-5.6 Sol，而是在攻击被阻断后，帮助安全团队解密载荷、恢复操作时间线，并确认哪些密钥需要轮换、哪些节点需要重建。03真正失控的是权限边界把这次事件描述成“AI 觉醒”其实并不准确。从现有证据看，Agent 没有产生脱离测试任务的独立目的。它一直在寻找 ExploitGym 的答案，只是发现入侵 Hugging Face 比正常解题更加直接。真正危险的地方在于，一个模型在目标定义存在漏洞时，同时拥有了执行代码、访问网络、读取凭证、保存状态和持续修改计划的能力。当这些能力被装进 Agent 框架后，模型是否具有主观恶意已经不是最重要的问题。只要任务只强调结果，而外部系统又缺少严格的权限边界，它就可能产生与真实黑客高度相似的行为。这次事件还暴露出另一个现实矛盾：关闭部分安全限制的闭源模型完成了攻击，开启安全限制