Next.js 高危 SSRF 漏洞 CVE-2026-44578：影響範圍與升級建議

Sun, 17 May 2026 17:27:13 +0800

Next.js 在 2026 年 5 月揭露了一個高危 SSRF 漏洞：CVE-2026-44578。

根據 GitHub / Vercel 安全公告 GHSA-c4j6-fc7j-m34r 和 NVD 記錄，這個漏洞影響自託管的 Next.js 應用，前提是應用使用內建 Node.js server，且暴露在可接收惡意 WebSocket upgrade 請求的網路環境中。攻擊者可能讓伺服器代理請求到任意內部或外部位址，進而暴露內部服務或雲端 metadata 端點。

Vercel 託管部署不受影響。修復版本是 15.5.16 和 16.2.5。

先說結論

如果你在自己的伺服器、容器、Kubernetes、ECS、VPS、裸機或 PaaS 上自託管 Next.js，需要優先檢查。

受影響範圍：

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

不受影響或風險較低的情況：

部署在 Vercel 平台上的應用。
已升級到 15.5.16、16.2.5 或更高版本。
沒有使用內建 Node.js server 暴露服務的場景。
反向代理或負載平衡已阻斷不需要的 WebSocket upgrade 請求，且出站存取也做了限制。

建議處置順序：

先確認生產環境實際執行的 next 版本。
自託管應用盡快升級到修復版本。
暫時無法升級時，在反向代理或負載平衡層阻斷不需要的 WebSocket upgrade。
限制應用伺服器存取雲端 metadata、內網管理面和敏感內部服務。
排查近期異常 WebSocket upgrade 請求和內部存取日誌。

漏洞是什麼

CVE-2026-44578 是一個 Server-Side Request Forgery，也就是 SSRF 漏洞。

SSRF 的核心風險是：攻擊者不直接存取內部系統，而是誘導你的伺服器替他發請求。伺服器通常位於更靠近內網、雲平台和內部服務的位置，所以一旦被當成代理使用，可能存取到外部攻擊者本來碰不到的資源。

這次 Next.js 的問題出在 WebSocket upgrade 處理路徑。安全公告稱，自託管應用如果使用內建 Node.js server，攻擊者可以透過特製 WebSocket upgrade 請求，讓伺服器代理存取任意內部或外部目的地。

風險點包括：

內網 HTTP 服務。
管理後台。
雲端 metadata 位址。
容器或叢集內部服務。
只允許伺服器存取的內部 API。

這個漏洞的 CVSS v3.1 評分為 8.6 High，向量是：

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

這意味著攻擊面在網路側，攻擊複雜度低，不需要權限，也不需要使用者互動，主要影響機密性。

為什麼自託管更危險

這次公告明確提到：Vercel-hosted deployments are not affected。

真正需要重點關注的是自託管部署。原因很簡單：自託管應用的網路環境千差萬別，有些直接暴露 origin server，有些在 Nginx、Traefik、Ingress、Cloudflare、ALB 或自建閘道後面，有些運行在雲主機、容器網路或 Kubernetes 叢集裡。

如果這些環境沒有限制出站存取，Next.js 程序可能看得到：

169.254.169.254 這類雲端 metadata 位址。
內網 IP 段。
只在 VPC 內暴露的服務。
Redis、Elasticsearch、Prometheus、Grafana 等內部元件。
Kubernetes Service、Pod 或管理端點。

所以 SSRF 的危險不只在 Next.js 本身，而在它所在網路裡能存取什麼。

如何判斷是否受影響

第一步，看 next 版本。

在專案目錄裡執行：

`1`	`npm ls next`

或：

`1`	`pnpm why next`

也可以直接查看：

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

如果版本落在下面範圍，就需要處理：

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

第二步，看部署方式。

重點關注這些情況：

使用 next start 運行生產服務。
使用自訂 Node.js server 承載 Next.js。
Docker 映像裡直接啟動 Next.js server。
Kubernetes / ECS / VPS / 裸機自託管。
反向代理後面仍然直接暴露 Next.js origin。
應用所在網路能存取內部服務或雲端 metadata。

如果應用部署在 Vercel，按官方公告不受這個漏洞影響。但依然建議保持 Next.js 版本更新，因為同一批版本裡可能還修復了其他問題。

應該升級到什麼版本

官方修復版本是：

15.5.16
16.2.5

升級示例：

`1`	`npm install next@15.5.16`

或如果使用 16.x：

`1`	`npm install next@16.2.5`

pnpm：

`1`	`pnpm add next@15.5.16`

或：

`1`	`pnpm add next@16.2.5`

升級後重新建置並發布：

1
2

npm run build
npm run start

或按你的 CI/CD 流程重新建置 Docker 映像並發布。

如果你的專案鎖定在 14.x 或 15.x，不建議為了修漏洞倉促跨大版本到 16.x。更穩妥的做法是先升級到 15.5.16 這一修復線，完成測試和發布後，再規劃大版本升級。

