CVE-2025-34291：Langflow AI智能体和工作流平台账户接管和远程代码执行漏洞

背景

一枚代币可以为你或持有它的人打开大门。

最近发生的Salesloft-Drift事件暴露了此类攻击可能造成的破坏。攻击者UNC6395利用被盗的OAuth令牌，从大约700家Salesforce组织（包括Cloudflare、Zscaler和Palo Alto Networks等大型科技公司）中大规模窃取数据。

人工智能代理和工作流平台已成为外部服务和数据系统的集成中心。每次集成都会增加更多凭证，将敏感访问权限集中在一处。这种集中化使得攻击者成为高价值目标：一次安全漏洞就可能让攻击者获得所有连接系统的“主密钥”。

对于共享平台而言，一次安全漏洞可能影响多个组织；对于自托管平台而言，一次安全漏洞可能暴露单个组织内的多个服务。鉴于这些风险，我们对一些知名的开源人工智能代理和工作流平台进行了安全评估，以识别可能导致底层系统完全瘫痪的潜在漏洞。

我们选择 Langflow 作为主要研究对象——这是一个开源的低代码可视化框架，用于构建 AI 工作流、RAG 应用和多智能体系统，在 GitHub 上拥有超过 14 万颗星。Langflow 基于 Python 和 FastAPI 构建，提供直观的拖放式界面，使开发人员无需编写大量代码即可创建复杂的 AI 应用。

‍

‍

值得注意的是，Langflow 于 2024 年 4 月被 DataStax 收购，而 DataStax 目前正被 IBM 收购（2025 年 2 月宣布），这使得 Langflow 成为 IBM 不断扩展的 Watsonx AI 产品组合的一部分。

Langflow 深度解析点击并应用

CVE-2025-3248：两年的历程

Langflow 是一款年轻且快速迭代的项目——正是这种类型的项目，值得深入研究其安全性。一个很好的切入点是它的漏洞历史记录。就在几个月前，CVE-2025-3248 漏洞浮出水面：这是一个影响 1.3.0 之前版本的严重且未经身份验证的远程代码执行漏洞。

真正引人注目的不仅是问题的严重性，还有背后的故事：从最初发现到最终修复，历时近两年，这是一个异常长的时间，暴露了架构上的权衡取舍以及 Langflow 的安全态势是如何演变的。

发现和补救时间表：

• 2023 年 7 月 27 日：GitHub 用户 @Lyutoon 提交了 Issue #696，指出未经身份验证的代码验证端点可以通过函数定义的默认参数被利用进行远程代码执行 (RCE)。
• 2024 年 11 月 10 日：Github 用户 @nimasteryang 提交了一个 pull request #4488，试图解决该漏洞，但由于修复会破坏现有功能，因此该修复被放弃了。
• 2025 年 2 月 22 日： Horizo​​n3.ai的安全研究人员通过 GitHub 安全问题报告了 Langflow 的漏洞，发现了第二个不同的 RCE 向量，该向量利用函数装饰器在代码验证期间触发 RCE。
• 2025年3月3日：Langflow团队在易受攻击的端点#6911上实施身份验证要求，正式修复CVE-2025-3248漏洞。

近两年的时间线凸显了一个熟悉的权衡：尤其是在人工智能领域，团队争先恐后地构建和赢得采用，而安全性却被抛在了后面。

‍

漏洞：快速回顾

让我们简要回顾一下这个漏洞是如何运作的。

核心问题源于 Langflow 的/api/v1/validate/code一个接口，该接口旨在验证自定义组件的 Python 代码片段。然而，在 1.3.0 版本之前，无需任何身份验证即可访问此接口：

src/backend/base/langflow/api/v1/validate.py

‍

该validate_code()函数会解析提供的代码，检查其中是否包含函数定义，然后执行这些函数以验证它们：

src/backend/base/langflow/utils/validate.py

这段代码假定函数定义可以安全执行。但事实并非如此。当 `exec()` 函数执行函数定义时，它会立即执行默认参数和装饰器中的表达式。

‍

如果没有沙盒机制，任何未经身份验证的用户都可以通过向服务器发送一个 POST 请求来完全攻破系统/api/v1/validate/code。

该漏洞已被积极利用，威胁行为者通过被入侵的 Langflow 实例部署 Flodric 僵尸网络，Trend Micro 的研究记录了这一情况。

‍

从开放到封闭

为应对 CVE-2025-3248，我们在 /api/v1/validate/code 端点添加了身份验证功能。当请求到达该端点时，FastAPI 的依赖注入机制会自动触发身份验证流程。

端点声明身份验证要求

‍

验证用户帐户是否处于活动状态

‍

执行实际身份验证检查

