WordPress 7.1.4修補22項資安問題：網站更新後該檢查的5件事

Author 郭光耀
Published 10/30/2026

WordPress 7.1.4於2026年10月28日釋出，是一個安全性版本。官方HelpHub版本頁列出22項安全修補，涵蓋核心更新流程中可能導致遠端程式碼執行(RCE)的競態條件、Interactivity API與多個區塊的儲存型XSS，以及未發布Customizer變更外洩等問題。官方建議立即更新；仍停留在舊主版本的網站，也能透過7.0.8、6.9.11、6.8.12等回溯版本取得修補。

這篇整理我們KYART光沅創意在維運現場會先確認的幾件事：哪些網站風險較高、更新後要檢查什麼，以及為什麼「有開自動更新」不等於「已經安全」。

WordPress 7.1.4修補了哪些問題？

以儲存型XSS為大宗，另有一項更新流程的RCE風險與兩項權限、資訊外洩問題。依官方公告與HelpHub頁面整理：

更新流程競態條件：核心更新期間的時間窗口可能被利用，導致遠端程式碼執行。
儲存型XSS：分布在Interactivity API、Customizer選擇性重新整理、分類(Categories)、圖片、播放清單、留言分頁等區塊，以及個人資料清除請求與特製的使用者登入名稱。
阻斷服務：Interactivity API中的儲存型阻斷服務問題。
權限與資訊外洩：未發布的Customizer變更集可被未登入訪客取得；具留言審核權限的自訂角色，可讀取、編輯、刪除自己無權編輯之文章上的Notes。
內建根憑證更新：因應eMudhra憑證撤銷而調整。

官方公告未列出CVE編號，細節以wordpress.org公告為準。

我的WordPress網站風險高嗎？

看「誰能登入後台」比看網站規模更準。HelpHub說明多數XSS需要Contributor(投稿者)以上權限才能觸發，因此以下情境要優先處理：

開放多位外部作者、協作廠商或實習生編輯權限的內容型網站與媒體。
啟用會員註冊，或把WordPress當作內部入口、知識庫使用的中小企業。
大量使用區塊編輯器與Interactivity API自訂區塊的佈景主題。
多站台(Multisite)架構，這次修補也觸及多站台使用者管理畫面。

儲存型XSS的危險在於惡意內容會被存進資料庫，等管理員打開後台或預覽頁面時才執行，可能被用來竊取登入工作階段，或以管理員身分進行操作。只有單一管理員、沒有其他帳號的小型網站風險相對低，但仍應盡快更新。

資安更新不是按下「立即更新」就結束，而是確認每一個網站都真的更新到位。

開了自動更新，還需要做什麼？

需要，至少要確認版本號。官方表示啟用自動背景更新的網站會開始自動更新，但實務上我們常遇到幾種沒有更新成功的情況：主機檔案權限不足、wp-config.php關閉了自動更新、以Git部署的網站被下一次部署覆蓋回舊版，或容器化部署時映像檔仍是舊版本。

這次修補項目剛好包含「更新流程」本身的弱點，更值得在更新完成後逐項檢查：

到「控制台 > 更新」確認核心版本為7.1.4，或所屬分支的對應回溯版本。
以版本控管或映像檔部署的網站，同步更新程式庫與建置流程，避免下次部署又回到舊版。
盤點後台帳號，移除離職人員、已結案廠商與長期未登入的編輯者帳號。
抽查近期由編輯管理者、編輯建立的文章與區塊內容，留意異常的script或HTML屬性。
使用自訂區塊或Interactivity API的佈景主題，在測試環境確認前台互動功能正常。

KYART光沅創意怎麼處理這類更新？

我們把核心更新當成一次小型變更管理，而不只是一個按鈕。代管維運的網站與系統，會先在測試環境套用並跑過關鍵頁面與表單，再排程正式環境更新，完成後回報版本與檢查結果。

對同時有對外官網與內部資訊系統的客戶，我們會把WordPress放進整體資安盤點：前後端整合的API權限、AWS或GCP上的部署流程是否會覆蓋修補、源碼弱點掃描是否涵蓋自訂佈景主題與外掛。這次以XSS為主的修補也提醒開發團隊，自訂區塊輸出內容時的跳脫與驗證，應該在開發階段就納入程式碼審查，而不是等官方修補才回頭補洞。