包括Help Net Security等多家媒體報導React 和 Next.js 中存在一個未經身份驗證嚴重漏洞 (CVE-2025-55182)，攻擊者可能利用該漏洞在應用程式伺服器上執行遠端程式。除了典型的漏洞修補活動外，台灣應用軟件從安全軟體開發生命週期，提供組織規劃與強化安全軟體設計與開發之參考。

CVE‑2025‑55182 是一項 未經認證的遠端程式碼執行（RCE）漏洞，源自 React Server Components（RSC）中的 Unsafe Deserialization，可讓攻擊者透過特製 HTTP 請求，直接在伺服器上執行任意 Javascript 或 Shell 指令。

影響版本包括：React 19.0.0 至 19.2.0，各相關 server-dom 套件；Next.js 載入 RSC 的版本亦受影響，並被追蹤為 CVE‑2025‑66478，CVSS 最高風險評分為 10/10，代表危害極大。

React 和 Next.js 應用場域與漏洞影響

1. React 的應用場域

• 單頁應用程式 (SPA)：React 最常用於建立高互動性的 SPA，例如儀表板、社交平台、電商前端。
• 跨平台應用：透過 React Native，可以開發 iOS 和 Android App。
• 組件化 UI：適合大型專案，因為它能將 UI 拆分成可重複使用的組件。

2. Next.js 的應用場域

• 伺服器端渲染 (SSR)：Next.js 提供 SSR，適合 SEO 要求高的網站（如部落格、新聞網站）。
• 靜態網站生成 (SSG)：適合內容固定的網站，如企業官網、文件站。
• 混合渲染模式：可以同時使用 SSR 和 SSG，適合大型電商或 SaaS 平台。
• API Route：Next.js 內建 API 路由，能快速建立後端服務。

3. React 漏洞可能影響

• XSS (跨站腳本攻擊)

―   原因：不安全地使用 dangerouslySetInnerHTML 或未過濾使用者輸入。

―   影響：攻擊者可注入惡意腳本，竊取 Cookie 或敏感資料。

―   防範：避免使用 dangerouslySetInnerHTML，或使用 DOMPurify 等工具。

• 依賴套件漏洞

―   React 專案通常依賴大量 npm 套件，若套件有漏洞，可能導致供應鏈攻擊。

―   防範：定期使用 npm audit 或 Snyk 檢測。

4. Next.js 漏洞可能影響

• 伺服器端渲染引發的 XSS

―   SSR 會將資料直接注入 HTML，若未做輸入驗證，容易被攻擊。

―   防範：使用 Next.js 的 next-safe 或 CSP (Content Security Policy)。

• 路由與 API 漏洞

―   API Route 若未驗證身份，可能導致未授權存取。

―   防範：加強身份驗證與授權機制。

• 敏感資訊洩露

―   在 getServerSideProps 或 getStaticProps 中處理敏感資料時，若錯誤傳到前端，會造成洩露。

―   防範：確保伺服器端邏輯不將敏感資料傳給客戶端。

5. 現實攻擊情境

• AWS、Google Cloud、Cloudflare、Akamai、Tencent 等雲端與 CDN 提供商已推出 WAF 規則，來檢測與防禦對此漏洞的攻擊嘗試。
• Unit 42、Trend Micro、Rapid7、Qualys 等資安廠商已觀察到在野攻擊，手法涵蓋植入 cryptominer、Backdoor、Cobalt Strike、Linux trojan、proxy 工具、反向shell、以太坊 RAT 等。
• 美國 CISA 已將其列入「已知被濫用漏洞清單（KEV）」，要求聯邦系統立即更新，私營企業也應視同緊急事件處理。

6. 類似漏洞與供應鏈風險

• 不安全反序列化（Unsafe Deserialization） 問題常見於多種語言與框架（如 Java, PHP, Python）。CVSS 10 分的漏洞亦曾在其他流行平台中出現，例如 Oracle EBS、PHP Roundcube、CWP 等。
• 在前端生態中，Server Component 的架構容易讓攻擊者透過序列化 payload 攻擊伺服器，導致跟類似 PHP Object Injection 的情況。

7. 防禦與緩解策略