get_current_user() 函数按优先级顺序检查两个身份验证源：

首先：来自 Authorization: Bearer <token> 标头的 JWT 令牌

第二种：来自 x-api-key 标头或查询参数的 API 密钥

补丁发布后，代码验证端点默认不再开放。现在访问该端点需要有效的 JWT 令牌或有效的 API 密钥。

‍

从受保护到已泄露：CVE-2025-34291

身份验证在理论上看起来很完善。因此，实际问题就变成了：我们能否获取或利用有效的凭证？以下三个方面值得关注：

1）API密钥

前景堪忧。API密钥默认不自动配置，用户必须在设置中显式创建。攻击面有限。

2) CSRF 和 CORS？

这条路径很有意思。如果没有适当的 CSRF 保护，攻击者可以cross-site write以用户的身份发出请求。如果 CORS 策略配置错误，攻击者还可以执行其他操作cross-origin read，从而获取已认证请求返回的敏感响应。

3) 利用 XSS 窃取 JWT 令牌

后端在登录期间生成并签名 JWT（HS256），然后将其作为 HTTP 响应的一部分设置到access_token_lfcookie中SameSite=Lax。响应正文中也包含相同的令牌。

然后前端读取此 cookie，并通过 Axios 拦截器使用标准Authorization: Bearer <token>标头将该令牌包含在所有 API 请求中。

换句话说，JWT 令牌的值与access_token_lfcookie 中存储的值相同。由于 cookie 不是加密的HttpOnly，因此客户端 JavaScript 可以读取它——但这需要 Langflow 中存在单独的 XSS 漏洞。

幸运的是，方法 2 奏效了：我们发现了两个配置错误，这两个错误加在一起完全绕过了身份验证。

‍

CORS配置错误

默认情况下，Langflow 使用 FastAPI 的 CORSMiddleware，并采用宽松的设置，允许来自任何来源的请求。此外，allow_credentials该设置还设为 True，允许攻击者使用凭据发起跨域请求。

langflow/main.py#L292-L300

然而，有两个问题阻碍了进一步的开发利用：

• 问题 1：身份验证 cookieaccess_token_lf已设置SameSite=Lax，这会将其排除在大多数跨站点上下文（XHR/fetch/POST）之外，但用户发起的顶级 GET 导航除外。
• 问题 2：在 Langflow 1.5 及更高版本中，大多数 API 端点需要额外的身份验证——要么提供 Langflow API 密钥，要么在 Authorization 标头中包含 JWT 令牌，而跨域请求不会自动包含该令牌。

因此，我们不应该能够发送经过身份验证的跨域请求。这个 CORS 设置看似无害——直到一个被忽略的细节重新引发了攻击链。

‍

refresh_token_lf Cookie 配置错误

该refresh_token_lfcookie 经过配置SameSite=None; Secure，使其可以通过 HTTPS 在跨站点上下文中访问。此外，它的有效期最长可达一周，这给了攻击者更长的攻击窗口。

该/api/v1/refresh端点仅依赖此 cookie 作为其身份验证机制，并且没有实施任何额外的 CSRF 保护。

因此，从攻击者控制的域发出的跨域请求/api/v1/refresh可以成功获得一对新的令牌：一个令牌access_token和一个新令牌refresh_token，从而实现完全会话劫持。

‍

攻击者只要掌握了有效的访问令牌，就可以简单地发出另一个跨域请求来利用 CVE-2025-3248 漏洞并实现远程代码执行。

‍

重现步骤

环境设置

1. 使用 Docker Compose 在本地配置 Langflow，并启用 HTTPS:

‍
2. 访问 Langflow:https://<server-addr>:443在浏览器中打开，将 替换<server-addr>为部署 Langflow 的服务器的 IP/主机名。

3. 登录：使用默认admin:admin凭据启动新的用户会话。

概念验证

1. 打开 PoC 页面：导航https://www.pocs.app/langflow-cors-vul-poc.html至

2. 配置目标：更改目标基本 URL，然后单击Launch Exploit。

3. 见证奇迹：几秒钟之内，将会发生以下情况：

• POST /api/v1/refresh浏览器发送包含受害者 cookie 的跨域请求。
• PoC提取了和access_tokenrefresh_token
• 然后它通过/api/v1/validate/code端点触发远程代码执行 (RCE)。

4. 结果：环境变量或其他敏感数据将显示在 PoC 终端面板上。

影響を及ぼす

Langflow 使用全局变量来存储和重用跨流程的凭据和其他通用值。这些变量持久化存储在其内部数据库中，并且其值使用密钥进行加密。

一旦系统被攻破，攻击者就很容易解密这些值。

