Langflow CVE-2026-0768：今年在野利用的第12个Langflow漏洞

CVE-2026-0768 是 Langflow 中的一个未经身份验证的远程代码执行漏洞，Langflow 是用于组装大语言模型流水线和智能体的开源可视化框架，而到 2026 年 8 月底，攻击者已在野利用该漏洞。该漏洞位于 Langflow 自定义组件编辑器背后的代码验证器中：validate 端点接受一个 code 参数并运行其中包含的 Python 代码，无需任何身份验证，并且用 Zero Day Initiative 的话说，是“在 root 上下文中”运行。VulnCheck 的 Canary 蜜罐网络在 2026 年 8 月 30 日首次检测到后的数小时内记录了 50 多次利用尝试，到 9 月 1 日星期一已超过 360 次，全部针对英国的传感器；VulnCheck 的 Caitlin Condon 表示，源流量主要源自俄罗斯。这些请求并非勒索软件攻击。它们读取保存 Langflow 超级用户凭据、OpenAI API 密钥以及 AWS 访问密钥和秘密密钥的环境变量，随后查找 /root/.cache/langflow/secret_key、.ssh 和 .bash_history。该档案中关于此事件的完整条目，包括其严重性、置信度和危害分类，收录在 Orca AI Incident Archive中，与围绕它的其他凭据窃取和 AI 基础设施记录并列。

Security Affairs 于 2026 年 9 月 2 日发表了其报道；SecurityWeek 的 Ionut Arghire 在前一天报道了该漏洞利用情况，BleepingComputer 的 Bill Toulas 于当周进行了报道，云安全联盟的 AI 安全倡议则于 9 月 4 日随后发布了一份研究说明，重述了该机制并补充了建议。本文所审查的所有报道均未指出有哪个组织遭到入侵。一切线索都可追溯至 VulnCheck 自己的传感器以及零日倡议于 1 月发布的公告。

一个执行其所被要求验证内容的编辑器

Langflow 的卖点在于，你可以通过将组件拖拽到画布上来组装 AI 应用。自定义组件使用 Python：编辑器允许用户粘贴代码并点击验证，然后由服务器进行检查。根据 ZDI 公告 ZDI-26-034，这项检查会运行代码。该公告对根本原因的描述只有一句话——“在使用用户提供的字符串执行 Python 代码之前，缺乏对该字符串的适当验证”——其结果就是，单个未经身份验证的 HTTP 请求即可在主机上执行任意 Python 代码。

三个特性使这成为一起安全事件，而不是一份漏洞报告。CVSS 向量为 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，评分为 9.8：可通过网络访问、低复杂度、无需权限、无需用户交互，且机密性、完整性和可用性完全丧失。执行上下文是 root，这就是为什么 Condon 和 Cloud Security Alliance 都描述的攻击者命令会指向 /root/.cache/langflow/secret_key——Langflow 用来加密存储的凭据和会话数据的文件。而且该端点完全不要求凭据，因此暴露与否仅取决于可达性。

披露历史对这件事的演变很重要。ZDI 的时间线记载：报告于 2025 年 7 月 18 日送达 Langflow 的 GitHub 账户；2025 年 9 月 11 日请求提供更新；2025 年 10 月 10 日请求提供修复；2025 年 12 月 10 日发出拟作为零日漏洞发布的意向通知。ZDI 于 2026 年 1 月 9 日发布公告。致谢的研究人员为 Trend Research 的 Peter Girnus、William Gamazo Sanchez 和 Alfredo Oliveira。GitHub 的安全公告数据库收录了相同文本，编号为 GHSA-x5pr-rvjj-j6qm，发布于 2026 年 1 月 23 日，归类为 CWE-94，且完全未列出受影响版本范围。ZDI 所述缓解措施并不是补丁，而是“限制与该产品的交互”。

