OOOMETA/OS
← 返回洞察

2026 年 9 月 · 6 分钟阅读

Langflow 9.8 分 RCE 正被用来偷 OpenAI/AWS 密钥——漏洞记录却一直静默

Langflow CVE-2026-0768：360 次攻击偷 API 密钥

关键定义

CVE-2026-0768 Langflow 自定义组件编辑器 code validator 的代码注入漏洞：攻击者无需认证即可在 validate 端点以 root 权限执行任意代码，CVSS 3.0 评分 9.8，由 ZDI 于 2026 年 1 月以 0Day 形式披露。

EPSS（利用预测评分） 基于全网威胁遥测预测某个 CVE 未来 30 天内被利用概率的评分系统，0 到 1 之间。CVE-2026-0768 的 EPSS 是 0.02338（约 2.3%），评分系统据此把它排在风险队列底部。

记录衰退（record decay） CVE/NVD 记录在披露后长期无人维护的现象：受影响版本停留在单个、无修复版本、无厂商引用，直到某天被利用才重新进入视野。记录本身没有错误，但信息过期到足以误导防御方。

8 月 30 日周日，VulnCheck 的 Langflow 蜜罐开始记录针对 CVE-2026-0768 的利用尝试，数小时内超过 50 次；到周一（8 月 31 日）累计超过 360 次。攻击者从俄罗斯方向而来，直取这台机器上的 OpenAI 与 AWS 密钥。而这一切发生时，按权威来源做漏洞管理的人看不到它——这个 9.8 分的 root RCE 不在厂商 advisory 里、不在 CISA KEV 里、EPSS 只有 2.3%。

攻击者在找什么：这台机器天生是密钥仓库

看攻击请求在捞什么，就知道写 payload 的人懂 Langflow。VulnCheck 威胁研究副总裁 Caitlin Condon 列出的清单：LANGFLOW_SUPERUSER（平台自己的超级用户凭据）、OPENAI_API*（OpenAI API 密钥）、AWS_ACCESS* 与 AWS_SECRET*（云访问密钥），还读取 /root/.cache/langflow/secret_key、检查 .ssh 访问与 .bash_history 大小。

这不是随便一个 botnet 想要的东西，而是一台 Langflow 部署恰好会持有的那一组密钥。原因在部署模型里：Langflow 是低代码的 LLM 应用构建平台，可视化编辑器必须暴露在网络接口上供人使用；而它构建的 flow 需要调用模型 API、读写数据源——所以跑 Langflow 的机器，几乎按构造就持有模型提供商的 API key 和云凭据。在这台机器上拿到 root 权限，等于打开了你 AI 支出的钥匙盒，很多时候还连着你的云账号。

漏洞本身：一条 13 个月前就该修完的链

机制不复杂。CVE-2026-0768 位于 Langflow 自定义组件编辑器的 code validator：validate 端点把用户提交的字符串没做校验就用来执行 Python 代码——无需认证，直接以 root 执行。ZDI 的官方描述是"远程攻击者可在受影响安装上执行任意代码，利用无需认证"。

时间线却很难看：ZDI 于 2026 年 1 月 9 日以 0Day 形式发布（ZDI-26-034），而研究报告早在 2025 年 7 月 18 日就交给了厂商——发布时距报告已近六个月，如今超过十三个月。CVSS 3.0 9.8，AV:N/AC:L/PR:N/UI:N——网络可达、无需认证、无需交互。

这也不是 Langflow 第一次出事：8 月 28 日，IBM 以"IBM Langflow OSS"名义披露了另外三个代码执行漏洞，影响 1.0.0 到 1.11.1，修复在 1.11.2；3 月还有攻击者在披露后一天内就用 CVE-2026-33017 收割 .ENV 和数据库文件。

为什么漏洞管理体系看不见它

把防御方用来分诊这条漏洞的每个信号过一遍：

NVD 记录：一个版本，无修复，一个引用

记录自 2026 年 6 月 17 日后未修改。受影响软件只有 1.4.2 一个版本，其余全标 unknown；没有固定版本，所以补丁队列里不会出现升级项；唯一引用是 ZDI advisory。

厂商 advisory：查无此洞

Langflow 自己的 GitHub Security Advisories 列了 10 个公告，多个是同类关键未授权 RCE——但没有一个是 CVE-2026-0768。它有公告流程、反复用过，唯独没用在这一次。

CISA KEV：不在，没有合规时钟

NVD 记录里没有 cisaExploitAdd，没有联邦修复截止日。

EPSS：2.3%

预测 30 天内被利用概率仅 2.3%，被风险评分队列排在接近底部——而就在这个分数有效的同时，VulnCheck 蜜罐两天记录了 360 次利用尝试。

这不是哪条记录写错了——上面没有一条是假的。问题在于记录在 1 月由第三方披露写成一次，6 月之后再没人更新。按例外维护的记录会安静地腐烂，而腐烂在有人开始利用它之前是看不见的。一个认真用工具做漏洞管理的团队，只依赖权威来源，这周不会把这条漏洞摆在面前——而它偏偏就是正在被用来打他们的那一条。

这不是模型攻击，这是 AI 基础设施攻击

把这条新闻放进 AI 安全叙事的正确位置：没有模型逃逸、没有提示注入、没有 Agent 行为失控。就是一个老旧的、未修补的 Web 漏洞，跑在一个没人放进资产清单的工具上，用来读环境变量。这是过去两年反复预警的"AI 基础设施沦陷"以一种最平淡的方式落地了——平淡，恰恰是它危险的原因。