完全会话劫持和远程代码执行——只需一次恶意网页访问即可完全控制系统。由于请求是通过 CORS 从受害者的浏览器发起的，因此即使是非公开的本地部署实例也可能被利用。

在 Langflow 作为人工智能代理和工作流平台的背景下，远程代码执行 (RCE) 漏洞尤其危险。攻击者可以访问项目流程以及存储在工作区中的特权凭证，包括 API 密钥、数据库密码以及用于连接 SaaS、云和其他环境的服务令牌。这极大地扩大了攻击范围，使其不再局限于 Langflow 实例本身，从而使 Langflow 等代理构建平台成为单点故障。

セキュリティに関する推奨事項

Langflow 迟迟没有发布完整的修复程序，似乎是出于担心收紧 cookie/CORS 设置可能会破坏前端/后端分离部署。

从安全角度来看，问题是：应该如何保护刷新端点？

1. 如果身份验证基于 Cookie，则必须采取适当的 CSRF 防护措施。对于同站点部署（例如，https://app.example.com → https://api.example.com，虽然是跨域但仍属于同站点），刷新 Cookie 可以安全地使用 SameSite=Lax 或 Strict（最好同时启用 Secure 和 HttpOnly）。如果前端和后端不在同一站点，并且某些功能需要 SameSite=None，则必须添加显式的 CSRF 令牌机制。

2. 刷新令牌最好通过 HTTP 标头而非 Cookie 发送。使用 `Authorization: Bearer <refresh_token>` 可以完全消除 CSRF 威胁模型，避免浏览器管理的凭据附加，并简化 CORS 加固。

最后但同样重要的是，这个漏洞并非源于单一的关键缺陷，而是由多个看似无关紧要的配置选择共同作用的结果，这些选择组合起来便构成了一个严重的攻击途径。此次事件凸显了一个重要的教训：在复杂的系统中，即使是看似无害的设计决策也可能以意想不到的方式相互作用。它强调了全面安全审查和默认安全配置的重要性——尤其是在人工智能平台日益深入地嵌入企业工作流程并处理越来越敏感的数据之际。

缓解措施方案

在负责任地披露问题后，Langflow 团队承认了该问题并启动了一系列修复措施。根据 Langflow 开发日志：

• 1.6.0 版本引入了新的环境变量，允许用户完全自定义 Langflow 的 CORS 配置。
• 在即将发布的 1.7 版本中，CORS 和refresh_token_lfcookie 都将采用更安全的默认设置：
  • CORS仅允许来自明确指定的来源的已认证请求。
  • refresh_token_lfcookie 将默认设置为SameSite=Lax减少跨站点暴露。

截至本文发布时，最新官方版本为 1.6.9，在默认设置下，一键远程代码执行 (1-click RCE) 仍然完全可利用。

组织可以按照官方 CORS 指南手动强化其部署。或者，如果前端和后端位于同一站点，则可以应用PR #10139中的修复程序，REFRESH_SAME_SITE在源代码级别进行更新。StrictLax

此外，Langflow 团队正在为代码验证端点#10696开发沙箱。希望这能彻底解决潜在的远程代码执行风险。

漏洞披露时间表

• 2025 年 7 月 29 日— 通过 GitHub 安全问题提交了该漏洞；同时在 HackerOne 上向 DataStax 报告了该漏洞，作为备用方案。
• 2025年7月29日——Langflow提交了PR #9240（“改进cookie安全性”）。这项前端更改对httpOnly cookie没有影响（必须在后端配置），因此并未缓解该问题。
• 2025 年 7 月 31 日— HackerOne 上的报告已进行分类。
• 2025年8月5日——请求提供GitHub安全问题的最新进展。
• 2025年9月7日——请求提供GitHub安全问题的最新进展。
• 2025 年 9 月 11 日— Langflow 提交了 PR #9441（“添加环境变量以允许用户控制”），并添加了一条警告：“在 v1.7 中，使用通配符来源时，凭据将自动禁用”。
• 2025年9月25日——Langflow 1.6.0发布：引入了环境变量以自定义CORS允许的来源。但是，默认配置仍然存在漏洞。
• 2025年9月26日——请求提供HackerOne的最新进展。
• 2025年10月3日——DataStax 回复道：“这是团队的事情。”
• 2025 年 10 月 22 日— GitHub 安全问题仍未有任何更新；已请求 VulnCheck 分配 CVE 编号。
• 2025年10月23日——CVE-2025-34291漏洞已分配。感谢VulnCheck团队快速提供CVE帮助。
• 2025 年 11 月 4 日——四个月过去了，由于用户可以通过调整 CORS 配置来手动缓解问题，我们决定发表这项研究。

Obsidian Security的安全研究人员发现了Langflow中的一个严重漏洞链