公开报告将受影响范围定为 Langflow 直至并包括 1.4.2 的各版本，而后添加的 Metasploit 模块正是针对该版本构建并测试的。确切性到此为止，下文关于修复的章节将说明原因。

360 检测能说明什么、不能说明什么

VulnCheck 的 Canaries 是面向互联网的传感器，被设计成看起来像攻击者正在扫描的目标。该公司于 2026 年 8 月 29 日至 30 日首次发现 CVE-2026-0768 遭到利用：周日几小时内检测到 50 多次，到周一升至超过 360 次。VulnCheck 威胁研究副总裁 Condon 在 LinkedIn 上称该活动是“侦察与凭据收集的混合”，并补充说源流量主要来自俄罗斯，且“迄今为止只击中了英国的 Canaries”。

传感器捕获的命令序列足够具体，可直接当作行动手册。攻击者查询环境中是否存在 LANGFLOW_SUPERUSER、匹配 OPENAI_API 的变量，以及 AWS_ACCESS 和 AWS_SECRET 密钥——这是 Langflow 主机最可能持有的三类凭据。他们读取了 /root/.cache/langflow/secret_key 处缓存的密钥。他们检查了 .ssh 访问权限，并查看了 .bash_history 的大小，这两项都能表明操作者能否横向移动，而不仅仅是读取密钥。云安全联盟引用的一篇社区文章详细描述了这条攻击链，并补充说，同一活动还搜索了源码树和 .env 文件中嵌入的密钥，外泄了发现的内容，并在添加自己的持久化之前检查主机是否已被先前的操作者植入后门。

这所确立的是：该漏洞利用确实有效，它曾被用于针对面向互联网的 Langflow 实例，且目标是凭据而非破坏。它未能确立的是存在受害者。金丝雀是诱饵；一次检测只是一次请求，而非已确认的窃取。该档案将此记录归类为真实危害，而公开来源中记录的危害是：凭据窃取代码已确认针对暴露系统执行——并非某个具名组织的密钥已被使用。

一个细节与关于披露的常见说法相悖。据 VulnCheck 称，在漏洞利用开始之时，CVE-2026-0768 并不存在公开的概念验证。该公告已公开近八个月，并且对漏洞的描述足够精确，足以让人根据文本构建利用程序。正如 The Hacker News 所报道，该公司的解读是，这属于独立推导，而非重复使用泄露的代码。

十二个缺陷，一万五千次尝试——以及这些数字在何处失效

赋予这起事件分量的统计数据来自 VulnCheck，值得用该公司的原话而非转述来引用。该公司表示：“在 2026 年之前，证据显示只有一个 Langflow 漏洞被已知在野外遭到利用。到了 2026 年，情况迅速发生了变化。”SecurityWeek 报道称，VulnCheck 追踪到 2026 年期间“另有 11 个漏洞遭到针对，并被报告为在野外遭到利用”。

把这些加起来，你会得到十二个已被利用的 Langflow 漏洞，其中一个是今年之前就存在的。这与2026年有十二个并不是一回事，而消息来源在两种说法之间摇摆。Forkast 的标题称 CVE-2026-0768 为“Langflow 2026年第12个被利用的CVE”，而同一篇文章的正文则把这十二个描述为“11个新漏洞和一个在年初之前就已识别出的漏洞”。该记录的标题沿用标题的说法。严格解读，2026年占十二个中的十一个，第十二个——也就是今年之前已知的那个——构成其余部分。

15,000 这个数字也有类似的微妙边界。SecurityWeek、The Hacker News 和 Forkast 都将“超过 15,000 次成功攻击”归因于三个具名漏洞：CVE-2026-0769、CVE-2025-3248 和 CVE-2026-5027。这是一个很大的数字，但它是跨三个 CVE 的计数，而不是跨 Langflow 整个 2026 年组合的计数。将其表述为针对该组合的利用尝试——正如该档案的摘要所做的那样——比 VulnCheck 发布的内容范围更广。

