2026年8月26日，微软安全研究团队披露3起已经发生的AI基础设施入侵，目标分别是LiteLLM网关、RAGFlow检索增强平台和Kestra工作流环境。攻击者的目的不是“让模型答错”，而是盗取密钥、建立长期控制并利用服务器挖矿。
说明：本文依据微软及相关项目公开的安全公告整理，不是云侦探实测。3个案例也不代表所有安装实例均已失陷，更不能据此认定它们属于同一攻击团伙。
为什么AI基础设施会成为目标
LiteLLM、RAGFlow和Kestra用途不同，却有一个共同点：它们位于用户、业务系统、数据和模型之间，往往集中保存模型厂商API Key、数据库连接信息、租户配置和工作流执行权限。一旦管理面暴露在公网，攻击者拿到的可能不只是一台服务器，而是进入更多系统的控制入口。
LiteLLM：从网关偷密钥，再进入数据库
微软以高置信度评估，初始访问很可能来自对外暴露的LiteLLM网关。现有遥测与CVE-2026-42271和CVE-2026-48710组成的公开利用链相符，但微软没有确认该漏洞链就是此次入侵的确定入口。
进入系统后，恶意程序读取容器进程环境变量，寻找模型API Key、LiteLLM主密钥和数据库连接串；随后访问PostgreSQL中的模型配置和虚拟密钥记录，并部署挖矿程序、写入SSH密钥和定时任务维持控制。
LiteLLM官方安全公告显示，CVE-2026-42271影响1.74.2及以上、1.83.7以下版本，1.83.7已经修复。暂时无法升级时，应在反向代理或API网关阻断相关MCP测试接口。若实例疑似失陷，只升级并不够，还需轮换上游模型密钥、虚拟密钥和数据库凭据。
RAGFlow：具体入口未确认，目标是模型密钥
RAGFlow案例尤其不能写成“某个漏洞已被确认利用”。微软以高置信度判断入口位于暴露的RAGFlow应用面，但对具体利用了哪个漏洞只有低置信度。微软先观察到一次可能的SSRF式回调，数日后同一服务环境出现代码执行，两者不能直接写成已经证实的因果链。
攻击者随后修改应用启动路径并植入隐藏钩子，在用户新增或修改模型配置时，截取服务商、模型名称、API Key和接口地址。RAGFlow官方仓库已公开多项远程代码执行和认证问题，但微软没有把本次入侵归因到其中任何一个。
管理员应核对自身版本与官方公告；不能确认安全状态时，先停止公网访问，检查应用文件是否被修改，并轮换可疑时间点后录入的模型密钥。微软在该案例中没有看到挖矿程序或交互式反向Shell，不能擅自扩大结论。
Kestra：认证绕过后创建恶意工作流
微软以高置信度评估，Kestra入侵很可能利用了CVE-2026-49869。攻击者可绕过认证、创建恶意工作流，并在Kestra worker容器内执行Shell。后续活动包括访问该受害环境中已挂载的Docker套接字、枚举其他容器的环境变量、部署XMRig挖矿程序和收集数据。
Kestra官方公告将1.0.45和1.3.21列为修复版本，对应旧分支应至少升级至以上版本。这里的root权限是worker容器内部权限，不等于攻击者必然取得宿主机root权限；Docker套接字也不是所有Kestra实例默认挂载。
云侦探判断：问题不在“AI”两个字
这3起案例暴露的仍是传统运维问题：管理端口直接上网、密钥集中放在环境变量、容器权限过大和升级不及时。AI网关及编排平台应按核心控制系统保护，而不是按普通开源工具处理。
整改顺序很明确：先把管理面撤出公网或限制到VPN和固定IP；升级至官方修复版本；为不同团队拆分密钥并设置额度；避免不必要地挂载Docker套接字；限制异常出站连接；监控应用进程拉起Shell、读取/proc环境、在/tmp执行文件以及修改cron或authorized_keys等行为。
若已经发现入侵迹象，优先在干净环境重新部署并全面轮换凭据，不要只删除挖矿程序后继续运行。
