本文對象：在正式環境中執行 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：在 middleware 中進行驗證時的授權繞過（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，依說明中提到的功能分類：
| 位置 | 樣貌 |
|---|---|
| 快取 | 快取混淆與污染：一個使用者的回應被提供給另一個使用者 |
| Middleware／路由 | 授權繞過：你以為受 middleware 保護的路由被通過了 |
| 圖片最佳化 | 透過擷取遠端 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 的 middleware／快取／圖片最佳化／rewrites
授權繞過、SSRF、快取污染、資源耗盡
一再出現的問題：在 middleware 中授權
反覆出現的模式，比任何單一 CVE 都更重要。
2025 年 3 月：CVE-2025-29927（CVSS 9.1）
帶有特定標頭的請求，可以繞過在 middleware 中執行的授權檢查。已在 12.3.5／13.5.9／14.2.25／15.2.3 修正。2026 年 5 月：CVE-2026-44574（CVSS 8.1）
刻意構造的查詢參數，可以在不改變可見路徑的情況下改變頁面看到的動態路由值，不通過 middleware 檢查就渲染出受保護的內容。已在 15.5.16／16.2.5 修正。2026 年 7 月：CVE-2026-64642（CVSS 8.2）
在使用 Turbopack 的 App Router 上，且config.i18n.locales只有一個項目時，刻意構造的請求可以繞過基於 middleware／代理的驗證。已在 16.2.11 修正。
這迫使我們得出的設計結論
十八個月內出現三次高嚴重度的 middleware 授權繞過。這不是一連串個別的實作錯誤，而是當判斷在路由之前做出、而該路由的解讀可能改變時，必然會發生的事。本站的立場：把 middleware 留作第一道粗略的檢查，並在存取資料前再做一次真正的授權判斷（在頁面、路由處理程式或資料層中）。把檢查寫兩次的成本，比一次繞過造成的損害更低。
有些取決於你的託管方式
容易被忽略的是：同一個 CVE 對你的影響，可能因是否自行託管而不同。CVE-2026-44578（CVSS 8.6）允許在使用內建 Node.js 伺服器的自行託管部署上，透過刻意構造的 WebSocket 升級請求進行 SSRF，可能到達內部服務或雲端中繼資料端點；而公告指出 Vercel 託管的部署不受影響。
所以「Next.js 的漏洞」不是單一的東西。是否適用，取決於你如何執行它，以及使用了哪些功能。
該做什麼
授權兩次（價值最高）
把 middleware 的檢查留作第一道粗略的檢查，並在存取資料前立即再判斷一次。上述三次繞過都能因此被擋下。關於區分這兩個概念，請看驗證與授權的差別。
為伺服器可以擷取的對象設定允許清單
限制圖片最佳化會載入的遠端 URL、伺服器端 fetch 的目的地，以及 rewrite 的目標。SSRF 問題在對外目的地不受限制的地方造成的損害最大。也請確認你的雲端中繼資料端點是否能從應用程式連到。
讓 Server Action 和 RSC 端點受到驗證保護
這些是反序列化請求內容的路徑，而 CWE-502 的 CVE 確實曾在這裡出現。不要讓它們留在驗證之外，套用速率限制，並確保非預期的資料無法讓程序停止。請把它們當成 /api 一樣對待。
讓更新成為機制
Next.js 的修正發布得很快，但只有在你更新時才有幫助。具體做法（以實際執行的版本判定、自動監控相依套件）請看安全維運 Next.js和osv-scanner 入門。一年 28 個 CVE，靠人工注意是跟不上的。
本站的看法：選擇框架的問題不在於數量
「Next.js 的 CVE 很多，所以應該避免使用嗎？」這是錯誤的問題。資料顯示的是，Next.js 穩定地承擔了越來越多伺服器的責任：它在 middleware 中授權、擷取遠端圖片、持有快取、反序列化請求。實際上，一個相依套件同時給了你反向代理和應用程式伺服器。所以該評估的不是數量，而是你實際使用了哪些伺服器功能，以及由誰來防禦它們。關閉不需要的；在需要的功能周圍加上雙重的自有控制。這樣看待，選擇就不再是喜好問題，而是關於你的維運能力的問題。
資料來源
- NVD（NIST）：2026 年 8 月 22 日查詢
cpe:2.3:a:vercel:next.js和cpe:2.3:a:facebook:react得到的數字 - CVE-2025-29927（middleware 授權繞過）／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 的原型污染（執行環境宣告不在其範圍內的領域）
- 維運：安全維運 Next.js，不在 CVE 上掉隊／用 osv-scanner 以機器監控相依套件
- 設計：驗證與授權的差別／X-Forwarded-For 偽造與受信任的代理
- 用語：SSRF 是什麼／CVE 是什麼
FAQ
QNext.js 的漏洞很多嗎？
以數量來說，是的，而且數量在增加。2026 年 8 月 22 日查詢 NVD，與 Next.js 相關的 CVE 有 56 個：2024 年發布 6 個、2025 年 14 個、2026 年 28 個。但不要把數量多解讀成「危險的技術」；越多人採用，研究就越多，回報也隨之增加。重要的是問題出現在哪裡，而不是有多少個。
QReact 的漏洞很少嗎？
作為瀏覽器端 UI 函式庫的 React，漏洞非常少：NVD 中有 6 個。而且除了 2018 年的一個之外，近期的全部都與在伺服器上執行的 React Server Components（react-server-dom-parcel／turbopack／webpack）有關。其中的 CVE-2025-55182 是驗證前的遠端程式碼執行，評分為 CVSS 10.0。
Q那實際的風險在哪裡？
在伺服器功能。近期 Next.js 的 CVE 集中在 middleware、快取、圖片最佳化、Server Actions 和 rewrites，主要的 CWE 是 SSRF（CWE-918）、不可信任資料的反序列化（CWE-502）、不受控制的資源消耗（CWE-770/400）和授權失敗（CWE-285/288）。這些都與你怎麼寫元件無關。
Q最值得改變的是什麼？
四件事：(1) 不要只依賴 middleware 做授權，繞過問題已經一再出現；(2) 為圖片最佳化、伺服器端 fetch 和 rewrites 的對外目的地設定允許清單；(3) 讓 Server Action 和 RSC 端點受到驗證和速率限制的保護；(4) 讓更新成為機制，而不是意願。第 1 點最重要，因為同樣形態的繞過在 2025 年和 2026 年都出現了。