AI 勒索软件来了?先别慌关掉你那几个没人管的旧后台!

如果你有一台云服务器，上面跑过测试项目、AI 工作流、数据库面板，后来业务忙起来就没再细管，这篇比“AI 黑客来了”更值得看。

周一早上，你打开数据库查订单。

原来的业务表还在，但旁边多了一张陌生的表：README_RANSOM。

表里不是订单，而是一段勒索说明、一个比特币地址、一个 Proton Mail 联系方式。

更糟的是，你回头查日志，发现它不是从某个电影里的黑客界面进来的。最开始只是一个暴露在公网的 AI 工具后台，后面才一路摸到配置、凭证和数据库。

这就是 JADEPUFFER 这件事最该让小团队警惕的地方：AI Agent 没有发明新魔法，它只是把几扇早该关上的旧门，一扇一扇串了起来。

安全公司 Sysdig 观察到的这个样本，重点不在“AI 多神”。更该看的，是 LLM agent 把侦察、漏洞利用、凭证搜索、数据库勒索这些步骤连成了流程。

你的旧后台、默认密钥、数据库 root 和没演练过的备份，正在变成它最容易串起来的门。

第一扇门，是暴露在公网的 AI 工具

JADEPUFFER 的入口是 Langflow。

Langflow 常被用来搭 LLM 应用和 Agent 工作流。很多人会把它理解成“拖拽式 AI 流程工具”：接模型，接组件，接外部服务，然后跑一个自动化链路。

问题是，这类工具一旦出现在公网，就不只是开发便利了。

Sysdig 指向的入口漏洞是 CVE-2025-3248。说成人话，就是某个代码验证端点缺少认证，外部未登录的人也可能让服务器执行 Python。对攻击者来说，这已经像拿到了一个可以试命令的遥控器。

这一步离普通用户并不远。现在很多小团队为了省事，会把 AI 工具、数据库面板、自动化后台、可视化配置平台开到公网。

理由通常也很朴素：方便远程调试，方便客户演示，方便手机上看一眼。

安全事故经常就从这些“方便入口”开始。AI Agent 加进来后，变化不在于漏洞突然变多，而在于旧漏洞被发现、试探、串联的速度变快了。

过去攻击者可能要自己写一堆步骤。现在如果工具链足够成熟，Agent 可以在有限目标下继续往前试：这个端口能不能连，这个服务是不是旧版本，这个配置中心有没有默认密钥，这个数据库凭证能不能复用。

AI 没有发明新的安全原则，它只是让旧问题更不耐拖。

它没有停在第一台机器上

如果攻击只停在 Langflow，本质上是一个 AI 工具暴露事故。

JADEPUFFER 麻烦在后面。

Sysdig 的报告显示，攻击目标后来指向另一台暴露在公网的生产服务器，那里跑着 MySQL 数据库和 Alibaba Nacos 配置服务。

Nacos 可以粗略理解成系统里的“配置中控台”。很多微服务系统会把服务地址、配置项和运行参数放在这里。

如果它被接管，攻击者未必马上看到全部业务数据，但很可能拿到继续往里走的线索：数据库地址、服务密钥、内部接口、环境变量、账号配置。

这次攻击里，载荷尝试了 Nacos 的多种路径，包括和老认证绕过、默认密钥有关的问题。后面，攻击者还用 root 凭证连接了暴露的 MySQL。Sysdig 没有确认这些凭证最初从哪里来，但能确认的是，数据库最后成了勒索对象。

这就是 AI Agent 攻击和普通漏洞扫描的差异之一：它不满足于“我发现你有漏洞”，它还会继续试“这个漏洞能把我带到哪里”。

对小团队来说，最容易忽略的正是这种链式风险。

你以为自己只是开了一个测试工具。实际情况可能是：测试工具能读环境变量，环境变量里有数据库地址，数据库账号权限过高，配置中心又能暴露更多服务信息。

每一环单看都像“先这样吧”，串起来就是事故。

勒索最爱利用的，是没收口的权限

JADEPUFFER 后面的勒索动作很直白：连接数据库，操作业务表，创建勒索表，留下联系方式和支付地址。

报告里还提到，勒索说明里的加密说法和实际 MySQL 函数细节并不完全一致。这个细节很有意思：攻击者的话术不一定严谨，但造成的破坏已经足够真实。

普通用户看这类新闻，容易把注意力放在“AI 到底有没有自主攻击能力”。

站在防守侧，更该先问：它拿到的权限是不是太大了。

如果一个数据库账号只是只读，攻击者能做的事会少很多。

如果这个账号不能删表、不能改表、不能创建事件、不能访问敏感库，勒索链路就会被卡住。

如果配置中心不在公网，或者需要额外认证，攻击者就算打进第一台机器，也不一定能继续扩散。

