WordPress 核心漏洞 CVE-2026-87902｜8.1 分風險、影響版本與修補教學
Kyle 2,333 字 · 約 8 分鐘

WordPress 在 2026 年 9 月 22 日發布 7.1.2 安全更新，修補 CVE-2026-87902。這個核心漏洞可讓未登入的攻擊者誘使網站載入不該當成頁面範本的本地 PHP 檔案；伺服器與佈景主題符合特定條件時，可能進一步遠端執行程式碼。官方建議立即更新。

「7.1.1 以下、8.1 分」可以用來辨識這則消息，但實際處理還要看評分版本與所屬分支的修補版號。舊分支已收到回補，不能把所有低於 7.1.2 的版本都視為尚未修補；已經更新到 7.1.1 的網站，則仍需要這次安全更新。

WordPress 核心與頁面範本是什麼

WordPress 是由開源社群維護的內容管理系統，可以透過後台管理文章、頁面與網站內容。核心提供基本運作，外掛擴充功能，佈景主題負責版面。頁面範本則是佈景主題用來決定個別頁面如何呈現的檔案，傳統主題常以 PHP 撰寫。

這次問題出在核心的 get_page_template() 頁面範本解析流程。路徑穿越是指檔案路徑突破原本應限制的目錄；當程式把目錄外的本地檔案當成程式載入，就形成本地檔案包含。若被載入的 PHP 能被用來執行攻擊者指定的操作，就可能形成遠端程式碼執行，也就是 RCE。

因此，這是一項 WordPress 核心修補，不能只更新外掛就當成處理完成。佈景主題與伺服器設定會影響能否利用，但修補入口仍是 WordPress 核心版本。事件與修補說明可見 WordPress 官方公告 。


Sponsored Links

8.1 分與 9.2 分的差別

CVSS 是描述漏洞嚴重程度的評分系統。不同版本的評分模型會得到不同數值；這次看到的 8.1 與 9.2 都指向同一個 CVE，不能解讀成漏洞突然變嚴重，或把分數當成遭入侵的機率。

來源與評分版本分數嚴重程度
新加坡 CSA 通報，CVSS 3.18.1 / 10High，高風險
WordPress 官方 GHSA，CVSS 4.09.2 / 10Critical，重大風險

新加坡 CSA 在 9 月 24 日的通報 使用 8.1 分，並指出已出現漏洞利用活動及公開的概念驗證程式。WordPress 官方安全公告則列出 9.2 分。兩者都支持同一項處置：確認網站已安裝修補，不要只因攻擊需要前提就延後更新。

哪些條件可能導致遠端執行程式碼

官方將這個問題描述為「有條件的 RCE」。未修補核心只是起點，佈景主題的目錄結構與伺服器上的 PHP 檔案，也會影響攻擊是否成立。

WordPress 漏洞利用條件示意：佈景主題有 page- 目錄，加上伺服器存在可利用的 PHP 檔案，可能導致遠端執行程式碼
遠端執行程式碼需要主題與伺服器條件同時成立。

WordPress 官方安全公告 列出的條件包括：啟用中的子主題或父主題，頂層有名稱以 page- 開頭的目錄，例如 page-templates；伺服器上也存在可由網站服務帳號讀取的目標 PHP 檔案。公告舉出的主題包括 Twenty Twelve、Twenty Fourteen、Neve、Hestia 與 Sydney，這些是例子，不是完整清單。

其中一條已知利用鏈涉及 PEAR 的 pearcmd.php，並需要 PHP 的 register_argc_argv 設為 On。官方也點名 Docker 官方 php 映像，以及使用 PHP 8.5 之前版本的 cPanel 預設設定。這不代表每個 Docker 或 cPanel 網站都能直接被接管，還要同時檢查主題與實際部署條件。

網站管理者通常不必等到完成所有利用條件分析才更新。條件清單適合用來安排排查優先順序；主題改版、切換或伺服器設定變更，都可能改變原本的判斷。

受影響版本與修補版本

7.1 分支的受影響版本是 7.1.0 至 7.1.1，修補版是 7.1.2。舊網站若暫時無法跨分支升級，可先安裝同分支的安全修補。下表依 官方版本文件 整理本次修補版號；它們是本漏洞的修補基準，不代表未來永遠足夠。

WordPress 分支本次修補版本
7.1、7.07.1.2、7.0.6
6.9、6.8、6.7、6.66.9.9、6.8.10、6.7.9、6.6.9
6.5、6.4、6.36.5.12、6.4.12、6.3.12
6.2、6.1、6.06.2.13、6.1.14、6.0.16
5.9、5.8、5.75.9.18、5.8.17、5.7.19
5.6、5.5、5.45.6.21、5.5.22、5.4.23
5.3、5.2、5.1、5.05.3.25、5.2.28、5.1.26、5.0.29
4.9、4.8、4.74.9.33、4.8.32、4.7.37