• 立即升級至 React 19.0.1、19.1.2、19.2.1；Next.js 更新至補丁版本：15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7 或 16.0.7。
• 加強 WAF 規則、APIs 限制、反序列化驗證與權限控制，並以 Cloudflare、Akamai、AWS、GCP 等網路層面防禦加持。
• 實施行為監控與 IOC 檢測：Trend Micro、Unit 42、PacketWatch 等提供 PoC 與攻擊樣本供偵測行動分析。

8. 類似場景學習與建議

• 架構級反序列化僅安全檢查不夠：需限制可執行函式清單，避免允許 caller 動態引用如 child_process.exec、fs 等內建模組。
• 即便無認證，攻擊仍可成功：API 不應信任 X-Client 提交資料，應於 server function 層加強驗證

不安全反序列化

反序列化（Deserialization）是將「序列化後的資料（如 JSON、XML、Binary、Base64）」轉回為程式可操作的物件或資料結構的過程。不安全反序列化指系統在未驗證資料來源、完整性或內容安全性的情況下，直接將外部輸入反序列化為物件，導致攻擊者可藉由竄改序列化資料，觸發任意程式碼執行（RCE）、權限提升、物件狀態竄改、商業邏輯繞過或DoS 或資料外洩。這類弱點在Java、PHP、.NET、Python等支援物件反序列化語言中特別常見。

1. 典型攻擊情境與風險

• 遠端程式碼執行（RCE） 

• 權限提升

• 身分冒用

• 商業邏輯繞過

• 拒絕服務（DoS）     

2. 發生不安全反序列化原因

• 信任來自用戶或外部的序列化資料

• 直接反序列化成「可執行物件」

• 缺乏完整性與來源驗證

• 使用預設或過度彈性的反序列化設定

• 第三方套件或框架隱含反序列化風險

3. 防護不安全反序列化的實務重點

• 避免使用原生物件反序列化

• 只允許反序列化「安全型別白名單」

• 驗證資料完整性與來源

• 限制反序列化的行為能力

• 移除危險魔術方法與 Gadget

• 輸入驗證與結構檢查

• 監控與防禦

如何透過SSDLC降低或避免這類漏洞

要透過 SSDLC（Secure Software Development Life Cycle）降低或避免類似 React2Shell 這類不安全反序列化與 RCE 漏洞，可以從以下幾個階段入手：

1. 規劃階段（Planning）

• 安全需求定義：在專案初期明確列出安全需求，例如禁止使用不安全的反序列化、必須啟用 CSP、輸入驗證。
• 威脅建模（Threat Modeling）：針對架構中 SSR、API Route、序列化機制進行威脅分析，識別 RCE、XSS、敏感資料洩露等風險。

2. 設計階段（Design）

• 安全架構設計

―   避免在伺服器端直接執行來自客戶端的序列化資料。

―   採用白名單策略，限制可執行函式或模組。

• 安全模式選擇

―   使用安全的序列化格式（如 JSON 而非自定義二進制格式）。

―   在 React/Next.js 中避免 dangerouslySetInnerHTML，並啟用 CSP。

3. 開發階段（Implementation）

• 安全程式碼規範

―   禁止使用 eval()、Function()、child_process.exec 等高風險 API。

―   對 API Route 加強身份驗證與授權。

• 依賴管理

―   使用 npm audit、Snyk、Dependabot 等工具，定期檢查第三方套件漏洞。

―   鎖定版本（package-lock.json），避免引入未驗證的更新。

4. 測試階段（Testing）

• 安全測試

―   進行動態應用安全測試（DAST），模擬攻擊場景。

―   進行靜態程式碼分析（SAST），檢查反序列化、XSS、RCE 風險。

• 滲透測試

對 SSR、API Route 進行滲透測試，驗證是否能注入惡意 payload。

5. 部署與維運（Deployment & Maintenance）

• 安全配置

―   啟用 WAF（Web Application Firewall）規則，阻擋惡意序列化請求。

―   設定 CSP、HTTP 安全標頭。

• 持續監控

使用 SIEM 或雲端監控工具，偵測異常行為（如反向 Shell、可疑 API 請求）。

• 快速修補流程

建立緊急漏洞修補 SOP，確保能在 CVE 公布後快速升級框架。

6. 教育與流程

• 開發人員安全訓練：教育團隊了解反序列化風險、RCE 攻擊手法。
• 安全代碼審查：在 Code Review 中加入安全檢查清單。