安全里有个老原则叫最小权限。它听起来不刺激，但 JADEPUFFER 这种案例恰好说明，老原则没有过时，反而更重要了。

因为 AI Agent 擅长的不是突然发明一种人类没见过的魔法，而是快速尝试大量常规路径。只要你给它一个能执行命令的入口、一个权限过大的账号、一组没轮换的密钥，它就有机会把这些东西拼成攻击链。

“我只是个人项目”也不是理由。个人项目里常见的坏习惯，在小公司里同样常见：数据库 root 账号到处用，测试环境和正式环境共用密钥，后台页面临时开放公网，云服务器安全组写成全开放，备份从来没演练过恢复。

这些问题过去也会出事。区别在于，过去可能拖很久才爆；现在自动化会把拖延成本抬高。

普通人先查有没有高风险问题

看到 AI 勒索软件，很多人第一反应是问：我会不会被这种高级攻击盯上？

这个问题可以先放一放。比起问“会不会被盯上”，更该先看自己有没有留下低门槛入口。

可以从五个地方查起。

公网入口。 把自己的云服务器、NAS、数据库、自动化面板、AI 工具后台列一遍。凡是能从公网访问的，都问一句：它真的必须开给全世界吗？如果只是自己用，优先放到 VPN、内网、白名单或临时隧道后面。

旧版本组件。 Langflow、Nacos、数据库面板、低代码平台，只要放在公网，就不能靠“能跑就行”。版本、补丁和已知漏洞要有记录。

凭证位置。.env、配置文件、日志、部署脚本里有没有数据库密码、云服务 key、API token？不提交到 Git，不代表本地工具和被打进来的程序看不到。

数据库权限。 业务服务是不是还在用 root？读、写、删表、建表、改表是不是全混在一个账号里？自动化脚本需要什么权限，就给什么权限。

备份恢复。 有没有备份不重要，能不能恢复才重要。抽一份备份，在新环境里恢复一次，才知道它是不是心理安慰。

这五件事不酷，但比转发“AI 黑客来了”有用。

今天就能做一个 30 分钟版本

五扇旧门都查一遍，当然最好。但如果今天时间不够，先做一个 30 分钟版本。

1. 列出所有公网入口，关掉不必要的。 2. 给数据库新建只读账号，替换掉脚本里的 root。 3. 随便抽一份备份，在新环境里恢复一次。

这三步做完，再讨论更复杂的安全系统。

防守也要看过程，不只看结果

JADEPUFFER 给出的另一个提醒，是防守不能只盯最后结果。

过去很多团队只看：数据库有没有被删，服务有没有宕机，告警有没有响。

如果攻击链由 Agent 推进，过程里的小动作也要被看见。

单个动作可能不像事故，连起来才是事故前奏：有人访问能执行代码的接口，异常运行 Python，扫描配置服务，尝试数据库连接，最后在库里创建可疑表。

小团队不一定要立刻买复杂安全平台，但至少先留三类记录：公网服务访问记录、关键配置变更记录，以及数据库高危操作记录。

尤其是数据库里出现建表、批量更新、加密函数、大量导出、异常登录来源时，不能等到业务报错才发现。

如果你已经在用 AI 编程助手或自动化 Agent，还要多一条规则：不要让它直接接触生产密钥。

让 AI 写脚本可以，让它解释日志可以，让它帮你整理排查清单也可以；但涉及数据库 root、云平台主账号、支付接口、客户数据导出，必须隔离。

一个实用做法是给 AI 准备“沙盒身份”：只读账号、测试数据、临时 token、明确过期时间、执行前人工确认。

不管是开发、运维还是业务负责人，接入 AI 自动化时都要多问一步：它能访问哪里，关键动作谁确认，失败后怎么回滚。

谁设计流程，谁就要设计停止点。

下次看到 AI 攻击新闻，先看它串起了哪几个风险

JADEPUFFER 不该被读成“AI 勒索软件已经全面取代人类黑客”。

这个结论太大，也没必要。

更稳的判断是：AI Agent 正在把攻击链里那些重复、试探、枚举、组合的步骤变得更便宜。它不会让安全原则失效，但会惩罚长期没处理的旧问题。

如果一家公司暴露了旧版本工具、配置中心、数据库端口和高权限凭证，过去也危险。区别在于，过去可能需要攻击者更有耐心；现在自动化可以替他把很多耐心变成流程。

如果你正在搭任何 AI 自动化工作流，也按同样方式收口：输入只给测试数据，输出先停在草稿或报告，关键步骤必须有人确认；日志要能看到它访问了哪些服务，失败后要能重试或回滚。

没有这些检查点，就不要把它接到真实后台。

以后看到任何“AI 攻击”新闻，可以先问一个问题：它到底发明了新能力，还是把几扇早就该关的旧门串了起来？

如果答案是后者，就别先恐慌，今天少留一扇门就已经有用。