React 是 Meta 維護的 JavaScript 前端函式庫，在程式碼託管平台累積 251,048 顆星標與 51,511 次複製。2026 年 10 月 14 日，React 團隊為 React Server Components 發布兩份安全公告，其中一份將問題列為重大等級，描述一個未經驗證的遠端程式碼執行漏洞，影響 19.0 至 19.3 共四條版本線。官方在同日把修正回溯至各版本線的修補版本，並明確建議使用者立即升級。本文依據官方安全公告、版本更新紀錄與儲存庫公開統計資料整理，說明漏洞成因、受影響套件、判斷曝險範圍的方式與升級步驟。
React Server Components 這次修補了什麼漏洞？
React 於 2026 年 10 月 14 日修補兩個漏洞，分別為重大等級的未經驗證遠端程式碼執行，以及高風險等級的伺服器函式阻斷服務，兩者皆已發布對應修補版本。
第一份公告編號 GHSA-xqc2-xf4c-x3h3，標題為 React Server Components 的未經驗證遠端程式碼執行，嚴重性列為重大。官方說明指出，針對支援 React Server Components 的框架所精心構造的酬載，可能導致遠端程式碼執行。公告同時說明觸發條件相當罕見，需要回應同時傳輸多個型別化陣列，並且其中包含攻擊者可控的值。官方在公告中直接寫明建議立即更新。
第二份公告編號 GHSA-h3gv-c5rc-p453，標題為伺服器函式的阻斷服務，嚴重性列為高風險。官方說明指出，攻擊者可透過向伺服器函式端點發送特製的 HTTP 請求觸發此問題，進而導致記憶體耗盡例外或處理器使用率過高。兩份公告的發布時間相差僅數秒，屬於同一批協調揭露的安全更新。
值得注意的是，官方在兩份公告中都以相同方式界定影響範圍。若應用程式的 React 程式碼並未使用伺服器端功能，則不受此漏洞影響；若應用程式並未使用支援 React Server Components 的框架、打包工具或打包工具外掛，同樣不受影響。這項界定將受影響族群收斂至採用伺服器端渲染架構的專案。
為什麼未經驗證的遠端程式碼執行風險特別高？
此漏洞不需任何身分驗證即可觸發，攻擊者無須取得帳號或權杖，只要目標服務對外開放並符合觸發條件，即可嘗試在伺服器上執行任意程式碼。
風險等級的關鍵在於觸發門檻。公告標題中的未經驗證一詞，代表攻擊者不需要通過登入流程、不需要持有有效的工作階段權杖，也不需要事先取得任何憑證。對於把伺服器端功能直接暴露於公網的應用程式而言，這意味著攻擊面等於所有可觸達該端點的來源。
遠端程式碼執行的後果通常比其他類型的漏洞更嚴重。一旦攻擊者能在伺服器上執行任意程式碼，讀取環境變數、存取資料庫連線資訊或橫向移動至內部網路都成為可能，影響範圍會從單一應用程式擴大到整個部署環境。這也是同類漏洞在業界通常被列為最高嚴重性的原因。
不過官方同時強調觸發條件相當罕見，需要回應同時傳輸多個型別化陣列且其中包含攻擊者可控的值。這種描述意味著實際可利用性取決於應用的資料流設計，並非所有符合架構條件的專案都會自動處於可利用狀態。即使如此，由於修正成本相對低廉，官方仍採取立即更新的立場。
哪些套件與版本受到影響？
受影響者為 webpack、parcel 與 turbopack 三個伺服器端傳輸套件，涵蓋 19.0 至 19.3 四條版本線的特定區間。
受影響的套件共有三個，分別是 react-server-dom-webpack、react-server-dom-parcel 與 react-server-dom-turbopack。這三個套件對應不同的打包工具生態，共同點在於它們都負責在伺服器與客戶端之間序列化與傳輸 React Server Components 的酬載，這也是漏洞得以觸發的技術位置。
版本範圍依漏洞類型略有差異。遠端程式碼執行漏洞存在於 19.0.0 至 19.0.8、19.1.0 至 19.1.9、19.2.0 至 19.2.8，以及 19.3.0 之中。阻斷服務漏洞的範圍稍窄，涵蓋 19.0.0 至 19.0.7、19.1.0 至 19.1.8 與 19.2.0 至 19.2.7，未包含 19.3.0。
修補版本則完全一致。官方將修正回溯至 19.0.9、19.1.10、19.2.9 與 19.3.1，四條版本線各有一個對應的修補版本。這種回溯策略讓仍在使用較舊主版本的團隊不需要進行大版本遷移，即可取得安全修正。以套件發布時間觀察，19.3.1、19.2.9 與 19.0.9 在極短時間內相繼上線，19.1.10 則稍晚數分鐘，反映官方對四條線採取近乎同步的發布節奏。
開發者應該如何處理這次修補？
先確認專案是否使用 React Server Components，再將傳輸套件升級至 19.0.9、19.1.10、19.2.9 或 19.3.1，並重新建置部署。
處理順序的第一步是確認自身的依賴關係。如果專案直接引用上述三個套件之一，可直接檢查安裝的版本號是否落在受影響區間。若專案透過框架間接使用，則需檢視框架所依賴的伺服器端傳輸套件版本，因為漏洞位於傳輸層而非框架本身。
第二步是升級。官方為四條版本線分別發布修補版本，開發者可依目前使用的主版本選擇對應目標，例如 19.2 線升至 19.2.9，19.3 線升至 19.3.1。若專案同時引用多個相關套件，應確保它們的版本一致，避免不同傳輸層實作混用造成非預期行為。
第三步是重新建置與部署。這類套件在伺服器端執行，屬於執行期依賴，套件管理工具的更新指令僅改變依賴宣告與本地安裝內容，正式環境仍需重新建置並部署才會生效。部署完成後，建議在測試環境驗證伺服器端渲染與伺服器函式呼叫是否維持正常，特別是涉及多段資料傳輸的回應。對於暫時無法升級的專案，官方未提供替代緩解措施，較務實的做法是先在邊緣層限制伺服器函式端點的存取來源，並將升級排入近期工作項目。
React 的專案數據與維護狀況如何？
專案累積 251,048 顆星標、51,511 次複製與 21,732 次提交，發布 137 個版本，並同時維護四條版本線以支援回溯安全修正。
專案自 2013 年 5 月建立，至今累積 21,732 次提交與 137 個版本發布，標籤數達 180 個。貢獻者活躍度圖表顯示，觀察期間每週提交次數維持穩定，並在 10 月中旬出現集中投入，時間點與本次安全修補及 19.3 線的後續開發相符。
版本策略採用多線並行。官方同時維護 19.0、19.1、19.2 與 19.3 四條線，其中 19.3 為最新穩定線。這種做法讓停留在較舊主版本的團隊仍可取得安全修正，代價是維護者需要對每條分支個別準備修補與發布。以本次事件觀察，四條線的修補在同一時間窗內完成，反映其安全回應流程已具備多線協同的能力。
本次安全修補對應的程式碼變更已併入主線。與 19.3.1 一同發布的傳輸協定改進由專案維護者提交並合併，四個版本線各有對應的提交，內容一致，差異僅在分支基礎。
React 這次修補對生態系統意味著什麼？
此事件顯示伺服器端渲染框架的傳輸層已成為供應鏈風險熱點，安全修正需具備多版本線同步發布能力，才能覆蓋仍在舊版的龐大安裝基礎。
React Server Components 的傳輸層在過去一年已多次成為安全公告的對象，涵蓋阻斷服務與資訊洩漏等類型。本次首度出現重大等級的遠端程式碼執行問題，代表這層程式碼的攻擊價值正在上升。傳輸層的特殊之處在於它直接解析來自網路的序列化酬載，而這類解析邏輯往往是漏洞的溫床。
對採用伺服器端渲染架構的團隊而言，這次事件凸顯依賴清單的可見度問題。多數開發者透過 Next.js 等框架接觸 React Server Components，未必會直接留意底層的三個傳輸套件；一旦漏洞出現在這一層，僅檢查框架版本並不足以判斷曝險狀態。建立可追蹤傳遞依賴的工具鏈，會比逐一比對版本號更可靠。
對開源專案治理而言，四條版本線的同步修補是一項成本不低的承諾。維護者需要在每條分支上完成修正、測試與發布，並協調公告與版本號的對應關係。這種模式對擁有龐大安裝基礎的專案幾乎是必要條件，因為要求所有使用者一次完成大版本遷移並不現實。本次修補的發布節奏顯示，多線安全回應能力已成為大型前端專案的基礎設施之一。
出處連結有哪些？
本文資訊整理自 React 官方儲存庫的安全公告與版本更新紀錄，完整公告內容、受影響範圍與修補版本清單可由下列來源查證。
官方儲存庫位於 https://github.com/react/react，內含完整原始碼、貢獻指南與授權文件。兩份安全公告分別為 https://github.com/react/react/security/advisories/GHSA-xqc2-xf4c-x3h3 與 https://github.com/react/react/security/advisories/GHSA-h3gv-c5rc-p453，內容涵蓋受影響套件、版本區間與建議動作。版本更新紀錄見 https://github.com/react/react/releases，官方文件網站為 https://react.dev，其中提供框架使用說明與伺服器端功能的教學。
常見問題有哪些？
常見疑問集中在三處：使用框架是否必然受影響、升級後是否需要改動程式碼，以及無法立即升級時的替代措施，以下逐項說明。
使用 Next.js 等框架的專案是否一定受影響？
不一定。官方公告界定，只有當應用程式的 React 程式碼使用伺服器端功能，且所處框架、打包工具或外掛支援 React Server Components 時才可能受影響。純客戶端渲染的應用不受此漏洞影響。實務上仍需檢視專案實際安裝的傳輸套件版本，因為漏洞位於傳輸層而非框架層。
升級後需要修改既有程式碼嗎？
修補版本未變更公開 API，屬於相容性更新，正常情況下不需要調整應用程式碼。不過這類套件運行於伺服器端回應路徑，建議在測試環境確認伺服器端渲染、資料串流與伺服器函式呼叫維持正常，特別是涉及多段資料傳輸的回應格式。
無法立即升級時應該採取什麼措施？
官方未針對此次漏洞提供替代緩解措施。較務實的做法是在網路邊緣限制伺服器函式端點的存取來源，降低未經驗證請求可觸達的機率，同時將升級排入近期工作項目。長期停留在受影響版本的風險會隨漏洞細節公開而上升。
總結：React 使用者該如何應對？
建議先確認專案是否使用 React Server Components 及其傳輸套件版本，再升級至對應版本線的修補版；無法立即升級者應限制伺服器端端點的對外暴露範圍。
本次事件的核心是一項被列為重大的未經驗證遠端程式碼執行漏洞，出現在 React Server Components 的傳輸層，影響 webpack、parcel 與 turbopack 三條打包工具路徑，並橫跨四條版本線。雖然官方說明觸發條件罕見，但仍以立即更新作為明確建議，並在同一時間窗內為四條線發布修補版本。
對一般使用者的行動相對明確：確認專案是否引用受影響套件，將版本升級至對應的修補版本，重新建置並部署，再於測試環境驗證伺服器端功能。對採用伺服器端渲染架構的團隊，這次事件也提示傳遞依賴的可見度同樣重要，因為漏洞可能出現在框架之下的傳輸層，而非框架本身。維持依賴清單的清查能力，會是後續面對同類公告時最實際的準備。