臨時緩解措施

如果暫時不能升級，安全公告給出的核心思路是：不要把 origin server 直接暴露給不可信網路；如果不需要 WebSocket upgrade，就在反向代理或負載平衡層阻斷；同時盡量限制 origin 的出站存取。

可以考慮這些緩解方向：

不直接暴露 Next.js origin server。
在 Nginx、Ingress、ALB、Cloudflare 等入口層過濾不需要的 WebSocket upgrade。
如果業務不使用 WebSocket，直接拒絕帶有 upgrade 語義的請求。
對應用伺服器做 egress 限制，禁止存取雲端 metadata 位址和敏感內網段。
用雲平台能力啟用更安全的 metadata 存取模式，例如要求 token 的 metadata 服務。
對管理後台、資料庫、快取、監控系統增加認證和網路隔離。

注意，反向代理規則只是臨時緩解，不應該替代升級。框架漏洞最終仍然要透過修復版本解決。

維運排查重點

這個漏洞主要影響機密性，所以排查重點是「有沒有被用來存取內部資源」。

建議關注：

Web 存取日誌中異常的 Upgrade、Connection、Host、路徑和來源 IP。
反向代理或負載平衡日誌中異常的 WebSocket upgrade 請求。
Next.js 服務附近的異常出站連線。
雲端 metadata 服務存取日誌或憑證使用記錄。
內網管理服務、監控系統、快取、搜尋服務的異常存取。
IAM 臨時憑證、存取金鑰、token 是否有異常調用。
容器或主機上是否出現異常程序、下載行為或橫向移動跡象。

如果懷疑被利用，建議按外洩場景處理：

保留日誌和現場。
輪換可能暴露的雲端憑證、API key、資料庫密碼和 session secret。
檢查雲帳號最近的 API 調用。
檢查內網服務存取記錄。
重建受影響容器或主機。
複查出站存取策略和 metadata 保護。

這和 React/Next.js RCE 不是一回事

容易混淆的一點是，CVE-2026-44578 是 Next.js WebSocket upgrade SSRF，不是之前 React Server Components 相關的 RCE。

它的核心影響是讓伺服器向攻擊者指定的內部或外部位址發請求，主要風險是資訊外洩和內部資源探測。

而 React Server Components 相關 RCE 則屬於程式碼執行風險，攻擊後果和修復範圍不同。

所以排查時不要只看「Next.js 有漏洞」這個大標題，要把具體 CVE、影響版本、部署模式和修復版本對應起來。

哪些團隊要優先處理

優先級最高的是這些環境：

自託管 Next.js 生產站點。
運行在雲主機、容器、Kubernetes 或內網環境。
應用伺服器可以存取雲端 metadata 服務。
應用伺服器能存取內部管理後台、資料庫、快取或監控系統。
直接暴露 next start origin server。
使用老版本 next，且升級流程不清晰。

優先級相對較低的是：

完全部署在 Vercel 的應用。
已升級到修復版本的應用。
origin server 不直接暴露，且入口層已經阻斷不需要的 WebSocket upgrade。
出站網路嚴格受控，無法存取敏感內網資源。

但「優先級較低」不等於可以不升級。Next.js 是高頻暴露元件，框架版本長期落後會疊加更多風險。

給開發團隊的檢查清單

可以按下面清單處理：

確認所有倉庫的 next 版本。
查出所有自託管部署，不只看 Vercel 專案。
標記使用 next start 或內建 Node.js server 的服務。
升級到 15.5.16、16.2.5 或更高版本。
重新建置並發布生產映像。
在入口層阻斷不需要的 WebSocket upgrade。
限制應用伺服器存取雲端 metadata 和敏感內網段。
檢查近期異常 upgrade 請求和出站存取。
輪換疑似暴露的憑證。
把 Next.js 安全更新納入依賴更新流程。

總結

CVE-2026-44578 是一個需要認真處理的 Next.js 高危 SSRF 漏洞。

它不影響 Vercel 託管部署，但影響範圍覆蓋大量自託管 Next.js 應用：13.4.13 到 15.5.16 之前，以及 16.0.0 到 16.2.5 之前。漏洞觸發點在 WebSocket upgrade 處理路徑，攻擊者可能讓伺服器代理存取內部或外部位址，進而暴露內網服務或雲端 metadata 端點。

最直接的修復方式是升級到 15.5.16 或 16.2.5。臨時緩解則是不要直接暴露 origin server，阻斷不需要的 WebSocket upgrade，並限制應用伺服器的出站存取。

對維運團隊來說，重點不是只看 CVE 分數，而是看你的 Next.js 服務所在網路能存取什麼。SSRF 的真實風險，往往取決於伺服器背後有哪些內網資源和雲權限。

參考連結：

Next.js on KnightLi的博客