AI网关成入侵跳板：一次失守可连带泄露模型与云密钥

微软安全研究团队在2026年8月26日披露，攻击者已把暴露的LiteLLM网关、RAGFlow部署和Kestra工作流环境变成进入企业AI基础设施的跳板。微软公布的三起入侵调查 记录了凭证窃取、数据库访问、容器探测、持久化和加密货币挖矿，并显示这些平台可能在同一运行环境内集中模型提供商密钥、数据库连接信息与云端凭证。

一次失守因而可能同时危及模型侧资产和云资源：这里的“模型泄露”主要指模型提供商API密钥、代理虚拟密钥、模型配置与端点元数据，现有公开证据并未证明模型权重或训练数据被盗。8月27日的 独立安全报道 也确认这是三起不同产品的真实入侵，而非只存在于实验环境中的漏洞演示。

攻击链为何会从公开入口延伸到云端

三起事件的入口和载荷并不相同，但都沿着一条共同链路推进：发现暴露的应用表面，在服务进程或工作进程中执行命令，读取该运行环境能够访问的秘密，再建立持久化并利用凭证或主机算力。放大损失的关键不是“AI”标签本身，而是网关、检索平台和编排服务往往同时拥有网络入口、执行能力及下游连接权。

1. 入口：攻击者接触可从互联网访问的网关、检索服务或工作流接口，利用脆弱版本、认证绕过或过度暴露的管理面。
2. 执行：恶意命令从AI应用进程或worker进程派生，调用shell、Python、下载工具或恶意工作流。
3. 凭证读取：载荷检查进程环境、应用配置、数据库记录及其他容器的环境变量，寻找API密钥、令牌、密码和连接字符串。
4. 持久化：攻击者修改SSH授权密钥、定时任务、应用启动路径或文件属性，使植入代码在重启后仍可能运行。
5. 利用：窃取的凭证可支持模型调用、数据库访问或云资源操作；LiteLLM和Kestra案例还出现了挖矿活动。

这条链也决定了调查不能停在HTTP访问日志。AI服务父进程异常派生bash、sh、Python、curl或wget，随后读取秘密、修改启动文件并连接异常外部地址，才构成更完整的入侵轨迹。

LiteLLM失守后，数据库扩大了泄露范围

LiteLLM案例中，研究人员以高置信度判断初始访问来自暴露的网关表面，并认为路径与CVE-2026-42271及CVE-2026-48710组成的公开漏洞链一致；这一表述仍是研判，并非对唯一入口的最终证明。可以确认的是，后续shell和Python命令直接从LiteLLM网关进程上下文启动。

攻击载荷读取网关进程环境，筛选模型提供商API密钥、LiteLLM主密钥、数据库连接字符串、界面凭证、令牌和密码。取得数据库连接信息后，攻击代码又访问Azure Database for PostgreSQL中的LiteLLM后端表，收集模型配置、上游密钥材料和代理签发的虚拟密钥，并把结果编码后外传。

第二阶段二进制文件被写入临时目录，以近似系统服务的名称运行，并为挖矿做准备。观察到的持久化与防御规避行为包括向服务账户写入SSH公钥、修改定时任务、使用隐藏文件以及设置不可变属性，因此只重启容器或终止矿工进程不能证明环境已经恢复可信。

快速利用并非首次出现。Tata Communications在5月5日发布的 LiteLLM威胁通告 记载，另一项预认证SQL注入漏洞CVE-2026-42208公开后36小时内便出现利用尝试，攻击载荷会枚举数据库并提取API密钥、提供商凭证和配置数据。该事件不是微软8月调查所研判的同一入口，但说明公开网关从披露到被攻击的窗口可能很短。

RAGFlow与Kestra暴露了两种不同的扩散方式

RAGFlow案例的重点不是一次性读取已有密钥，而是拦截以后配置的新密钥。研究人员先观察到疑似SSRF式探测，数日后又在相同服务上下文发现代码执行；攻击者在应用目录放置隐藏Python钩子，并修改启动或导入路径，使钩子随服务加载。

植入代码包裹了TenantLLM凭证配置流程，可捕获后来提交的提供商类型、模型名称、API密钥和端点元数据，并从容器向外发送。公开研究列出了多个可能提供技术背景的RAGFlow漏洞，但此次入侵无法归因于某个特定CVE，因此仅安装一项补丁不足以排除应用代码已被修改。

Kestra案例展示了工作流执行权与Docker访问权结合后的影响。攻击者通过恶意工作流使Java worker派生shell，再经挂载的Docker socket枚举其他运行容器的环境配置，从中寻找潜在的云密钥、数据库密码和API令牌；同一环境还出现XMRig部署以及通过Kestra键值接口保存收集结果的行为。

三种平台由此形成不同的高权限控制点：LiteLLM连接应用、模型提供商与代理数据库，RAGFlow处理租户的模型和知识库配置，Kestra执行任务并可能接触容器运行时。服务一旦被攻陷，原本用于自动化的权限就会成为读取秘密、访问下游系统和滥用算力的通道。

处置优先级：封入口、清驻留，再轮换密钥

对疑似暴露的实例，第一优先级是隔离仍可访问的管理面和API，同时保存网关、端点、容器、数据库、DNS及云审计日志。团队需要核对实际运行版本、认证边界和公网暴露范围，并寻找AI服务进程派生shell、访问进程环境、调用Docker socket或修改应用文件的证据。

第二步是清除持续窃密能力或从可信镜像重建环境。RAGFlow案例尤其说明，如果启动钩子仍在运行，立即换入的新API密钥可能再次被捕获；LiteLLM中的SSH授权密钥、定时任务和不可变文件也要求调查范围越过单个应用容器。

完成入口封堵与环境清理后，轮换范围应按受影响服务的实际可达权限确定，包括：

• 模型提供商API密钥、LiteLLM主密钥和代理虚拟密钥；
• PostgreSQL等后端数据库的连接凭证；
• RAGFlow中感染前已保存及感染后新增的LLM凭证；
• 容器环境中的云访问密钥、服务令牌和数据库密码；
• 受影响服务账户的SSH密钥及可能暴露的服务主体凭证。

最后才是降低再次扩散的结构性调整：把上游密钥移出长期存在的进程环境，改由受控秘密存储按需提供；限制网关数据库账户权限和不必要的出站连接；避免向工作流服务直接挂载Docker socket；在可行时禁止从临时目录执行文件。检测规则应关联父子进程、秘密读取、应用文件修改、异常外联与CPU占用，而不是把这些信号分别作为孤立告警。

已确认的是三起入侵，不是一个统一漏洞

目前公开信息指向LiteLLM、RAGFlow和Kestra三个不同工作负载中的真实攻击活动，而不是一个同时影响三款产品的统一漏洞。LiteLLM与Kestra的初始入口有高置信度研判，RAGFlow的具体执行漏洞仍未确认；不同置信度意味着安全团队不能仅凭CVE清单关闭事件。

公开材料尚未提供受影响组织总数、被盗凭证总量或全部下游滥用结果。可以确认的是，攻击者已在AI服务上下文执行命令、读取或拦截秘密、建立持久化，并在部分环境部署矿工；仍待进一步披露的是受害范围，以及模型提供商和云平台侧是否出现与这些被盗凭证对应的异常调用。