WordPress 漏洞 CVE-2026-119977 列入 CISA KEV：升級到 7.1.4 前，先封鎖 wp-content/upgrade
台灣很多企業的官網、活動頁、電商與部落格都使用 WordPress，通常架在 AWS、GCP、Azure 的虛擬主機或代管主機上，並開啟自動更新。WordPress 核心漏洞 CVE-2026-119977 已在 2026-11-03 被美國 CISA 列入「已知遭利用漏洞（KEV）」清單，聯邦機構的修補期限只有 3 天（2026-11-06）。
這個漏洞的特別之處在於：攻擊者鎖定的是「網站正在更新的那幾秒鐘」。換句話說，還沒修補的網站，每次執行完整的核心更新（包括自動更新），都會短暫打開攻擊空檔；而常見的 WordPress 資安外掛，對這種攻擊也可能無能為力。以下整理官方公告重點與企業可以馬上做的檢查。
漏洞重點：更新時暫存的安裝程式，可能被拿來執行程式碼
以下為官方與資安研究機構公告整理的事實（查核日期：2026-11-05）。
CVE-2026-119977 是什麼
漏洞類型： 核心更新流程的競爭條件（TOCTOU）。使用完整套件更新核心時，受影響版本會把新檔案解壓到 wp-content/upgrade 底下一個可預測、可從網頁存取的目錄，裡面包含 WordPress 安裝程式（setup-config.php）。未經驗證的攻擊者若在解壓的瞬間請求這個安裝程式，就可能進一步在伺服器上執行 PHP 程式碼。
嚴重程度： Wordfence 評為 CVSS 8.1（High）；WordPress 官方 GitHub 公告則標示為 Low，主要因為攻擊必須「搶到時間差」。
修補時間： WordPress 於 2026-10-28 發布 7.1.4 安全更新，並回溯修補到 4.7 以上所有分支。
CISA KEV： 2026-11-03 列入，代表 CISA 認定已有實際遭利用的證據。
修補版本對照
WordPress 分支 | 受影響版本 | 修補版本 |
|---|---|---|
7.1 | 7.1.0–7.1.3 | 7.1.4 |
7.0 | 7.0.0–7.0.7 | 7.0.8 |
6.9 | 6.9.0–6.9.10 | 6.9.11 |
6.8 | 6.8.0–6.8.11 | 6.8.12 |
6.0–6.7 | 各分支舊版 | 6.7.11、6.6.11、6.5.14、6.4.14、6.3.14、6.2.15、6.1.16、6.0.18 |
4.7–5.9 | 各分支舊版 | 最低為 4.7.39（詳見官方公告） |
4.6 以前 | 不再提供安全更新 | 需升級到仍受支援的版本 |
官方修補方式是把暫存目錄名稱加上隨機字元、補上防止列出目錄的 index.php，並避免把暫存的設定檔帶進正式環境。7.1.4 同時修補了其他多項問題，主要是需要登入帳號的儲存型 XSS，以及未公開 Customizer 變更可被未登入者讀取等。
攻擊者已經在「守株待兔」
Wordfence 在 2026-10-28 20:30（UTC）部署防火牆規則，9 分鐘後就攔到第一筆攻擊，前 21 小時記錄超過 18,500 次針對暫存安裝程式路徑的請求。其中兩個最大的來源，對一小批網站反覆輪詢約 14.5 小時，目的就是等到網站更新的那幾秒。
為什麼外掛型防火牆擋不住
Wordfence 與 Patchstack 都指出，這個攻擊是直接請求暫存目錄裡的 PHP 檔案，不會先載入正式網站的 WordPress，因此跟著 WordPress 一起載入的防火牆外掛不會執行。Wordfence 建議用戶確認已啟用 Extended Protection（讓防火牆在 PHP 檔案被執行前先載入），並強調防火牆規則不能取代更新；Wordfence 免費版用戶要到 2026-11-27 才會收到這條規則。
Patchstack 的建議則更直接：在網頁伺服器層禁止從網頁存取 wp-content/upgrade/，並關閉目錄列表。平常這個目錄應該只有一個 index.php，封鎖它幾乎沒有副作用。
對企業的影響
以下為 WeWinCloud 的分析與建議，非官方說法。
「升級」本身就是風險時段。 還停在舊版的網站，在升級到 7.1.4 的過程中仍會經歷一次攻擊空檔。比較穩妥的順序是：先在網頁伺服器或雲端 WAF 封鎖 wp-content/upgrade，再執行升級。
自動更新不等於已經更新。 自動更新可能因檔案權限、磁碟空間、主機設定或被手動關閉而失敗。企業常有多個由行銷部門或外包廠商建置的 WordPress 站台，很容易漏掉。
官方標示 Low，不代表可以等。 這次官方評級、Wordfence 評分與 CISA KEV 的判斷差異很大。對外網站的修補優先順序，應同時參考是否已遭利用，而不是只看單一評分。
防護要放在 WordPress 之前。 這類攻擊說明了為什麼網站防護不能只靠外掛，Nginx／Apache 規則、雲端 WAF 或 CDN 邊緣規則都能在請求抵達 PHP 前先攔下。
企業 6 步驟檢查與修補
盤點所有 WordPress 站台： 包含官網、活動頁、子網域、測試站與外包廠商代管的網站，記下版本與主機位置。
確認版本： 到「控制台 → 更新」確認已是 7.1.4，或所屬分支的修補版本；4.6 以前的版本需規劃升級。
先封鎖升級暫存目錄： 在網頁伺服器設定拒絕存取 wp-content/upgrade/（例如 Nginx 對該路徑 deny all，Apache 在該目錄設定 Require all denied），或在 AWS WAF、Cloudflare 等雲端 WAF 加上路徑封鎖規則，並確認關閉目錄列表。
再執行升級： 盡量安排在維護時段手動升級並確認結果，不要只等待自動更新。
使用資安外掛者，確認防護設定： 例如 Wordfence 確認已啟用 Extended Protection；但仍以完成更新為主。
檢查是否有入侵跡象： 回頭檢查存取日誌中對 wp-content/upgrade 底下 PHP 檔案的請求、陌生的管理員帳號、未知外掛，以及不是你們放上去的 PHP 檔案。曾有可疑紀錄的站台，應更換管理員密碼與資料庫帳密，並請資安人員進一步調查。
情境 | 建議優先順序 |
|---|---|
版本未修補、對外公開的官網或電商 | 立即封鎖 wp-content/upgrade，再升級並檢查日誌 |
已自動更新到修補版本 | 確認版本與目錄設定，保留封鎖規則作為縱深防禦 |
外包廠商代管的站台 | 要求廠商提供版本與更新紀錄，確認已修補 |
4.6 以前或已停止維護的舊站 | 評估升級或下線，暫時以 WAF 限制存取 |
常見問題 FAQ
網站已開啟自動更新，還需要處理嗎？
需要確認。Wordfence 建議實際到控制台檢查版本，而不是假設更新已完成。自動更新失敗或被關閉的情況並不少見。
安裝了 WordPress 資安外掛，就能擋下這個攻擊嗎？
不一定。攻擊直接請求暫存目錄裡的 PHP 檔案，不會載入正式網站的外掛。建議在網頁伺服器或 WAF 層封鎖 wp-content/upgrade，並盡快更新。
封鎖 wp-content/upgrade 會影響網站更新嗎？
依 Patchstack 說明，這個目錄在兩次更新之間只會有一個 index.php。更新是由伺服器端的 PHP 直接處理檔案，一般不需要從網頁存取這個目錄，因此封鎖的副作用很小；實際設定前仍建議先在測試環境確認。
WeWinCloud 能提供什麼協助
WeWinCloud 提供資安防護服務，包括 WAF 網站防火牆、DDoS 防護、EDR／MDR 端點防護，以及資安顧問與弱點評估；也提供架構規劃與上雲服務，協助檢視 WordPress 這類對外網站的主機架構、存取控制與備援設計。
如果你不確定公司有多少個 WordPress 站台、版本是否已修補，或想在雲端 WAF 加上防護規則，可以先和我們聊聊目前的環境。
延伸閱讀
參考資料
留言