AI 基础设施入侵：LLM 网关上的凭据窃取与挖矿

这是什么？

2026 年 8 月 26 日，微软安全研究团队发布了针对三类 AI 工作负载入侵事件的分析：一个 LiteLLM 网关、一个 RAGFlow 部署，以及一个 Kestra 工作流环境。该文由 Yash Gund 与 Sumith Maniath 署名，依据的是从受害主机上采集的 Microsoft Defender 遥测数据。

这份报告的价值不在于攻击的复杂程度——复杂程度其实不高。入口路径因产品而异，但三起事件的目标完全一致，而且相当传统：收集凭据、建立持久化，再用加密货币矿工把主机变现。报告没有点名任何威胁组织，也没有给出国家级归因。这是普通犯罪团伙发现了一类新的暴露目标。

微软把这类目标称为控制点：网关、检索平台与编排服务如今位于用户、应用、数据与模型之间，因而把模型厂商密钥、数据库连接串、租户配置和执行权限集中到了同一个运行时里。

工作原理

网关（LiteLLM）。 初始访问被以高置信度评估为对暴露网关面的利用：MCP stdio 测试端点中的一个需认证的命令执行缺陷，Horizon3.ai 的公开研究将其与 Starlette 的 Host 头校验绕过串联，从而在存在缺陷的部署上达成未认证代码执行。真正值得注意的是后续动作。网关在容器中以 PID 1 运行，因此载荷读取了 /proc/1/environ，并按 master、API key、token、password 等关键词过滤。随后一段自包含的 Python 单行命令从同一环境中解析出 DATABASE_URL，连上后端 PostgreSQL 实例，导出了模型表与虚拟密钥表。输出经 base64 编码后被分成小块外传至带外回连端点。持久化则通过修改 SSH 授权密钥、伪装服务名称与设置文件不可变属性实现；一次 crontab 重写还顺带清除了竞争对手的矿工，然后才装上自己的。

检索平台（RAGFlow）。 微软明确表示，对于究竟是哪个缺陷导致了代码执行，其置信度较低：相关代码路径在 RAGFlow 的 Flask 服务进程内执行，端点遥测无法定位具体的执行落点。公开记录的候选缺陷有多个，包括提示词生成器与智能体工作流组件中的模板注入、某解析器的路径穿越，以及一处沙箱绕过。真正的教训在于后利用行为：攻击者在应用目录树下植入了一个隐藏的 Python 钩子，修改导入路径使其随服务加载，并包裹了租户的 LLM 配置流程。该钩子并不窃取已存储的密钥——它捕获的是管理员随后输入的厂商凭据，覆盖 OpenAI、Azure、Anthropic 与 Gemini 的配置，并抑制报错以让配置看上去成功。此次未部署矿工，目标纯粹是凭据截获。

编排器（Kestra）。 初始访问被以高置信度评估为身份认证绕过。根因是一个教科书级的 Web 应用缺陷，与 AI 毫无关系：认证过滤器用后缀匹配（endsWith("/configs")）而非精确路径比较来放行公开配置端点。由于 Kestra 通过调用方自选的路径片段（命名空间、流程 ID）来寻址资源，任何以该片段结尾的路径都能完全绕过 Basic Auth。这已足以创建并运行一个工作流，而 Kestra 默认自带脚本执行插件。随后是来自 worker 进程谱系的 shell 执行、通过挂载的 Docker 套接字枚举其他可达容器的环境变量数组，以及针对门罗币矿池运行的 XMRig。

微软还指出，若干载荷呈现出常与辅助生成代码相关联的特征：导入整齐、显式超时处理、依赖回退、防御性异常处理、解释性注释。微软谨慎地将其定位为对工具链的观察，而非归因证据，并拒绝就代码作者身份下任何结论。我们以同样的口径转述。

为什么重要

一个 AI 网关的影响半径，比多数资产清单所反映的要大。单个被攻陷的代理就会交出主密钥、它签发过的全部租户虚拟密钥，以及一条通向别处的数据库连接串。模型厂商的账单反而是最小的问题：这些密钥通常意味着能访问组织接入模型的一切。