这些模式背后的各个条目均有文档记录。根据 Cloud Security Alliance 引用的 GitHub 安全公告 GHSA-rvqx-wpfh-mfx7，CVE-2025-3248 是同一个 /api/v1/validate/code 端点中的代码注入漏洞，Langflow 1.3.0 通过将执行替换为仅编译验证对其进行了修补——这意味着 CVE-2026-0768 是该修复发布约四个月后、同一代码路径中的同一类漏洞。CVE-2026-33017 是公开 flow 构建端点中的未认证 RCE，在其 2026 年 3 月披露后约 20 小时内就被武器化，并被用于窃取 OpenAI、Anthropic 和 AWS 凭据，随后转向 Monero 加密货币挖矿，这是 Cloud Security Alliance 的说法。该联盟 2026 年 6 月 12 日的说明涵盖了 CVE-2026-5027，这是文件上传端点中的路径遍历漏洞，研究人员将其与伊朗国家支持的团体 MuddyWater 联系起来；其 9 月 4 日的说明记录了 CVE-2026-55255，这是一个授权绕过漏洞，允许已认证用户运行其他用户的 flow，该漏洞于 2026 年 7 月 7 日被列入 CISA 的已知被利用漏洞目录。这四个漏洞有一个共同特征：在一个职责是为其所交互的一切保管凭据的平台中，某个端点要么跳过了身份验证，要么跳过了清理。

为什么编排平台值得费这些功夫

生产环境中的 Langflow 实例会配置提供商 API 密钥、云凭据、数据库连接字符串和集成密钥，因为它所运行的 flow 在调用时需要用到这些凭据。因此，一旦主机被攻陷，攻击者便能获得该实例所存储凭据对应的每一项服务的有效访问权限。窃取的 OpenAI 或 Anthropic 密钥可让攻击者将推理费用记在受害者账上，或在下游冒充该组织；窃取的 AWS 密钥则可打开远超 Langflow 容器范围的基础设施。观察到的这些命令所瞄准的正是这种可资利用的权限，而非任何 AI 特有的能力。

云安全联盟的判断是，一年内在四个不同的 Langflow 子系统——代码验证器、公开流程构建端点、文件上传、工作流执行——中反复出现的问题，表明的是安全工程层面的系统性缺口，而不是一连串互不相关的缺陷。这是该联盟在一份研究简报中给出的评估，并非独立审计师的发现；并且，在本文所审阅的材料中，Langflow 未对此公开回应。

修复了什么，以及还有什么仍然不明确

这是公开记录中最薄弱的部分，值得准确说明原因。ZDI 的公告未指明任何已修补版本。Snyk 针对该 CVE 的数据库条目将受影响版本列为 1.10.1 之前的所有版本，并建议升级至 1.10.1 或更高版本。包括 SecurityWeek 和 Security Affairs 在内的公开报道将受影响范围描述为截至 1.4.2 的各个版本，但未指明任何修复版本。Cloud Security Alliance 于 9 月 4 日指出，Langflow 的维护者尚未发布专门指明该 CVE 的安全公告，而且各漏洞跟踪机构对于究竟哪个版本真正修复了该问题存在分歧——该联盟表示，这种模糊性与此前一个 Langflow 案例相似，当时某个被报告为已修复的版本仍可利用。

Langflow 确实在正确的模块、正确的时间发布了修复。1.11.6 版于 2026 年 9 月 1 日发布，当天是星期一，蜜罐计数已超过 360；其发布说明描述了一次安全修复回移，包括“弥合组件代码扫描缺口”和“无需执行即可解析注解”（拉取请求 14876）。1.12.0 版于当晚随后发布。此后，同一代码路径的进一步加固仍在继续：一个稍后标题为“阻止 validate_code 执行导入”的拉取请求表明，在首次利用发生数周后，validate 端点仍在被收紧。这些都不构成供应商声明，说明 CVE-2026-0768 已在某个具名版本中修复；在记录所引用的来源中也没有找到此类声明。