也要对规模保持诚实：一切关于利用的信息来自一家公司的蜜罐。360 次是探测量的度量，不是失陷量的度量；没人公布过实际被攻破的 Langflow 实例数量，厂商没有发声。把利用当成真实、把规模当成未测。

三步行动

先找到实例，它们通常不在资产清单里

Langflow 常以数据科学便利工具的形式出现，跑在个人账号下，被暴露出来让同事能打开编辑器。查默认端口的监听，查带 LANGFLOW_ 环境变量的主机。

升级到 1.11.6 以上，并自行验证

报道称 1.11.6 修复了它，但主要记录未确认——升级后验证，别假设。独立于这个 CVE，1.11.2 是 IBM 披露的三个代码执行漏洞的修复版本，所以任何低于 1.11.6 的部署在多项上落后。

升级前限制可达性

接受 ZDI 的缓解建议：限制与受影响产品的交互。任何配置下 Langflow 都不该暴露在公网上——利用流量正从外部无认证地到达。

底线判断

对安全团队，这条新闻的教训不是"又一个要打的补丁"，而是漏洞管理管道本身有个洞：一条正在被利用的 9.8 分 RCE，可以同时缺席厂商 advisory、KEV 和高 EPSS。把它当作校验信号——如果你的分诊只信权威来源，你就和所有只信权威来源的人一样，对这周正在发生的事一无所知。AI 资产尤其如此：它们最常跑在清单之外。

参考来源

常见问题

CVE-2026-0768 是什么？+

Langflow 的未授权远程代码执行漏洞：自定义组件编辑器的 validate 端点把用户提交的字符串直接当 Python 代码执行，无需认证、以 root 权限运行。ZDI 在 2026 年 1 月 9 日以 0Day 形式披露，CVSS 3.0 评分 9.8。

攻击者在偷什么？+

VulnCheck 蜜罐记录的请求在查询 LANGFLOW_SUPERUSER、OPENAI_API*、AWS_ACCESS*、AWS_SECRET* 等环境变量，读取 /root/.cache/langflow/secret_key，并检查 .ssh 访问与 .bash_history 大小——典型的侦察加凭据收割，目标就是 Langflow 主机上天然持有的模型 API 密钥与云凭据。

为什么说漏洞管理体系看不见它？+

NVD 记录只列了 1.4.2 一个受影响版本、没有修复版本、只有一个引用，且自 2026 年 6 月 17 日后未再更新；Langflow 自己的 GitHub 安全公告列了 10 个 advisory，却不包含这个；它不在 CISA KEV 目录，没有联邦修复截止日；EPSS 只有 2.3%，风险排序会把它压在底部。按权威来源做漏洞管理的人本周看不到它。

影响哪些版本？修复了吗？+

NVD 记录只写了 1.4.2 一个版本，其余标为 unknown。报道称修复版本是 1.11.6，但没有任何主要来源确认这一点。另外 IBM 8 月 28 日披露了 Langflow 另外三个代码执行漏洞，影响 1.0.0 到 1.11.1，修复在 1.11.2。所以低于 1.11.6 的部署在多项上落后，升级后要自行验证。

为什么 Langflow 主机特别危险？+

Langflow 是低代码 LLM 应用构建平台，默认开在网络接口上供人使用可视化编辑器；它构建的 flow 天然需要模型供应商 API key 和云凭据——所以这台主机几乎必然持有你组织里 AI 支出的钥匙，常常还连着云账号。root 级 RCE 在这里不是普通的服务器失陷，而是直接拿到密钥仓库。

现在该做什么？+

先在资产清单外找 Langflow 实例——它常以数据科学便利工具的形式跑在个人账号下，检查默认端口监听与带 LANGFLOW_ 环境变量的主机；升级到 1.11.6 以上并验证；升级前按 ZDI 的建议限制可达性——任何配置下 Langflow 都不该暴露在公网上。

相关文章

AI 网关只告诉你请求去了哪，JetStream 回答它该不该发

JetStream Clearance 把零信任的信任边界从身份下移到单次动作：AI Blueprints 契约 + 参数级权限 + 序列检测，在 MCP 调用执行前逐动作授权。网关已成商品，授权引擎是下一个战场。

审查过的 MCP 工具在第四次调用开始背叛你：Deadbugz 的运行时门控投毒

Pillar Security 披露活跃 MCP 供应链活动 Deadbugz：恶意服务器伪装成文本格式化工具，前三次调用一切正常，第四次起改写返回的工具元数据，指示 agent 搜寻 SSH 密钥、AWS 凭证并隐藏行为。一次性审查被系统性绕过——工具描述是运行时安全边界，批准应发生在动作执行之时。

AI Agent安全信心悖论：82%高管自信，仅14.4%获完整审批

Gravitee对900多位高管与工程师的调研显示：82%高管相信现有策略能防住未授权Agent行为，但仅14.4%的Agent获得完整安全审批上线，88%企业已遭遇或疑似遭遇安全事件。可见性与身份是最大短板。

AI Agent安全2026：采用速度超过控制力

AI Agent 采用速度已超过控制力：Gravitee 对 900+ 高管的调查显示，81% 团队已进入测试或生产，仅 14.4% 的 Agent 上线前获得完整安全审批，88% 企业去年遭遇 Agent 安全事件。身份是薄弱环节，决策者需要从手动审计转向身份感知强制。