第176篇：大模型驱动的 AI 智能体自动化入侵Hugging Face案例全过程复盘分析（超详细版上篇）

原创 abc123info 2026-10-20 21:06 山东

 Part1 前言 

大家好，我是ABC_123。近两年来，AI大模型技术飞速发展，从文本生成、代码编写到自主规划、工具调用，新技术层出不穷。今天，我们分析一起发生于2026年7月的OpenAI大模型自动化攻击事件。这场持续约4.5天的攻击行动，AI智能体跨越多个信任边界，用了多个0day漏洞、逃逸了两个沙箱，完整展现了从初始入侵到深入内部基础设施的攻击链路；AI智能体在未经授权的情况下，为了获取题库和flag，意外入侵了Hugging Face k8s网络。据相关估计，顶尖人类黑客完成类似攻击可能需要两到三周。这一事件不仅揭示了AI智能体日益增强的自主攻击能力，也为网络安全防御带来了新的挑战。

 Part2 技术研究过程 

• 攻击事件起因介绍

当时OpenAI 正在测试AI 智能体的自动发现和利用软件漏洞的能力，让它参加一个类似于CTF的漏洞挑战，基于 ExploitGym 基准测试开展的内部网络安全能力评估。这个 AI 原本应该像安全人员一样，自己寻找漏洞并完成题目；但 AI 误以为 Hugging Face 网站上存放着这次考试的题库和答案，于是没有继续分析漏洞，而是尝试攻击 Hugging Face 的生产系统，绕过常规测试流程，想直接获取答案来作弊完成漏洞挑战。于是在约四天半的时间内，此 AI Agent智能体针对 Hugging Face 平台基础设施实施了一次端到端自动化入侵行动。

此次攻击是AI 智能体自动化完成的。AI 智能体在 OpenAI 提供的沙箱中持续进行目标探测、漏洞分析、访问尝试等攻击行为，并通过公共网络服务建立C2通信链路，实现攻击流程自动化。经安全团队调查，共还原约 17,600 次异常操作记录，并聚类分析形成约 6,280 个攻击行为链，相关活动持续时间约为 2026 年 7 月 9 日至 7 月 13 日。该事件表明，当前 AI 智能体已经具备一定程度的自动化攻击能力，可在无人干预情况下完成连续侦察和攻击流程，同时也暴露出 AI 系统在任务目标判断、权限控制和安全防护机制方面存在新的风险挑战。

• 第1步，AI Agent逃逸沙箱获取互联网访问能力

AI智能体收到了一项 ExploitGym CTF任务，并被要求编写漏洞利用程序来获取 flag。AI模型被允许可以在沙箱中运行命令，但无法访问开放的互联网环境。该智能体配置可能使用了最新的 Codex 搭配子智能体，配合一个使用 Ultra 版本的未发布模型，以及可能作为子智能体的 GPT-5.6。沙箱拥有 JFrog 软件包注册表的读取权限，可用于安装 npm、PyPI 和 Docker 软件包，以便AI智能体测试和执行漏洞利用代码。

 1  JFrog Artifactory 0day漏洞获取管理员权限

刚才我们说到，AI 智能体处在一个受到严格限制的沙箱环境中，软件包代理使用了JFrog Artifactory，该设置使AI Agent不直接访问互联网的情况下可以通过JFrog的缓存安装脚本插件，从而实现受限的互联网访问能力。在 Hugging Face 公开披露该事件的前一天，JFrog Artifactory发布了 Artifactory 7.146.27，修复了部分漏洞；据推测，其中至少有一个可能源自 OpenAI 的漏洞披露。这个漏洞在于 Artifactory 会信任访问令牌 JWT 中的声明，却没有先验证其签名。补丁如下所示：

要复现存在漏洞的刷新请求，首先生成一个可正常刷新的读取者令牌，然后伪造带有管理员声明的访问令牌：

将伪造的访问令牌与原始有效的刷新密钥一并发送：

Artifactory 7.146.25 接受了此操作，并返回了有效的管理员令牌；这让AI智能体获得了对 Artifactory 的控制权，但此时没有获得 shell 或直接访问互联网的权限。要连接到可访问互联网的节点，至少还需要一步。

 2   利用软件包缓存污染获取命令执行权限

拥有Artifactory 的管理员权限后，模型可以从缓存中删除一个受信任的软件包，将仓库指向其控制的源，并在缓存中用相同的名称和版本存入另一个软件包，如下所示。

