CVE-2026-9198：Langflow 为任何人签发超级用户令牌，随后执行其发送的内容

IBM 针对 CVE-2026-9198 的公告描述了 Langflow OSS 的一种“两次请求即接管”攻击：一次对平台自动登录端点的调用，会把超级用户 bearer 令牌返回给任何请求者；第二次调用则向代码校验端点提交 Python 代码，而该端点会直接执行它。厂商将这条攻击链的两个部分分别归入不同的标识符——缺失身份验证对应 CVE-2026-9103，代码执行对应 CVE-2026-8481——并在 CVSS 3.1 中为这一组合评分 9.8，可通过网络触达，无需任何权限，也无需用户交互。1.0.0 至 1.10.0 版本的默认部署均受影响；修复方案为 1.10.1，IBM 未列出任何变通方法。美国网络安全和基础设施安全局于 2026 年 8 月 4 日将该 CVE 加入其已知被利用漏洞目录，联邦修复截止日期为 8 月 7 日。该记录、其严重性与危害标签，以及围绕它归档的条目均保存在Orca AI Incident Archive中，该档案将本起事件与系列中的其余事件一并列出。

这条链，见于三份 IBM 公告

IBM 将这个漏洞以三份文档而非一份发布，只有将它们放在一起阅读，其机制才清晰可辨。整个链条是 CVE-2026-9198，这是 CWE-94 下的代码注入问题，评分为 9.8，向量为 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H——网络可达、低复杂度、无需权限、无需用户交互，并且对机密性、完整性和可用性有高影响。其前半部分是 CVE-2026-9103，属于 CWE-306 下的关键功能缺少身份验证，评分同样为 9.8。其后半部分是 CVE-2026-8481，同样是 CWE-94，但评分为 9.9：AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H，所需权限为低权限而非无权限，且范围已改变。

9.9 是这套算术中诚实的部分。代码验证端点本身从未对陌生人开放——IBM 将其描述为一个漏洞，使“任何已认证用户都能以 Langflow 服务器进程的完整权限执行任意系统命令”。使这条链条无需认证的是前半部分：自动登录端点；在 IBM 的叙述中，当 AUTO_LOGIN 配置启用（默认启用）时，该端点“无需认证即可签发长期有效的超级用户持有者令牌”。公告还补充说，这些令牌带有 365 天的有效期，并记录了第二条较少受到关注的暴露路径——宽松的跨源资源共享默认设置允许携带凭据的通配符来源，IBM 表示这“可能使任意网站进行路过式令牌窃取”。

执行这一半才是值得细究的部分。IBM 的总结称，该验证器“编译并执行了用户提交的代码，包括函数定义时的求值，例如默认参数和装饰器”，因此攻击者便可以把可执行表达式夹带进默认参数或装饰器之中。这并非关于不安全代码的比喻：装饰器会在包含它的 def 被构造时求值，因此，一个声称目的仅为检查函数语法的请求，仍会运行附加在它上面的一切。IBM 自己的链式公告用一句话就点明了这一点——验证与执行是同一个操作。CVE-2026-8481 公告中记录的修复方案是“从验证路径中移除代码执行，仅执行编译检查”。

有一个小差异值得记录，因为它会影响威胁狩猎。链式公告将令牌端点写为 /api/v1/auto_login，Cloud Security Alliance 和 Field Effect 也是如此；IBM 单独的 CVE-2026-9103 公告将其写为 /api/v1/login/auto_login。两份 IBM 文档描述的是同一个端点，而且两者对该行为的描述都没有错。执行路径在各处的写法完全相同：POST /api/v1/validate/code。

日期来自哪里

该档案将这条记录的日期标为2026年8月6日。CISA 的目录条目（查阅于2026年10月30日）将此次新增记录为2026年8月4日，并将修复截止日期定为8月7日。周边报道的日期位于档案日期的两侧，而非当日：Field Effect 于8月5日发布，cvetodo 和泰国国家计算机应急响应小组均于8月7日发布。一条收录记录、它产生的截止日期以及围绕它撰写的文章是三件不同的事件，因此这些日期并不矛盾——但档案字段与 CISA 的字段之间的两天差距，正是在确切日期至关重要时需要查阅该目录的原因。