RAGFlow 这一例最该被记住。凭据轮换是怀疑密钥泄露时的标准动作——但面对一个安装在配置流程中的钩子，轮换反而在主动喂养攻击者。每一把新签发的密钥，都会在输入的那一刻被捕获。因此，针对检索平台或网关的任何应急响应，都必须先确认应用目录树是干净的，再让新密钥靠近它。

最后，Kestra 的缺陷提醒我们：AI 技术栈吸收通用基础设施的速度，快过对这些基础设施重新审计的速度。按后缀做授权判断，是 Web 安全社区二十年前就理解的错误。它在这里之所以变成致命问题，是因为该组件如今挡在模型凭据与容器运行时之前。

防御

盘点并关闭暴露的管理面。 网关、RAG 平台与编排器的管理界面不应可从互联网访问。这一项控制措施本可阻止全部三起入侵。

修补文中提到的组件。 Kestra 的认证绕过已在 1.0.45 与 1.3.21 中修复；更早的版本应视为可被未认证 RCE。同时升级 LiteLLM 与 RAGFlow 至当前版本，并应用上游框架的修复。

把厂商密钥移出进程环境变量。 只有密钥确实在那里，读取 /proc/1/environ 才有回报。改为在调用时从托管密钥库注入；用带消费额度的团队级虚拟密钥替代共享主密钥；并轮换一切曾存在于暴露实例上的凭据——但要在下文的完整性核验之后。

在网关与数据库之间执行最小权限。 用专用服务账号运行代理，把数据库授权收窄到确实需要的对象，并将数据库置于私有端点之后配以严格防火墙规则。导出虚拟密钥表，不应是网关角色能做到的事。

出向流量改为默认拒绝。 只放行必需的模型厂商与服务端点；阻断到裸 IP 地址与非标准端口的直连；让被允许的流量经过按 FQDN 过滤的代理。记录并过滤 DNS——子域编码的信标与带外回连在那里最先可见。

加固主机运行时。 在运维可行的前提下把临时目录挂载为不可执行，对来自全局可写路径的执行告警，并监控 cron 条目、authorized_keys 文件与不可变属性的变更。

在轮换凭据之前先核验应用完整性。 将已部署的应用目录树与导入路径同已知良好的镜像比对，并把凭据配置流程中任何意外出现的钩子，视为暂停轮换的阻断项。

基于关联而非单点事件做检测。 上述任何一步单独看都不足以告警。信号在于链条：应用进程派生出 shell 或解释器，随后访问密钥，随后在临时目录暂存载荷，随后发起外连回调。微软自身的建议是按控制平面角色而非孤立应用来监控 AI 工作负载——并把针对检索平台的任何 SSRF 式探测视为前兆信号，因为在 RAGFlow 一例中，代码执行是在数天之后才发生的。

Status

项目	参考	日期	说明
微软调查报告	Microsoft Security Research	2026-08-26	三类负载：LiteLLM 网关、RAGFlow、Kestra。未作威胁组织归因
LiteLLM MCP stdio 命令执行	CVE-2026-42271 / GHSA-v4p8-mg3p-g94g	—	需认证的命令执行；网关一例中初始访问置信度为高
Starlette Host 头校验绕过	CVE-2026-48710	—	被 Horizon3.ai 公开研究串联，达成未认证 RCE
RAGFlow 候选缺陷	CVE-2026-45312、CVE-2026-28797、CVE-2026-24770、CVE-2025-68700、CVE-2025-69286	—	模板注入、路径穿越、沙箱绕过、账号访问缺陷。低置信度 —— 均未确认为执行落点
Kestra 认证绕过	CVE-2026-49869	—	CVSS 10。公开配置端点的后缀匹配过滤缺陷；已在 1.0.45 与 1.3.21 修复
对应框架	OWASP LLM Top 10（供应链 / 过度代理权限）、MITRE ATT&CK T1190、T1552.001、T1496	2026	利用对外应用 → 从文件获取凭据 → 资源劫持

主要来源的发布日期：2026 年 8 月 26 日。微软对各案例的置信度不同，上表按原文如实转述——LiteLLM 与 Kestra 的初始访问路径为高置信度，RAGFlow 的执行落点为低置信度。