安全团队最怕的场面往往发生在通告出来以后群里开始翻旧账“这套系统谁搭的”“谁在用”“连了哪些库”问了一圈没人能马上给出准确答案。JADEPUFFER 作为全球首例全自动 AI 勒索攻击它盯上的入口是暴露在公网的Langflow实例。攻击者利用漏洞拿到入口后开始翻配置、找密钥、碰云凭据、扫内部服务最后把目标推向生产服务器和数据库。真正扎心的地方在这里攻击链上的很多环节本来就是企业自己先跑起来、后来没人持续收口的 AI 应用和连接关系。平时看着只是临时服务、测试接口、方便排查到了攻击链里就都成了通路。不是 AI 突然觉醒而是工具变得更勤快此次事件的突破口是一套暴露在公网的开源 Langflow 实例。作为大模型流程搭建工具研发拿它接模型、接API接口、接数据库确实极其顺手。但“顺手”的代价是它瞬间成为了一个高价值的拓扑连接点。一个平台只要能连通万物它就不再只是开发辅助工具——它手里握着API Key、数据库连接串和配置文件。平时游离于安全视野之外真被打的时候它就是天然的攻击链入口。图源https://www.cve.org/CVERecord?idCVE-2025-3248事件档案突破口公网暴露的 Langflow 实例漏洞利用JADEPUFFER 利用的是 CVE-2025-3248后续披露的 CVE-2026-33017 同样指向 Langflow 未认证远程代码执行风险影响1.9.0 之前版本。横向移动读取本地配置 → 搜寻凭据 → 连接内部数据库 → 推进勒索核心演进攻击过程具备自动试错、结果修正、链式推进的 Agent 特征所以这事不用神化。它不像科幻片里 AI 自己觉醒了更像一个老入口被一个更勤快、更不怕失败的工具反复敲门。以前可能是人带着脚本慢慢试现在可以把一部分试错交给 Agent 跑。多数影子资产死于“赶进度”在企业内部多数 AI 应用最初都不是按正式系统建设的。为了赶项目研发临时搭建一个平台为了看效果业务先开一个测试服务为了调参数端口先放开几天。它们的标签通常很朴素test、internal、demo。但在实战对抗中最脆弱的边界往往就是“临时”。临时系统没人长期盯防临时账号没人及时回收临时开放的策略没人记得关闭。AI 应用平台的风险是在一次次接入中野蛮生长的先接模型再接知识库接着对接工单系统最后连通生产数据库。功能一路上线安全边界却停在原地。攻击者不需要多高明的技术他们只是在赶进度留下的废墟里抢先翻出了这些无人认领的入口。Agent 不嫌烦运营侧最怕“碎片化”扫公网、打旧漏洞、读配置、连数据库这些动作本身并不新鲜真正改变的是节奏与密度。人会累脚本会断但AI Agent不会。它可以根据安全设备的阻断反馈实时调整下一步失败了换个方向再失败就继续重试。它不需要绝对聪明只要足够快、足够耐心就能把数个分散的小漏洞串联成一条致命的单向攻击链。防守侧最头疼的正是这种碎片化误判Web 侧捕捉到一次轻量级异常请求主机侧看到一次常规命令执行数据库侧出现一次短暂的异常连接。在系统日志中每个单点告警的风险评分都不够触发高危预警。当安全设备各说各话、告警各响各的上下文链路一旦断开复盘时连真实的攻击路径都无法还原。该补的不是口号是验证这件事最后还是会落回一个老问题我们以为有防护和防护真的有效是两码事。AI 应用平台有没有进资产清单暴露面扫描能不能发现它它一旦被打命令执行、配置读取、凭据访问有没有日志留下数据库出现异常连接时入口、账号、主机和数据库几段上下文能不能接起来封入口、换凭据、确认影响、复测验证这几步能不能跑完整。这些都不是写在制度里就算数的事。更实在的做法是把这类场景放进验证清单。不是等攻击者来了再复盘而是提前用接近真实的路径跑一遍。看入口能不能被发现告警能不能出现分析人员能不能读懂上下文处置动作能不能落下去。跑完以后安全团队手里就不只是“已经排查”四个字而是一组能拿出来说明问题的结果哪些环节看得见哪些环节接不上哪些规则要补哪些流程要改。这样的结果比一张打勾表更有用。AI 应用也要进清单AI应用、Agent流程、插件服务只要触碰了业务系统持有了真实凭据它就不再是“临时服务”。研发总觉得这只是个测试。但从技术指标上看入口能不能发现、异常调用有没有告警、后续处置能不能闭环这些实打实的对抗数据比一张纸面上的上线审批表更能说明问题。说白了AI本身不是威胁的根源那些没人负责、无法溯源的小入口才是。与其等攻击者哪天摸进来帮你“清点资产”不如老老实实把这些有权限的组件先塞进验证清单里测了再说。