披露时间更难确定，而且各来源确实存在分歧。IBM 关于该链式 CVE 的公告页面标注的初始发布日期为 2026年7月2日，修改日期为2026年8月17日。Field Effect 将 IBM 的披露日期定为7月2日。Cloud Security Alliance 8月18日的研究笔记将披露时间以及随之一同发布的1.10.1版本定为 7月17日；cvetodo 也这样说。两种说法相差十五天，且两份文件都并非草率之作，因此本文不在两者之间作出选择。无论按哪种说法，可以确定的是，补丁在 KEV 列表收录之前就已发布，而1.10.1就是承载该补丁的版本。

CISA 条目在其自身字段中确切说明的内容，比其标题所体现的范围更窄。该产品列在供应商 IBM 下，产品名为 Langflow；该漏洞被描述为“允许未经身份验证的攻击者在默认 Langflow 部署上实现完整的远程代码执行”的漏洞；已知在勒索软件活动中被利用的情况记录为未知；根据 BOD 26-04，取证研判被标记为必需；而所需操作是按照供应商说明应用缓解措施，或者在无法获得缓解措施时停止使用该产品。

使用记录

CISA 的收录声明称该漏洞已被在野利用。支撑这一说法的公开证据比 9.8 这一评分所暗示的要薄弱。IBM 和 CISA 均未指明威胁行为者，也未公布所观察到的攻击活动的细节——Field Effect 直接指出了这一点，而 IBM 的三份公告或 KEV 条目中没有任何内容与之相矛盾。

取而代之的是二手转述的厂商遥测数据。云安全联盟的说明引用 KEVIntel 称，利用尝试最早记录于“2026年7月6日左右”，按该联盟自己的估算，这比披露早了数周；截至8月中旬，累计尝试次数已增至数百次，来自分布在数十个国家的数百个唯一互联网地址。这些数字来自一家监测公司，在本文审阅的其他来源中均未出现。此处仅作报道，未经证实。

起始日期值得再仔细审视。如果相关尝试确实在7月6日前后开始，那它就比IBM页面上所载的公报日期晚了四天，比另外两个来源给出的7月17日早了十一天。因此，遥测数据既不能证实也不能推翻这两个披露日期中的任何一个；云安全联盟（Cloud Security Alliance）同时给出了两种解释却未作取舍，将早期活动描述为要么是机会主义扫描者的独立发现，要么是协调披露之前技术细节的泄露。

公开的漏洞利用代码是记录更完善的部分。Field Effect 将该攻击链的公开描述归因于“2026年7月发布的一个公开概念验证”，该概念验证位于仓库 github.com/0xdak/CVE-2026-9198_exploit；并称该代码演示了通过自动登录端点获取超级用户令牌，然后将其用于验证端点。Field Effect 并未将该仓库的作者与任何已观察到的利用行为联系起来，本文也没有。同样，所审阅的任何来源均未报告从被利用主机上确认窃取凭据的情况：通常伴随 Langflow 漏洞出现的凭据收集描述，是对此类主机所持有内容的评估（见下文），而不是关于本记录中任何具名受害者的发现。

已确立、已报告和未确立

• 已确认。CVE-2026-9198 将自动登录端点中缺失的身份验证与代码验证端点中的代码执行串联在一起；IBM 依据 CWE-94 将该漏洞链评为 9.8，并将其两个组成部分分别评为 9.8 和 9.9；Langflow OSS 1.0.0 至 1.10.0 的默认部署在 Windows、macOS 和 Linux 上均受影响；1.10.1 是修复版本，IBM 未提供任何变通方案；CISA 已将该 CVE 加入 KEV 目录，联邦截止日期为 2026 年 8 月 7 日。三份 IBM 公告是主要文档，且它们在机制上相互一致。

• 独立重述。ThaiCERT 在其 2026 年 8 月 7 日的公告中复现了同样的双端点链路、同样的 9.8 评分、同样的受影响范围以及同样的 1.10.1 修复方案，并增加了 IBM 公告中未包含的一项网络控制措施：将 Langflow 的管理界面置于公共互联网之外，仅通过 VPN 或严格的地址允许列表访问。这印证了该公告是如何被解读的——由一个与厂商措辞无利害关系的政府机构所作——而非对该漏洞的独立发现。