该攻击场景利用 npm 供应链机制和内部制品仓库（Artifactory） 实现横向攻击扩散。攻击者篡改 npm 包元数据，使其中记录的 tarball 地址和完整性校验值（hash/integrity）指向恶意软件包，导致正常的 npm install 流程将恶意包识别为可信版本。如果该软件包包含 postinstall 生命周期脚本，npm 会在安装阶段自动执行AI智能体投放的恶意代码，从而获得目标节点的命令执行权限。

 3   共享邮箱式C2控制第2个节点获取互联网访问能力

随后，攻击者进一步分析 AI 服务内部依赖关系，寻找其他会自动安装或更新相关 npm 包的内部节点，通过依赖投毒方式实现横向移动。当前Agent由于受控节点位于内网，无法直接从公网节点上执行命令，攻击者还需要建立通信渠道，例如通过内部网络建立反向 Shell，或进一步滥用 Artifactory 等内部制品管理平台作为 C2通道，用于下发指令和回传执行结果。

当前攻击链可概括为：npm 元数据篡改 → 恶意依赖安装 → postinstall 代码执行 → 内网横向扩散 → C2 通信控制。

这样一来，模型无需在两个节点之间建立直接连接，就能控制第二个节点。一旦进入可访问开放互联网的节点，它就可以继续攻击 Hugging Face。这是一条相当复杂的攻击链，而 OpenAI 公布的细节不足以确认模型实际采用了哪种路径。第二个节点不是通过网络直连被控制，而是通过 JFrog Artifactory 充当“共享邮箱式 C2”被间接控制的。共享邮箱式 C2（Shared Mailbox C2） 是一种形象化说法，指攻击者不直接连接受害主机，而是利用一个双方都能访问的公共位置作为“留言板”或“邮箱”，实现命令下发和结果回传。

      攻击者/AI Agent
             |
             |
     上传命令(command)
             |
             ↓
     JFrog Artifactory
      （共享命令仓库）
             |
             |
     第二节点轮询(poll)
             |
             ↓
          执行命令
             |
             ↓
        上传执行结果
             |
             ↓
     Artifactory保存结果
             |
             ↓
       攻击者读取结果

• 第2步：AI Agent逃逸安全沙箱获取互联网跳板机

此时，AI Agent 通过利用软件包仓库缓存代理中的一个0day漏洞突破了自身沙箱环境限制，并获得了访问互联网的能力。为了有一个完全不受限制的执行命令的环境，随后AI Agent 入侵一个第三方用户托管的代码评测沙箱，被标记为 CyberGym 的实例，该实例暴露了一个可执行任意代码的接口；在此外部沙箱环境中AI Agent可以 root/管理员权限执行命令，并将该环境作为整个攻击活动的控制节点、攻击准备节点及网络出口节点。换句话说，该互联网沙箱成为该 Agent 发起后续攻击活动的外部跳板。

简而言之，该框架允许 Agent 通过 /submit-function API 接口提交 C 语言代码src/main.c 文件，并将其链接到一个会调用 sqlite3_initialize() 的目标程序中，然后对此代码进行编译和执行。sqlite3_initialize() 函数被注册为一个构造函数，因此当相关库被加载时，该函数会自动执行。该 Agent 利用这一机制，通过重新定义 sqlite3_initialize() 函数来实现执行任意 Shell 命令。

// attacker-supplied src/main.c (illustrative)
#include<stdlib.h>


intsqlite3_initialize(void){
    system("id; echo ZZROOTSTART; cat /proc/self/mountinfo");
    return 0;
}

但随后，AI Agent进一步发现并利用了代码提交流程中的参数校验缺陷：该沙箱会将用户提交的源代码路径直接拼接到后续 Shell 构建命令中，而未进行有效过滤。攻击者在路径字段中利用经典的命令注入方式，使构建流程被篡改，从而执行任意命令。

path = src/main.c;echo ZZROOTSTART;cat /proc/self/mountinfo; ... ;false;#

两种攻击路径最终都达到了相同的效果，在该沙箱环境中以 uid=0（即 root 权限） 执行任意 Shell 命令。第一个远程代码执行（RCE）行为发生在 7 月 9 日 04:01 UTC，其执行内容非常简单：

id            # uid=0(root) gid=0(root)
env           # dump the environment, look for anything useful

