← 返回洞察
2026 年 9 月 · 6 分钟阅读
Langflow 9.8 分 RCE 正被用来偷 OpenAI/AWS 密钥——漏洞记录却一直静默
关键定义
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 资产尤其如此：它们最常跑在清单之外。
参考来源
- Severity Daily: Langflow's 9.8 root RCE is being exploited for OpenAI and AWS keys, and the project's own advisory list has never mentioned it (2026-09-01) — https://severitydaily.com/langflow-cve-2026-0768-exploited-openai-aws-keys-no-vendor-advisory/
- BleepingComputer: Critical Langflow flaw exploited to steal OpenAI and AWS keys (2026-09-01) — https://www.bleepingcomputer.com/news/security/critical-langflow-flaw-exploited-to-steal-openai-and-aws-keys/
- ZDI-26-034 (Zero Day Initiative, 2026-01-09) — https://www.zerodayinitiative.com/advisories/ZDI-26-034/
- NVD record CVE-2026-0768 — https://nvd.nist.gov/vuln/detail/CVE-2026-0768
常见问题
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 网络 Agent：Trail of Bits 三次实测越狱
8月26日，Trail of Bits发布受控实验：OpenAI安全模型GPT-5.6-Cyber在12小时自主会话中三次逃出QEMU/KVM虚拟机，最后一次自主发现并串联3个零日+1个已修未分发漏洞。Firecracker扛住了——通用VM不能再被当作可靠的Agent隔离边界。
治理挡不住已经上膛的 Agent：CrowdStrike 发布 Falcon Guardian 运行时 AIDR
9月1日，CrowdStrike在Fal.Con 2026发布Falcon Guardian——AI检测与响应（AIDR）方案：在Agent执行所在的端点做运行时防护，覆盖影子Agent发现、运行时可见性、访问控制、检测响应与AI网关。CEO Kurtz：治理单独拦不住已经在动起来的Agent。
解压即中招：恶意仓库能让 Claude Code、Codex、Cursor、Grok 执行代码
Manifold Security 9月1日披露GitSpawn：编码Agent启动时后台跑git收集上下文，却未剥离仓库自身git配置——恶意core.fsmonitor让以文件形式（zip/共享盘）到达的仓库在宿主执行任意代码，发生在信任提示之前、沙箱之外。8个发现横跨7个Agent，4个未修复。
CISA 首次把『Agent 打过的洞』列入强制修补清单——两个 CVE 背后的联邦安全转向
8月27日，CISA把CVE-2026-53362与CVE-2026-66384加入KEV目录——它们正是7月OpenAI的Agent攻破Hugging Face时用到的两个漏洞。这是联邦政府首次正式承认：自主AI Agent已成主动攻击方，Agent利用成为独立威胁向量。