应对 CVE-2025-55182：我们处理 React Server Components 漏洞的经验
2025年12月3日，React 团队披露了 CVE-2025-55182——一个存在于 React Server Components 中的预认证远程代码执行漏洞，CVSS 评分高达10.0。数小时内，Amazon、Google 和 Microsoft 的威胁情报团队便观察到多个攻击组织的活跃利用行为，其中包括国家级攻击行动。该漏洞影响 Next.js、React Router 以及基本上所有实现了 React Server Components 的框架。
本文记录了我们在收到 BSI（德国联邦信息安全办公室）关于我们某台生产服务器的通知后的响应过程，并为面临类似情况的团队提供了一套安全审计框架。
CVE-2025-55182 的实际影响
CVE-2025-55182 利用了 RSC “Flight” 协议中的不安全反序列化漏洞——该协议是 React 用于在服务器和客户端之间序列化组件树的机制。当服务器接收到特制的 POST 请求时，无法正确验证有效载荷结构，导致攻击者控制的数据能够影响服务器端执行逻辑。其结果是以 Node.js 进程的权限执行任意代码。
这个漏洞尤为突出的原因在于其攻击面。默认配置即存在漏洞。使用 create-next-app 创建并构建为生产环境的标准 Next.js 应用程序，无需开发者做任何代码更改即可被利用。Wiz Research 的测试表明其利用成功率接近100%，且攻击仅需一个无需认证的 HTTP 请求。
问题在于 React Server Components 已成为现代 Web 应用程序的基础设施。Wiz 的数据显示，39% 的云环境中包含运行存在漏洞版本的实例。对于面向互联网的应用程序而言，这一暴露窗口代表着巨大的风险。
我们遭遇了什么
2026年1月14日，我们收到了 Hetzner 的一封自动安全通知，转发了 BSI 的 CERT-Bund 团队发出的警报。通知指出我们的一台生产服务器——运行在 Hetzner Cloud 基础设施上的 meinjagdschein.tva.sg——托管的 Web 应用程序存在 CVE-2025-55182 漏洞。BSI 的检测方法（由 SL Cyber 记录）通过外部扫描识别出该漏洞，无需访问应用程序本身。
通知到达时距初始公开披露（12月3日）已过去约六周。这一时间线至关重要，因为活跃利用几乎在披露后立即开始。Amazon 威胁情报记录了披露后数小时内的利用尝试，攻击活动部署了加密货币矿工、反向 Shell 和持久化访问机制。Google Threat Intelligence Group 识别出多个不同的攻击活动，在受感染系统上部署了 SNOWLIGHT 下载器、HISONIC 后门和 XMRIG 矿工。
实际上，暴露窗口代表了漏洞管理的核心风险。从公开披露到补丁部署之间的时间决定了理论上的漏洞是否会变成实际的入侵。
修补
修复本身非常简单。对于 Next.js 应用程序，升级到已修补版本即可解决该漏洞。Vercel 的更新日志记录了具体版本：
对于 Next.js 14.x：升级到 14.2.35 或更高版本。对于 Next.js 15.x：升级到 15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7 或各次要版本的更高版本。对于 Next.js 16.x：升级到 16.0.7 或更高版本。
底层 React 包根据当前版本需要更新到 19.0.1、19.1.2 或 19.2.1。React 19.2.2 解决了额外的信息泄露问题（CVE-2025-55183），19.2.3 解决了拒绝服务漏洞（CVE-2025-55184 和 CVE-2025-67779）。
对于使用 Docker 的生产部署，这通常意味着更新 package.json、重新构建容器镜像并重新部署。该过程遵循我们在 React 应用程序部署指南和多租户 Docker 架构文章中记录的相同容器化部署模式。
但实际上，修补解决的是未来的利用问题。在长时间暴露后，更紧迫的问题是入侵是否已经发生。
检查是否已被入侵
CVE-2025-55182 利用的性质意味着成功的攻击会留下可识别的痕迹。Unit 42、Google Threat Intelligence 和 Amazon 安全团队记录的后利用活动遵循一致的模式：初始侦察、通过 Base64 编码命令进行有效载荷投递、通过 cron 作业或 systemd 服务建立持久化访问、以及横向移动或加密货币挖矿部署。
系统性审计应检查进程活动、网络连接、持久化机制、文件系统变更和应用程序完整性。
进程分析侧重于识别异常的资源消耗（加密货币矿工通常会导致持续的高 CPU 使用率）和可疑的进程名称。来自 React2Shell 攻击活动的已知恶意软件包括 xmrig 的各种变体、通过 curl 或 wget 执行 Shell 脚本的进程，以及试图混入合法系统进程的内核伪装名称，如 kswapd 或 kworker 变体。
网络分析检查活动连接中是否存在意外的出站流量。命令和控制基础设施通常通过常用端口（443、8443、8080）通信以规避防火墙检测，但连接到陌生 IP 地址的情况需要调查。Node.js 进程与预期应用程序依赖之外的地址建立的连接表明可能已被入侵。
持久化机制是成功利用最可靠的指标。建立持久化访问的攻击者通常会修改 crontab、创建 systemd 服务、添加 SSH 授权密钥或在 Shell 配置文件脚本中注入命令。在暴露窗口期间对这些文件的任何修改都需要仔细检查。
SSH 密钥审计值得特别关注。将未授权的 SSH 密钥添加到 authorized_keys 文件中可为攻击者提供可靠的重新进入途径，即使在初始漏洞修补后也是如此。将当前的授权密钥与已知的合法密钥进行比较，可以识别可能表明入侵的新增密钥。
文件系统分析检查攻击者经常用于暂存有效载荷的临时目录（/tmp、/var/tmp、/dev/shm），并识别最近被修改的可执行文件或配置文件。暴露窗口——从2025年12月3日到补丁部署之间——定义了相关的修改时间范围。
应用程序完整性验证将当前应用程序文件与已知的正常状态进行比较。对于使用版本控制的应用程序，git status 和 git diff 可识别修改。对于容器化部署，将运行中容器的内容与源镜像进行比较可揭示部署后引入的变更。
检查日志
Web 服务器日志可提供对利用尝试的可见性，但根据日志配置的不同，成功的利用可能不会留下明显的痕迹。React2Shell 漏洞利用使用 POST 请求发送到 RSC 端点，请求体中通常带有异常的有效载荷特征。
检查暴露窗口期间的访问日志中的 POST 请求，特别是发送到与 React Server Components 相关路由的请求，可能会揭示利用尝试。然而，没有可疑日志条目并不能确认没有被入侵——拥有持久化访问权限的攻击者经常清除或修改日志以掩盖其活动。
认证日志（auth.log、sshd 日志条目）记录了登录尝试和成功登录。意外的成功认证，特别是来自陌生 IP 地址或使用暴露窗口期间添加的密钥的认证，即使应用层利用日志不存在，也表明可能已被入侵。
我们的结果
经过对受影响系统的系统性检查，我们没有发现成功利用的证据。没有异常进程、没有可疑的网络连接、没有未授权的持久化机制、没有被修改的 SSH 密钥、没有在临时目录中部署有效载荷的证据，也没有在正常部署活动之外对应用程序文件的更改。
暴露窗口确实存在——从漏洞披露到我们的补丁部署之间约六周。鉴于已记录的活跃利用活动，风险是巨大的。但在本次事件中，要么我们的系统在该窗口期间未被攻击，要么利用尝试未能成功实现代码执行，尽管理论上存在漏洞。
这一结果并不意味着延迟修补是合理的。对于处理任何敏感操作的生产基础设施而言，六周的暴露窗口代表着不可接受的风险。正确的响应既包括在漏洞已知时立即修补，也包括系统性审计以评估暴露期间是否发生了入侵。
我们学到了什么
BSI 通知系统按预期运作——外部监控识别出影响德国托管基础设施的漏洞，并通过托管提供商通知了责任方。这正是互联网基础设施应有的协作安全模式。
挑战在于响应延迟。CVE-2025-55182 于12月3日披露。补丁立即可用。活跃利用在数小时内开始。然而我们的通知于1月14日到达——六周之后。这一差距反映了管理生产基础设施的运营现实。并非每个组织都会持续监控其技术栈中每个依赖项的安全公告。自动化漏洞扫描虽然存在，但需要配置和维护。多应用环境使挑战更加复杂。
关键在于建立减少未来暴露窗口的流程。具体到 React 和 Next.js 应用程序，监控 React 博客和 Next.js 安全公告可提供关键漏洞的直接通知。对于更广泛的基础设施，Dependabot、Snyk 等服务可自动化跨项目的依赖漏洞监控。
我们的基础设施——包括之前记录的 tva-fetch 系统——采用了便于快速修补的容器化部署模式。更新依赖意味着重新构建容器并重新部署，一旦识别出漏洞，通常可在数分钟内完成。我们在 n8n 自托管指南和 Traefik 反向代理教程中详细介绍了这些模式。这种架构方法无法防止漏洞，但可以最大限度地减少响应时的运营摩擦。
如果您收到了类似的通知
如果您收到了类似的 BSI 或托管提供商关于 CVE-2025-55182 的通知，响应优先级非常明确：立即修补，然后审计是否已被入侵。
修补可防止未来的利用，但无法解决潜在的现有入侵问题。上述审计框架为系统性检查提供了起点。对于缺乏内部安全专业知识的组织，根据受影响系统和数据的敏感性，聘请事件响应服务可能是适当的选择。
在整个过程中，文档记录至关重要。在进行更改之前记录当前系统状态。保留可能被轮换或覆盖的日志。如果出现入侵指标，应停下来考虑在修复之前进行取证保存，因为修复可能会破坏对了解攻击范围有用的证据。
React2Shell 漏洞是 React 生态系统的一个重要时刻——这是第一个影响服务器端 React 组件的严重预认证远程代码执行漏洞。修补要求很简单，但这一事件提醒我们，现代 Web 框架尽管使用方便，但引入的服务器端攻击面需要与任何其他服务器基础设施同等的安全关注。
总结
CVE-2025-55182 展示了理论上的漏洞如何迅速转变为实际风险。国家级攻击者和犯罪组织在披露后数小时内就整合了漏洞利用工具。其技术严重性——CVSS 10.0、无需认证、单个 HTTP 请求即可利用——充分证明了紧急响应的必要性。
对于在生产环境中运行 React Server Components 的组织，当务之急是验证所有部署的补丁状态。对于像我们一样经历了较长暴露窗口的组织，使用上述框架进行系统性审计可以对入侵状态提供合理的信心，尽管在没有全面取证分析的情况下，完全确定性仍然难以实现。
更广泛的教训超越了这一具体漏洞。现代 Web 应用程序中的依赖管理创建了大量需要持续关注的攻击面。自动化漏洞监控、支持快速更新的容器化部署模式以及事件响应程序应成为标准运营实践，而非在安全通知到达后才采取的被动措施。
对于管理 Next.js 或 React 应用程序并需要基础设施咨询或安全审计协助的团队，tva 提供基于各种规模和安全需求的生产部署经验的技术咨询服务。此处讨论的架构模式反映了从实际运营环境中获得的经验教训。
关于 React Server Components 安全或基础设施审计流程有疑问？请访问 tva.sg/contact 开始讨论您的具体环境。