Langflow 严重漏洞 CVE-2026-33017 在披露后 20 小时内引发攻击

2026-03-21 03:39:56 1 105

Langflow 严重漏洞 CVE-2026-33017(CVSS 9.3)在披露后 20 小时内即遭在野利用。该漏洞源于缺失鉴权与代码注入,可致 RCE。由于攻击者利用速度极快,建议用户尽快升级至修复版本,并检查环境变量与凭证安全。



影响 Langflow 的一个严重安全漏洞在公开披露后 20 小时内即遭到主动利用,凸显了威胁行为者将新发布的漏洞武器化的速度之快。

该安全缺陷被追踪为 CVE-2026-33017(CVSS 评分:9.3),是一个缺失身份验证结合代码注入的案例,可能导致远程代码执行(RCE)。

Langflow 针对该漏洞的公告指出:“POST /api/v1/build_public_tmp/{flow_id}/flow 端点允许在无需身份验证的情况下构建公共流。”

“当提供可选的 data 参数时,该端点使用攻击者控制的流数据(节点定义中包含任意 Python 代码),而不是数据库中存储的流数据。这段代码在毫无沙箱保护的情况下被传递给 exec(),从而导致未经身份验证的远程代码执行。”

该漏洞影响该开源人工智能(AI)平台 1.8.1 及之前的所有版本。目前已在开发版本 1.9.0.dev8 中修复。

安全研究员 Aviral Srivastava 于 2026 年 2 月 26 日发现并报告了该漏洞。他表示,这与 CVE-2025-3248(CVSS 评分:9.8)不同,后者是 Langflow 中的另一个严重漏洞,滥用 /api/v1/validate/code 端点在无需任何身份验证的情况下执行任意 Python 代码。据美国网络安全和基础设施安全局 (CISA) 称,该漏洞随后也遭到主动利用。

Srivastava 解释道:“CVE-2026-33017 位于 /api/v1/build_public_tmp/{flow_id}/flow,”并补充说根本原因在于调用链末端使用了与 CVE-2025-3248 相同的 exec() 调用。

“该端点设计为无需身份验证,因为它服务于公共流。不能直接添加身份验证要求,否则会破坏整个公共流功能。真正的修复方法是完全从公共端点中移除 data 参数,这样公共流只能执行其存储的(服务器端)流数据,而永远不会接受攻击者提供的定义。”

成功利用该漏洞可能允许攻击者发送单个 HTTP 请求,并以服务器进程的完整权限获得任意代码执行能力。拥有此权限后,威胁行为者可以读取环境变量,访问或修改文件以注入后门或删除敏感数据,甚至获取反向 shell。

Srivastava 告诉 The Hacker News,利用 CVE-2026-33017“极其简单”,可以通过武器化的 curl 命令触发。他补充说,只需一个在 JSON 载荷中包含恶意 Python 代码的 HTTP POST 请求,就足以实现立即的远程代码执行。

云安全公司 Sysdig 表示,在 2026 年 3 月 17 日公告发布后的 20 小时内,它就观察到了针对 CVE-2026-33017 的首批在野利用尝试。

“当时不存在公开的概念验证代码,”Sysdig 说。“攻击者直接根据公告描述构建了可用的漏洞利用程序,并开始扫描互联网上的易受攻击实例。被窃取的信息包括密钥和凭证,这提供了访问连接数据库的权限,并可能导致软件供应链受损。”

还观察到威胁行为者从自动化扫描转向利用自定义 Python 脚本,以从“/etc/passwd”提取数据,并投递托管在“173.212.205[.]251:8443”上的不明下一阶段载荷。来自同一 IP 地址的后续活动表明这是一次彻底的凭证收集操作,涉及收集环境变量、枚举配置文件和数据库以及提取 .env 文件内容。

这表明威胁行为者进行了规划,准备好恶意软件以便在识别出易受攻击目标后进行投递。Sysdig 指出:“这是一名拥有准备好的漏洞利用工具包的攻击者,在单次会话中从漏洞验证转移到载荷部署。”目前尚不清楚攻击的幕后黑手。

公告发布与首次利用之间 20 小时的时间窗口与一种加速趋势相符,即从漏洞披露到利用的中位时间(TTE)已从 2018 年的 771 天缩短至 2024 年的仅几小时。

根据 Rapid7 的《2026 年全球威胁态势报告》,过去一年中,漏洞发布到被列入 CISA 已知被利用漏洞(KEV)目录的中位时间从 8.5 天降至 5 天。

报告补充道:“这种时间压缩给防御者带来了严峻挑战。组织部署补丁的中位时间约为 20 天,这意味着防御者暴露在风险中的时间太长了。威胁行为者正在监控防御者使用的相同公告源,他们构建漏洞利用程序的速度比大多数组织评估、测试和部署补丁的速度都要快。组织必须彻底重新考虑其漏洞管理计划以应对现实。”

建议用户尽快更新到最新的修复版本,审计任何公开暴露的 Langflow 实例上的环境变量和机密信息,作为预防措施轮换密钥和数据库密码,监控通往异常回调服务的出站连接,并使用防火墙规则或带有身份验证的反向代理限制对 Langflow 实例的网络访问。

针对 CVE-2025-3248 和 CVE-2026-33017 的探测活动凸显了 AI 工作负载如何因其访问有价值数据、集成在软件供应链中以及安全保障不足而成为攻击者的目标。

Sysdig 总结道:“CVE-2026-33017 [...] 展示了一种正成为常态而非例外的模式:流行开源工具中的严重漏洞在披露后数小时内即被武器化,通常甚至在公开 PoC 代码发布之前。”

关于作者

淡蛋的忧伤16篇文章31篇回复

评论1次

要评论?请先  登录  或  注册
  • 1楼
    15 小时前

    这漏洞简直核弹级别!漏洞刚公开20小时就被黑了,说明现在攻防速度太快了,赶紧看下自己服务器有没有Langflow在跑。 为什么这么危险?攻击者不用登录直接发个HTTP请求就能跑任意代码,服务器直接沦陷。想想你的服务器里存的密钥、数据库凭证全暴露,甚至能远程开个shell完全控制服务器。 建议三步走: 1. **立刻升级到1.9.0.dev8以上版本**,这可能是最紧急的事; 2. 如果暂时不能升级,直接在防火墙封掉/api/v1/build_public_tmp/这个接口的外网访问; 3. 检查服务器有没有异常出站连接到173.212.205.251这个IP,同时赶紧换掉可能泄露的密钥和数据库密码。 现在这种漏洞刚发公告就被扫荡的情况太常见了,建议平时就把Langflow这类服务放在内网,外网必须用的话配反向代理验证身份。后续要留意有没有公开的漏洞利用代码,但防比补更快才是关键。