适合：在生产环境中运行 Next.js 的团队，以及正在考虑是否采用它的人。目的是用实际的数字及其内容，取代「框架的 CVE 很多」这种模糊的印象。
数据（NVD，截至 2026 年 8 月 22 日）
| Next.js | React | |
|---|---|---|
| 累计 | 56 | 6 |
| 按年份 | 2020:1 / 2021:3 / 2022:3 / 2023:1 / 2024:6 / 2025:14 / 2026:28 | 2018:1 / 2025:4 / 2026:1 |
| 严重度 | CRITICAL 2、HIGH 21、MEDIUM 29、LOW 4 | CRITICAL 1、HIGH 3、MEDIUM 2 |
| 最严重的一项 | CVE-2025-29927——在中间件中做认证时的授权绕过（CVSS 9.1） | CVE-2025-55182——React Server Components 中无需认证的 RCE（CVSS 10.0） |
如何看待 CVE 数量
数量多并不意味着技术危险。使用越广，研究就越多，研究越多，报告就越多。数量少可能意味着「安全」——也可能意味着「没人在看」。数量只是起点；判断要看问题出在哪里、属于哪一类。这里的数字来自按 CPE（vercel:next.js、facebook:react）查询 NVD，所以没有分配 CPE 的不计入在内。
它们出在哪里
把 2025–2026 年发布的 Next.js CVE，按描述中提到的功能分类：
| 位置 | 表现 |
|---|---|
| 缓存 | 缓存混淆和投毒——一个用户的响应被提供给另一个用户 |
| 中间件／路由 | 授权绕过：你以为受中间件保护的路由被放行了 |
| 图片优化 | 通过获取远程 URL 导致的 SSRF 和资源耗尽 |
| Server Actions / RSC | 对不可信请求体的反序列化；由请求引发的过载 |
| rewrites / redirects | 对转发目标的解释不一致 |
CWE 的分布也说明了同样的事：CWE-770（不受控制的资源分配）、CWE-918（SSRF）、CWE-502（反序列化）、CWE-400（资源耗尽）、CWE-444（请求解释不一致）、CWE-288/285（授权绕过和授权失败）。这是一份服务器和代理的弱点清单。
浏览器端——React 渲染组件
React 本身在 NVD 中只有一个 CVE，来自 2018 年
服务器端 1：React Server Components
React 近期的五个 CVE 都在这里（最严重：无需认证的 RCE）
服务器端 2：Next.js 中间件 / 缓存 / 图片优化 / rewrites
授权绕过、SSRF、缓存投毒、资源耗尽
反复出现的问题：在中间件中做授权
反复出现的模式比任何单个 CVE 都重要。
2025 年 3 月 — CVE-2025-29927（CVSS 9.1）
携带特定请求头的请求可以绕过在中间件中执行的授权检查。已在 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 中修复。2026 年 5 月 — CVE-2026-44574（CVSS 8.1）
精心构造的查询参数可以在可见路径不变的情况下改变页面看到的动态路由值，从而在没有通过中间件检查的情况下渲染受保护的内容。已在 15.5.16 / 16.2.5 中修复。2026 年 7 月 — CVE-2026-64642（CVSS 8.2）
在使用 Turbopack 的 App Router 中，当config.i18n.locales只有一个条目时，精心构造的请求可以绕过基于中间件/代理的认证。已在 16.2.11 中修复。
由此必然得出的设计结论
十八个月内出现了三次高严重度的中间件授权绕过。这不是一连串个别的实现错误；而是当判断在路由之前做出、而对该路由的解释又可能发生偏移时必然会发生的事。我们的立场是：把中间件保留为第一道粗略的检查，在访问数据之前再做一次真正的授权判断（在页面、路由处理程序或数据层中）。把检查写两次的成本，低于一次绕过造成的损害。
有些取决于你的托管方式
容易被忽略的是：同一个 CVE 对你的影响，可能取决于你是否自托管。CVE-2026-44578（CVSS 8.6）在使用内置 Node.js 服务器的自托管部署中，允许通过精心构造的 WebSocket 升级请求进行 SSRF，可能到达内部服务或云元数据端点——而公告说明托管在 Vercel 上的部署不受影响。
所以「Next.js 漏洞」并不是一回事。它是否适用于你，取决于你如何运行它、使用了哪些功能。
该做什么
授权两次（最有价值）
把中间件的检查保留为第一道粗略检查，在访问数据之前再判断一次。上面三次绕过都能因此被挡住。关于把这两个概念分开，见认证与授权的区别。
对服务器可以获取的东西使用允许列表
限制图片优化器会加载的远程 URL、服务器端 fetch 的目标，以及 rewrite 的目标。SSRF 问题在外部目标不受限制的地方造成的损害最大。同时检查应用能否访问你的云元数据端点。
把 Server Action 和 RSC 端点放在认证之后
这些是反序列化请求体的路径——而且那里确实出现过 CWE-502 的 CVE。不要把它们留在认证之外，加上频率限制，并确保意外的数据无法让进程崩溃。像对待 /api 一样对待它们。
把更新做成机制
Next.js 发布修复很快，但只有你更新了才有用。具体做法（按实际运行的版本来判断，并自动监控依赖包）见安全地运行 Next.js和 osv-scanner 入门。一年 28 个 CVE，靠人工关注是跟不上的。
本站的观点：选择框架的问题不在于数量
「Next.js 的 CVE 很多，我们应该避开它吗？」这是一个错误的问题。数据显示的是，Next.js 承担的服务器职责在稳步增加——它在中间件中做授权、获取远程图片、持有缓存、反序列化请求。实际上，一个依赖包同时给了你一个反向代理和一个应用服务器。所以要评估的不是数量，而是这些服务器功能中你实际用了哪些，以及由谁来防御它们。关闭不需要的；在需要的周围加倍设置自己的控制。这样来看，选择就不再是喜好问题，而是关于你的运维能力的问题。
出处
- NVD（NIST）——2026 年 8 月 22 日查询
cpe:2.3:a:vercel:next.js和cpe:2.3:a:facebook:react得到的数字 - CVE-2025-29927（中间件授权绕过）／CVE-2026-44574（动态路由值偏移）／CVE-2026-64642（App Router + Turbopack 认证绕过）
- CVE-2026-44578（自托管环境中的 WebSocket SSRF；托管在 Vercel 上的不受影响）
- CVE-2025-55182（React Server Components 中无需认证的 RCE，CVSS 10.0）／CVE-2026-23864（RSC 拒绝服务）
接下来阅读
-
实现：Node.js 中的原型污染（运行时声明不在其责任范围内的领域）
FAQ
QNext.js 的漏洞多吗？
按数量来说，是的，而且数量在增加。2026 年 8 月 22 日查询 NVD，与 Next.js 相关的 CVE 有 56 个：2024 年发布 6 个，2025 年 14 个，2026 年 28 个。但不要把数量多理解为「危险的技术」——使用越广，研究就越多，报告也随之增多。重要的是问题出在哪里，而不是有多少个。
QReact 的漏洞少吗？
作为浏览器端 UI 库的 React 非常少：NVD 中只有六个。而且除了 2018 年的一个之外，近期的全部都与在服务器上运行的 React Server Components（react-server-dom-parcel / turbopack / webpack）有关。其中 CVE-2025-55182 是一个无需认证的远程代码执行，CVSS 评分 10.0。
Q那么真正的风险在哪里？
在服务器功能上。Next.js 近期的 CVE 集中在中间件、缓存、图片优化、Server Actions 和 rewrites 上，排名靠前的 CWE 是 SSRF（CWE-918）、不可信数据的反序列化（CWE-502）、不受控制的资源消耗（CWE-770/400）和授权失败（CWE-285/288）。这些都与你如何编写组件无关。
Q最值得改变的是什么？
四件事：（1）不要只依赖中间件做授权——绕过问题已经反复出现；（2）对图片优化、服务器端 fetch 和 rewrites 的外部目标使用允许列表；（3）把 Server Action 和 RSC 端点放在认证和频率限制之后；（4）把更新做成机制，而不是停留在意愿上。第 1 项最重要，因为同样形态的绕过在 2025 年和 2026 年都出现了。