例如，7.0.5 需要更新，7.0.6 已包含本次修補；不能因為 7.0.6 的數字低於 7.1.2 就判定它仍有這個漏洞。官方也提醒，只有最新版本受到積極支援，舊分支回補不等於完整的長期支援承諾。4.6 與更早版本已不再收到安全更新，不應因為沒出現在修補表就認為安全。

網站如何更新與確認修補

一般站長可使用後台更新；有 SSH 與 WP-CLI 的管理者則可用指令處理。更新前先備份資料庫和網站檔案，確認備份能取回，並留意直接修改過的核心檔案可能被更新覆蓋。代管網站應依主機商提供的核心更新流程操作。

WordPress 後台更新

  1. 以管理員登入，開啟「控制台 → 更新」，確認目前 WordPress 版本與可更新版本。
  2. 完成備份後，使用「立即更新」，安裝含有本次修補的版本。若目前有更新的正式版，應一併評估相容性後採用。
  3. 更新完成後重新讀取版本號，對照前面的分支修補表；再檢查首頁、文章、表單與後台等主要功能，必要時清除快取。

WordPress 支援背景安全更新，但仍應確認實際結果。沒有收到通知，或曾開啟自動更新，都不能替代版本檢查。操作細節可參考 官方更新指南 。使用 Docker 管理資料庫的網站，也可參考本站的 資料庫自動備份教學 ；資料庫備份之外，還需要網站檔案備份。

WP-CLI 更新與核心檢查

以下適用於已安裝 WP-CLI、具有檔案更新權限，且已完成備份的管理者。在目標 WordPress 安裝目錄執行；--minor 只更新目前分支的小版本，適合先取得同分支修補。這些是依官方文件整理的操作範例，不是本站的實測紀錄。

# 查看目前核心版本
wp core version

# 更新目前分支的小版本，會修改核心檔案
wp core update --minor

# 再次確認版本，並比對官方核心檔案校驗碼
wp core version
wp core verify-checksums

wp core update 不加 --minor 時預設更新到最新版本，可能跨分支，應先確認相容性。 核心校驗碼檢查 可協助找出核心檔案差異，但不會完整檢查外掛、佈景主題、上傳目錄或資料庫，因此通過不代表整個網站未被入侵。

已有攻擊活動，更新後還要檢查什麼

Patchstack 的 一手觀測報告 在 9 月 23 日更新，指出流量已從探測擴展到嘗試透過 PEAR 寫入 PHP 檔案。這表示不能再把事件當成只有理論風險；但在日誌看到一筆攻擊請求，也不等於已經成功入侵。

建議保留更新前後的網站與防火牆紀錄，檢查 pagename 中異常的編碼路徑、涉及 pearcmd 的請求，以及 /tmp、/var/tmp 等位置出現的不明 PHP 檔案。這些是調查線索，應結合回應內容、檔案來源與時間判斷，不能只靠 HTTP 200 或單一檔名下結論。

暫時無法更新時，可請主機商確認是否部署針對此漏洞的 WAF 規則。關閉 register_argc_argv 可阻斷上述 PEAR 利用鏈，但不會修好核心的檔案包含問題，也不能代替更新。PHP 設定應由管理者依實際 Web 執行環境調整，不能只看終端機 PHP 的設定就推定網站也相同。

如果已發現不明管理員、被竄改檔案或可疑程式，應保留證據，交由主機商或資安人員處理，並檢查帳號、憑證與可還原的乾淨備份。依 WordPress 安全加固文件 的原則，更新只是降低再次被利用的機會；已留下的惡意檔案不會因版本升級自動消失。

常見問答

修補的判斷依據是核心版本、所屬分支與實際更新結果，登入防護或外掛狀態不能單獨回答這個問題。

更新到 7.1.1 就安全了嗎

7.1.1 仍在本次受影響範圍。7.1 分支需要 7.1.2 或包含此修補的後續版本，先前已做過安全更新也應再次確認。

修改登入網址或啟用雙重驗證有用嗎

這些措施能改善登入保護，但本漏洞不要求攻擊者先登入，不能靠它們修補頁面範本解析問題。仍應更新核心。

沒有使用公告列出的佈景主題就能略過嗎

不能只靠主題名稱排除。官方列出的是例子，實際條件包含啟用中子主題與父主題的目錄結構。直接安裝核心修補，比長期依賴目前環境剛好不符合利用條件更穩妥。

參考來源

Post Views: 11
Tags:
Sponsored Links

發佈留言