• 已报告，未经佐证。所有利用计数：数百次尝试、数百个地址、数十个国家，始于7月6日前后。这些是一家监测公司的数据，由一家研究机构转述。CISA的清单确认利用确已发生，但未作量化；在本文审阅的材料中，未出现第二个遥测数据源。

• 尚未确定。 没有具名受害者，也没有具名行为者。未归因于任何国家或犯罪团伙。没有确认互联网可访问的 Langflow 实例数量——cvetodo 于 8 月 7 日报道称，IBM 尚未回答有关利用规模的问题——此后也没有供应商声明对此加以量化。档案将该记录评为置信度 A，且未将其标记为有争议，此处审查的内容也没有对其提出质疑；这些空白是公开证据中的空白，而不是关于该缺陷存在且已被利用这一说法的空白。

• 有意排除。ThaiCERT 的公告还描述了同一周内由 AI 驱动的自动化扫描，但将其归到同一 CISA 批次中的另一款产品，而非 Langflow。它并非关于本条记录的证据，本文也未将其作为此类证据使用。

上市后发生了什么变化？

供应商的补救措施只是提升版本号，别无其他。IBM 的受影响产品表列出了 Langflow OSS 1.0.0 至 1.10.0，并将 1.10.1 列为修复版本，还在“变通方法”字段中填入“None”——三份公告皆是如此。CVE-2026-8481 公告描述了这一变更：验证器不再执行，而是开始编译。涵盖自动登录部分的那份 CVE-2026-9103 公告，没有以同样详细的程度说明其修复方式，而且本文所审查的任何 IBM 文档都没有标明 1.10.1 的发布日期。

其他各方的建议都比厂商更进一步。Cloud Security Alliance 建议先升级，然后在运行时验证自动登录端点不再向未认证调用方发放令牌，而不是信任版本字符串——其给出的理由是此前 Langflow 补丁发布时修复并不完整。它还建议将 LANGFLOW_AUTO_LOGIN 环境设置显式设为 false，使平台要求真实凭据而不是自行生成凭据，并将任何自 7 月初以来一直面向互联网的实例视为已遭入侵，待日志审查后再作判断，同时轮换该实例可能触及的所有凭据：模型提供商密钥、数据库凭据和云服务密钥。ThaiCERT 补充了网络层面的建议——公共互联网上不暴露管理界面，仅允许通过 VPN 或允许列表访问。这两项都是研究人员的建议。IBM 则未发布任何建议。

一条致谢记录已在案。IBM的致谢将该报告归于Harish Kolla，其GitHub用户名为Har1sh-k。Cloud Security Alliance在其8月18日的说明中，将CVE-2026-9198列为约五个月内进入CISA目录的第四个不同的Langflow未认证或授权绕过漏洞，并列出了先前三个标识符；其解读是，这一模式反映的是对同一套认证与代码执行模型反复进行的零散修补，而非彼此无关的缺陷。这一表述是该联盟在一份研究说明中给出的评估，并非独立审计方的结论；此处查阅的任何来源均未记录维护者对此作出公开回应。

KEV 清单能确定什么、不能确定什么

CISA 的目录是对已观察到的利用行为的断言，而非事件报告，本条条目也遵循这一形式。它只说明该漏洞已被利用，并未说明针对谁、由谁利用，或利用频率如何。勒索软件的使用情况记录为“未知”。没有任何量化信息。该条目真正能够确定的，恰恰是严重性评分无法回答的那个问题：该漏洞是否已从可用的概念验证转变为实际利用。对于不受 BOD 26-04 约束的组织——世界上大多数组织均属此类——8 月 7 日的截止期限并不附带任何义务，而这一期限背后的事实，其分量与附带义务时并无二致。

云安全联盟（Cloud Security Alliance）从同一条记录中得出了运营层面的结论：被列入 KEV 目录是一个可靠信号，表明漏洞利用已经越过概念验证阶段；而对于这一漏洞，该信号在首批有记录的尝试发生约一个月之后才出现。按照这一解读，任何等到该目录收录之后才开始分类处置的人，其实已经是在应对一起事件，而不是在预防事件。这是否描述了某个具体部署的情况，则要由其日志来回答——需要搜索的端点对正是 IBM 所记录的那一对，而该记录并未指名任何一个受害者，可供用来检验这一答案。