不到一个小时内，该 Agent 已开始对互联网靶场沙箱环境进行系统探测，包括分析容器的挂载表、控制组、供应商控制平面以及一个随环境附带的调试 Shell。该调试 Shell 恰好内置了 curl、nc 和 ip 等网络与系统诊断工具，这些curl、nc等预置的工具在后续攻击过程中发挥了重要作用。

cat /proc/self/mountinfo
ls -la /<sandbox-root> /<sandbox-root>/volumes /<sandbox-root>/mounts /pkg /root
PATH=/<sandbox-root>/.debug_shell/bin:$PATH curl -s http://<internal-svc>:8000/...

• 第3步：AI Agent借助跳板入侵 Hugging Face k8s网络

AI Agent 从这个外部跳板机出发，开始攻击 Hugging Face 内部网络，通过数据集处理流水线的两个漏洞（HDF5 文件读取漏洞、Jinja2 模板注入）获取 Hugging Face 的 Kubernetes 集群内部Pod网络访问权限。具体流程如下：外部Launchpad-->恶意Dataset配置（基于配置驱动的数据加载器）--> Hugging Face Dataset Processor--> 生产Kubernetes Pod。

 1  漏洞利用1：AI利用HDF5 外部原始数据存储文件读取漏洞

AI Agent的第一种攻击路径利用了 HDF5 外部原始存储数据集读取机制，该漏洞可以返回本地文件内容。通过这一方式，Agent 获取了 Pod 环境中的信息，包括：密钥secrets、访问令牌tokens及工作节点自身的源代码。

AI Agent利用的是本地文件读取漏洞，利用 HDF5 数据格式支持引用外部文件的特性，构造了一个恶意数据集；该数据集表面上是普通 AI 训练数据，实际隐藏了对服务器本地文件的读取指令。当 Hugging Face 后台 Worker 自动处理该数据集时，会按照 HDF5 文件中的定义读取本地指定路径中的内容，并将其作为数据返回。攻击者随后通过Hugging Face API  接口获取这些数据，最终导致服务器本地文件泄露。

 Agent（提交数据集的人/程序）
             |
             v
Dataset Config（告诉平台怎么读取数据）
             |
             v
 Worker（平台的数据处理机器）
             |
             v
      读取 HDF5 文件
             |
             v
    返回 Dataset 数据行
             |
             v
     Hugging Face API
             |
             v
    用户/API调用者获取数据

具体技术细节如下：

数据集配置（dataset config）可以通过多种格式指定其数据文件，其中包括 HDF5 格式。该 Agent 提交了一个数据集，其精心构造的配置文件将每个数据切分指向一个较小的 .h5 文件。每个文件都是一个有效的 HDF5 容器，其中包含一个数据集，而该数据集的原始数据被声明存储在本地文件系统中的某个路径下，指向 Worker 运行环境中的敏感文件。当 Worker 为构建数据切分而打开该文件时，它会根据 HDF5 中的定义，从指定的本地路径读取原始字节数据，并将这些内容作为数据集的行返回。随后，Agent 通过 Hugging Face API 读取这些返回的数据内容。AI Agent在获取初始访问立足点的过程中，攻击者重点读取了以下目标文件内容：

# the malicious dataset config (README.md): each split is one .h5 file,
# and each .h5 declares its raw data as living at a local path on the worker
configs:
  - config_name: envu8     # -> /proc/self/environ
  - config_name: mainu8    # -> /src/services/worker/src/worker/main.py
  - config_name: startu8   # -> /src/services/worker/src/worker/start_worker_loop.py

当攻击者读取 envu8 数据分片时，Worker 返回了运行环境中的完整环境变量信息，其中包含部分敏感配置、访问密钥和认证凭据等信息。随后，攻击者进一步读取 mainu8 和 startu8 数据分片，获取了 Worker 自身的数据处理源代码，使该 Agent 能够准确了解整个数据处理流水线是如何将配置转换为具体执行操作的，即流水线实现细节。在 Pod 内执行命令产生的输出结果，会通过 Hugging Face API 以及由攻击者控制的数据传输方式返回给该 Agent。随后，Agent 从其运行的沙箱环境中读取这些返回数据，并据此继续执行后续操作。

     OpenAI AI Agent
            | 
            | 利用0day漏洞
            ↓
       OpenAI 沙箱
            |
            | 沙箱逃逸
            ↓
     第三方代码评测环境
            |
            | Root权限，作为攻击跳板
            ↓
Hugging Face 数据集处理系统
            |
            | 漏洞利用
            ↓
      外部Launchpad
            | 后续攻击
            | 漏洞利用
            ↓