攻击者一侧的变化更为清楚。针对该漏洞的 Metasploit 利用模块于 2026 年 9 月 2 日以拉取请求形式提交——同一天 Security Affairs 发布了相关报道——并于 2026 年 10 月 8 日合并，已针对 Langflow 1.4.2 进行测试。无论最初的推导处于何种状态，在该漏洞开始被利用六周后，利用它就不再需要原创性工作。

Cloud Security Alliance 建议的应对措施是“修补并轮换”的流程，而不是仅打补丁：核实正在运行的版本并升级到当前稳定版；将任何运行受影响版本且暴露于互联网的实例视为已遭入侵，除非能证明并非如此，因为观察到的活动是静默采集而非可见破坏；并轮换该实例能够访问的每一个机密——Langflow 超级用户密码、各提供商 API 密钥、AWS 访问密钥和秘密访问密钥，以及 Langflow 密钥本身，并重新加密已存储的凭据，而不只是替换文件。它还建议审计访问日志，查找对 validate 端点的请求；检查 authorized_keys 中是否有不熟悉的 SSH 密钥；并查找证据，确认先前的操作者是否已经在该主机上植入了后门。如果平台必须保持可访问，它建议对 validate 端点加访问控制或将其禁用，并不要再将长期有效的高权限密钥直接存储在平台中。

已确立、已报告和未确立

已确认：CVE-2026-0768 是 Langflow 的 validate 端点中的未经身份验证的 RCE，该端点以 root 身份执行 Python，记录于 ZDI-26-034，并镜像为 GHSA-x5pr-rvjj-j6qm；利用活动始于 2026 年 8 月 29 日至 30 日；VulnCheck 在数小时内记录了超过 50 次检测，截至 9 月 1 日超过 360 次，针对英国传感器，流量主要来自俄罗斯；并且观察到的请求针对 Langflow 超级用户、OpenAI 和 AWS 凭据以及缓存的密钥、.ssh 和 .bash_history。这些信息来自公告本身，以及 VulnCheck 的遥测数据，并由 SecurityWeek、Security Affairs 和 The Hacker News 独立报道。

据称，未经独立核实：每一个检测计数。50、360和15,000都是VulnCheck自己的数据，由该公司发布，并被引用其数据的媒体转载；尚无第二个蜜罐网络发布佐证计数。将来源归因于俄罗斯基础设施同样只是VulnCheck对源流量的解读，而非任何政府或CERT在所审查材料中认可的评估。

尚未确定：任何具名组织丢失了凭据。记录所引用的来源中未确认任何受害者。也没有已确认的修补版本：ZDI 未指明任何版本，Snyk 称是 1.10.1，报道称受影响范围一直到 1.4.2，而 1.11.6 的发行说明描述了安全修复，但未将其与这个 CVE 关联。如上所述，“2026 年第十二个漏洞”这一计数在其自身来源之间也并不一致。

真正应该让按计划打补丁的人担心的部分

八个月的空白本身就是关键发现。CVE-2026-0768 于 2026 年 1 月 9 日作为零日漏洞公布，其技术描述详细到足以据此复现漏洞，而直到八月最后一个周末，VulnCheck 的传感器才探测到相关活动。随后，三天内出现了数百次尝试，按该公司的说法，这些操作者并没有可照搬的公开漏洞利用代码。无论是什么让这些实例在长达八个月的公开严重漏洞公告期间一直未打补丁，也正是同一因素，使得当终于有人写出利用代码时，这个漏洞值得被利用。

这也闭合了早先 Langflow CVE 所打开的一个循环。CVE-2025-3248 的修复方式是从同一个 validate 路径中移除执行；而 CVE-2026-0768 却仍然在该路径上执行。一个只移除行为、却不移除产生该行为的设计决策的修复，只能争取时间；在这个案例中，它争取到了大约四个月。