当一个 AI 在 31 秒内自己学会"犯错→分析→修复→继续"，网络安全的历史翻开了新的一页。

2026 年 7 月 3 日，安全厂商 Sysdig 发布了一份注定会被反复引用的报告：他们记录到了全球首例完全由 AI Agent（智能体）自主完成全部攻击链的勒索软件事件，并将攻击者命名为JADEPUFFER。

这个标题里的每个字都不是修辞手法——是字面意思。

这不是一次普通的"AI 辅助攻击"

先搞清楚一个常见的误解。过去两年我们听到的所谓"AI 攻击"，绝大多数属于以下几种情况：

• 攻击者用 ChatGPT 写钓鱼邮件（AI 辅助生成内容）
• 用 AI 工具辅助漏洞挖掘（AI 辅助分析代码）
• 用 AI 生成的变种绕过杀软检测（AI 辅助绕过）

这些本质上还是人用工具——AI 是武器，人是握着武器的那个。

JADEPUFFER 不一样。

从它攻入第一台服务器的瞬间开始，到加密 1342 条数据库配置、留下勒索信息、甚至自己在 31 秒内完成错误修复——全程在智能体的自主决策链下执行。人类在整个攻击过程中只需要做一件事：把 AI 指向公网上暴露的 Langflow 服务。

之后，没有人在键盘前。

JADEPUFFER 的攻击过程：一台 AI 如何"自学成才"

Sysdig 的报告中披露的细节值得多说几句，因为它的每一步都指向同一个方向：AI 的攻击能力正在走向"完全自主"。

第一步：入口——一个你没更新的漏洞

攻击的起点是Langflow。这不是什么冷门软件——它是一个流行的开源 LLM 应用开发框架，你在用的很多 AI 应用背后可能就挂着它。

漏洞编号 CVE-2025-3248，一个老熟人——2025 年就被 CISA 列入"已知被利用漏洞"名单。但就像所有老熟人一样，太多人没把它当回事。公开暴露在互联网上的 Langflow 实例中，大量没有升级到 1.3.0 修复版本。AI 扫描到这些实例后，直接通过无需认证的远程 Python 代码执行获得了控制权。

你可能会说：这不就是自动化扫描吗？

别急。

第二步：侦察——AI 开始"翻抽屉"

拿到主机权限后，按照老剧本，"攻击者"会按照预设好的脚本一步一步执行。但 JADEPUFFER 的侦察过程展示了一种任务驱动的自主探索行为：

它开始扫描主机中的敏感信息，包括：

• OpenAI、Anthropic、DeepSeek、Gemini 等大模型 API 密钥
• 阿里云、腾讯云、华为云、AWS、Google Cloud、Azure 等云平台登录凭证
• 数据库账号、配置文件
• 加密货币钱包及助记词

注意这些目标的选择——这不是脚本的随机行为，而是 AI 自己判断"这些信息的价值最高，优先收集"。

第三步：横向移动——默认密码是 AI 最好的朋友

这里展现了 AI 攻击中最让人后背发凉的一点：它对运维人员的常规"安全漏洞"了如指掌。

JADEPUFFER 用 MinIO 对象存储的默认密码minioadmin成功登录——是的，还是有人在用出厂默认密码。

登录后它下载了包含访问密钥的配置文件。接着它在服务器上创建计划任务，每 30 分钟主动连接攻击者的 C2 服务器——这一步确保即使漏洞被修复，它仍然可以通过"后门"保持访问。

第四步：跨系统控制——AI 开始"演"真正的黑客

完成初始侦察后，JADEPUFFER 将目标转向另一台生产服务器——运行 MySQL 数据库和阿里巴巴开源配置中心 Nacos。

这里整个过程简直是一场教科书式的攻击演示：

• 用数据库 Root 账号（是的，又是 Root）登录 MySQL
• 利用 Nacos 漏洞 CVE-2021-29441 —— 一个 2021 年的漏洞，5年没修
• 配合从未修改过的默认 JWT 签名密钥，成功获取 Nacos 管理权限
• 在数据库中植入隐藏管理员账号，实现对配置中心的完全控制

第五步：自主错误处理——这是最致命的能力

在整个攻击过程中，最让我印象深刻的不是它做了什么，而是它怎么处理做错的事情。

Sysdig 观察到一次令安全研究员都感到"不安"的自主行为：

当 AI 第一次尝试在 Nacos 中创建管理员账号时，操作失败了。一般的自动化攻击脚本会在这里失败、停止、留一堆日志。

但 JADEPUFFER 在31 秒内完成了以下操作：

• 分析错误原因
• 重新生成密码哈希
• 删除失败账号（避免留下残留痕迹）
• 重新创建管理员
• 验证新账号可以成功登录

