一次真实的 RCE 攻击:CVE-2025-55182 漏洞复盘

从 504 错误到发现服务器被入侵

January 12, 2026·3 min read·Yimin
#安全#React#Next.js#CVE#RCE#漏洞

如果不是攻击者的操作导致服务崩溃,我可能永远不知道服务器被入侵了。

事件背景

2026 年 1 月 12 日凌晨,发现网站 yiminlab.site 返回 504 Gateway Timeout。

检查后发现:

  • Docker 容器正常运行(Up 2 days)✅
  • 容器内部 Next.js 进程已停止响应 ❌
  • nginx 等待后端超时,返回 504

意外发现

重启容器后查看日志,发现了奇怪的错误信息:

⨯ Error: NEXT_REDIRECT
   at ignore-listed frames {
  digest: 'CVE-2025-55182-TEST'
}

⨯ Error: x
   at ignore-listed frames {
  digest: 'bmV4dGpzCg=='
}

digest 字段里的内容是 base64 编码。解码后:

$ echo "bmV4dGpzCg==" | base64 -d
nextjs

继续解码其他 digest,发现更多内容:

# 攻击者执行了 ls -la
total 16
drwxr-xr-x    1 nextjs   nodejs          20 Jan  9 09:06 .next
drwxr-xr-x    3 root     root            18 Dec 14 07:16 content
-rw-r--r--    1 nextjs   nodejs         887 Jan  9 09:06 package.json

# 攻击者执行了 env,获取了环境变量
REDIS_PASSWORD=wuGgho***********
SMTP_PASSWORD=elntmm***********
NEXT_PUBLIC_API_URL=https://api.yiminlab.site

攻击者成功在我的服务器上执行了命令!

漏洞分析

CVE-2025-55182

这是 React 19 Server Components 的一个严重漏洞:

属性
CVE 编号CVE-2025-55182
CVSS 评分10.0(最高)
影响范围React 19.0.0 ~ 19.2.0
漏洞类型远程代码执行(RCE)
披露时间2025 年 12 月

攻击原理

React Server Components 在处理客户端请求时,对某些参数缺乏校验。攻击者可以构造特殊的 HTTP 请求,在服务器上执行任意代码。

攻击者的操作序列(根据日志推断):

1. 执行 whoami/id → 确认 RCE 成功
2. 执行 ls -la → 查看文件结构  
3. 执行 env → 获取环境变量(包括密码)
4. 尝试 curl → 失败(容器内没有 curl)

时间线还原

时间事件
1月9日 09:07Portal 容器部署(使用有漏洞的 React 19.2.0)
1月11日 06:10攻击者 IP 93.123.109.175 尝试访问 /.env(被 nginx 拦截)
1月11日 ~10:35🔴 攻击者利用 CVE-2025-55182 成功执行 RCE
1月11日 14:07攻击者用 "CVE-2025-55182-Checker" UA 再次扫描
1月12日 ~01:00发现 504 错误,开始排查
1月12日 01:55重启容器,发现攻击痕迹
1月12日 02:30升级 React 到 19.2.3,修复漏洞

总暴露时间:约 15 小时

损失评估

已泄露信息

信息风险等级说明
REDIS_PASSWORD🟢 低Redis 只绑定 127.0.0.1,外部无法访问
SMTP_PASSWORD🟡 中QQ 邮箱授权码,可能被用于发送垃圾邮件
文件结构🟢 低标准 Next.js 结构,无敏感信息
邮箱地址🟢 低可能被用于钓鱼

幸运的地方

  1. Redis 未暴露:虽然密码泄露,但端口只监听 127.0.0.1
  2. 攻击者能力有限:容器内没有 curl,无法外传数据或下载后门
  3. 攻击导致崩溃:如果服务没崩溃,可能永远不会发现

修复方案

1. 升级依赖(立即)

pnpm add react@19.2.3 react-dom@19.2.3 next@16.1.1

修复版本:

  • React: 19.0.1、19.1.2、19.2.1+
  • Next.js: 16.1.0+(同时修复了 CVE-2025-66478)

2. 更换泄露的密码(建议)

虽然 Redis 密码泄露风险较低,但建议:

  • 更换 SMTP 授权码
  • 更换 Redis 密码(如果有其他服务使用)

3. 部署 WAF(长期)

推荐 Cloudflare 或自建 ModSecurity,可以:

  • 拦截已知 CVE 利用
  • 限制异常请求
  • 提供攻击可视化

经验教训

为什么没有提前发现?

  1. 没有日志告警:日志里的异常 digest 字段没有触发告警
  2. 没有定期检查:漏洞披露于 2025 年 12 月,但没有及时关注
  3. 运气成分:攻击导致崩溃才暴露,否则可能一直不知道

如何主动发现入侵?

#!/bin/bash
# 简单的安全检测

# 1. 检查可疑请求
docker logs nginx-proxy 2>&1 | grep -iE "CVE|RCE|exploit"

# 2. 检查应用日志中的 RCE 痕迹
docker logs portal 2>&1 | grep -E "RCE_RES|digest.*[A-Za-z0-9+/]{50,}="

# 3. 检查异常进程(挖矿程序)
ps aux | grep -iE "xmrig|minerd|cryptonight"

核心建议

优先级措施说明
P0保持依赖更新订阅安全公告,及时升级
P1日志监控告警对异常模式设置告警
P2最小权限原则容器内不安装多余工具
P3定期安全审计pnpm audit、依赖扫描

总结

这次事件的讽刺之处在于:如果攻击者更「优雅」一点,不导致服务崩溃,我可能永远不会发现被入侵。

504 错误反而成了「报警器」🚨

安全不是一劳永逸的事情,需要:

  • 持续关注安全公告
  • 及时更新依赖
  • 建立监控告警体系
  • 定期进行安全审计

希望这篇文章能帮助你避免类似的问题。


参考链接