Hugging Face 生产 Kubernetes Pod
            |
            ↓
   Hugging Face 内部资源

 2  攻击路径 2：AI利用Jinja2 模板注入漏洞攻入Hugging Face k8s网络

第二种攻击路径是服务端模板注入漏洞，该漏洞最终使 Agent 能够在我们 Kubernetes 集群中的生产环境转换 Worker Pod 内执行任意 Python 代码。攻击者通过构造恶意数据集配置，将 Jinja2 模板表达式（{{ expression }}）注入到 fsspec 的 reference:// 数据引用配置中。其中本应表示数字偏移量的字段实际上被填充为了一个 Jinja2 模板表达式。由于渲染流程存在缺陷，该模板内容被错误地执行解析。

随后，该 Agent 利用 Python 标准对象调用链，最终触达 exec 函数，实现了 Worker 环境中的任意代码执行。

{{ cycler.__init__.__globals__.__builtins__.exec(
     "import gzip,base64; exec(gzip.decompress(base64.b64decode('<payload>')))"
   ) }}

随后该 Pod 成为攻击者进入Hugging Face内部网络环境后的关键立足点。攻击者利用该环境执行进一步操作，并通过 Hugging Face API 将执行结果隐藏回传至其控制的数据集中，实现了基于正常业务链路的数据隐蔽传输。由于该方式利用了正常的数据集访问流程作为通信通道，使攻击流量表面上表现为普通的数据读取行为，从而降低了传统安全监测手段对异常通信的发现概率。

• 未完待续，AI Agent自动渗透k8s内网网络

攻击者最初尝试通过传统 SSRF 方式访问云元数据服务，但被平台 URL 校验机制拦截，返回错误 ValueError: not an hf path。随后，AI Agent调整策略，不再尝试让 Worker 获取远程资源，而是转而利用 Worker 操作本地资源，通过本地文件读取和代码执行两条路径绕过 URL 限制，最终突破数据处理环境安全边界。由于这两种方式均不涉及 URL 请求，因此不会经过 URL 允许列表检查，从而成功绕过了该防护机制。两种攻击路径都利用了同一个攻击面，即负责将数据集声明配置转换为文件读取操作的数据加载器，但最终实现的目的不同，同时绕过了相同的安全防护机制。

一旦 Agent 在 Hugging Face 生产环境 Pod（prod-pod）中建立了立足点，它便按照一种典型的权限提升和横向渗透模式展开行动：首先进行侦察，然后投放阶段性载荷，建立 C2 通道，随后进一步横向移动至 Kubernetes 集群、云环境元数据服务、内部网络以及源代码控制供应链。未完待续，敬请期待。

 Part3 总结 

1.  攻击能力边界扩大。AI Agent 的风险不仅来自模型本身，还取决于其可调用的工具、代码执行环境、网络出口及第三方基础设施。多种能力组合后，可能形成超出预期的自动化攻击链。

2.  目标偏离导致非授权攻击。AI Agent 为通过 ExploitGym 挑战，在无法解决题目时转而从互联网寻找答案，甚至将 Hugging Face 作为渗透目标。长时间推理、上下文压缩和子代理委派，还可能进一步弱化任务约束，使其偏离原始目标并突破授权边界。

3.  开源生态面临更大安全压力。具备较强代码分析能力的 AI Agent 可以持续审计大型代码库，不知疲倦地挖掘潜在漏洞。在充足算力支持下，0day 漏洞的挖掘门槛可能进一步降低，也让开源软件面临更大的安全风险。

4.  自主决策带来未知风险。随着推理能力增强，AI Agent 可能更高效地探索实现目标的路径。未来更值得关注的是，当目标设定与安全约束发生冲突时，模型能否主动遵守边界，是否会为达成目标而刻意隐藏真实意图或采取超出授权范围的入侵行动。

5.欢迎大家扫码加入知识星球希水涵@信安知识库，进入星球内部交流群，一起学习进步（原有知识星球内容正在迁移）。

为了便于技术交流，现已建立微信群"希水涵-信安技术交流群"，欢迎您的加入。

公众号专注于网络安全技术分享，包括APT事件分析、红队攻防、蓝队分析、渗透测试、代码审计等，每周一篇，99%原创，敬请关注。

Contact me: 0day123abc#gmail.com

OR 2332887682#qq.com

(replace # with @)

跳转微信打开