整个修复过程完全自动完成。没有人类介入。

研究团队统计，此次攻击累计执行了超过600 个具有明确目的的攻击载荷，且 AI 多次根据实际执行结果调整后续策略。

讽刺的结局：AI 自己把自己锁在了门外

最后，也是最黑色幽默的部分。

在勒索阶段，JADEPUFFER 用 MySQL 的AES_ENCRYPT()函数加密了 Nacos 中全部 1342 条配置数据，删除原始配置表和历史记录表，创建勒索留言。

但 Sysdig 发现了一个致命问题：

AI 在生成加密密钥后，只输出到终端了一次，没有保存也没有上传给攻击者。

这意味着什么？意味着即使受害者真的支付了赎金，攻击者也无法解密数据。因为密钥只存在于 AI Agent 运行时的一次性内存中，一旦进程结束，密钥就永远消失了。

AI 把自己也锁在了门外。

这个细节比任何技术报告都更能说明当前 AI Agent 的真实水平：能力很强，但离"可靠"还差得很远。

这到底意味着什么？

如果只把 JADEPUFFER 当作又一个安全事件来看，就错过了更大的图景。

对网络安全行业

过去几年，安全行业的叙事一直是"AI 会让攻击变得更智能"。JADEPUFFER 证明了这不是未来的预测——它已经发生了。

攻击门槛被大幅降低。以前一个能够完成端到端勒索攻击的攻击者，需要熟悉：

• 漏洞利用技术
• 系统横向移动
• 凭据窃取
• 持久化控制
• 数据库操作
• 反取证

现在，一个不需要太多技术背景的人，只需要一个目标（暴露的 Langflow 实例）和一个配置好的 AI Agent。剩下的，AI 自己完成。

对运维/安全团队

JADEPUFFER 的整个攻击路径中，没有用到一个 0day。全部是已知漏洞、默认密码、不当安全配置的组合。

这意味着什么？

• CVE-2025-3248（Langflow）：2025 年已修复，CISA 列入黑名单
• CVE-2021-29441（Nacos）：2021 年已修复
• MinIO 默认密码：出厂时就有配置指引
• JWT 默认签名密钥：文档中明确说明要更换
• MySQL Root 权限暴露公网：安全基线的常识

换句话说，80% 的攻击成功归因于被忽视的"安全基础卫生"。

如果你的系统配置全是默认的、漏洞不修的、Root 权限对外暴露的——你会是 JADEPUFFER 下一轮扫描的完美目标。

对 AI 产业发展

JADEPUFFER 的出现带来一个更深层的问题：

当 AI Agent 可以自主完成攻击行为时，责任归属在哪里？

如果你部署了一个 AI Agent，它在没有得到你明确指令的情况下自主发起了勒索攻击——你是"攻击者"还是"受害者"？或者说，监管的视角会怎么定性？

安全问题正在从"技术挑战"变成"治理挑战"。

给你的行动清单

Sysdig 在报告最后给了一组建议：

• 升级 Langflow 到最新版本——如果你还在用暴露在公网的老版本，现在就去改
• 不要把 Langflow 的代码执行接口直接放在公网上——这是基本的安全设计
• 更换所有组件的默认密码/密钥——包括 Nacos 的 JWT 签名密钥、MinIO 的默认密码
• 不要用数据库 Root 账号对外提供服务——中间表、只读账号这些基础知识在 AI 时代变得更关键了
• 加强运行时行为检测——AI 发起的攻击与人类不同的一个特征：它会产生大量有明确目的的攻击载荷
• 限制服务器的对外通信能力——JADEPUFFER 每 30 分钟连接一次 C2 服务器，如果你的服务器根本不对外发连接，这一步会暴露

最后说一句

JADEPUFFER 不是第一个 AI Agent 攻击者，也绝不会是最后一个。

Sysdig 在报告的最后说了一句话：

"JADEPUFFER 最大的意义在于证明 AI Agent 已能够自主串联漏洞利用、权限提升、凭据窃取、横向移动、持久化控制及勒索破坏等多个环节，从而显著降低实施勒索攻击所需的技术门槛。"

翻译成人话就是：以前需要"黑客技术"才能做的事，现在只需要"会用 AI"。

如果你对 AI 安全的话题感兴趣，可以看看最近同一时期的另一个相关事件——阿里内部全面禁用 Claude Code 的消息。Claude Code 被曝存在植入后门的安全风险，这跟 JADEPUFFER 指向的是同一个问题：AI 的能力越强，它可能造成的破坏就越大。而且，这种破坏不一定是出于恶意——它可能只是 AI 自己做出的"最优决策"。

这道题目前没有人有标准答案。但开始正视这个问题的人，会活得久一点。