WordPress 站長通常把「趕快更新」當成唯一正解，但這次的 CVE-2026-119977 打破了這個直覺。問題不在漏洞本身有多難修，而在修補的安裝流程仍由網站上舊的、未修補的程式碼負責解壓縮。換句話說，按下更新的那幾秒，反而可能是整個修補過程中風險最集中的時刻。最近這篇 Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time，對講究縱深防禦的站長來說，這則公告確實很重要，主要是我們在更新之外還做了哪些加固工程。
漏洞本體：暫存資料夾裡多了一份可執行的安裝程式
這次的 WordPress 資安漏洞由 Picus Security 研究員 Umut Bayram 發現，編號 CVE-2026-119977，影響 WordPress 4.7 到 7.1.3。當網站執行完整套件更新時，WordPress 會把新版本解壓縮到 wp-content/upgrade 底下的暫存資料夾，而這份副本包含 WordPress 安裝程式，網頁伺服器通常又能直接存取到它。
沒有帳號的攻擊者只要猜中資料夾名稱，並趕在 WordPress 刪除副本之前存取到安裝程式，就能在伺服器上執行程式碼。美國網路安全與基礎設施安全局 CISA 本週稍早已把這個漏洞列入已知遭利用漏洞清單，依據是積極利用的證據，但未描述攻擊細節。
時序漏洞的核心：修補由舊程式碼執行
WordPress 上週在 7.1.4 版釋出更新檔，並為 4.7 起的分支提供對應更新，列於安全公告 GHSA-4w3m-c66w-69mg。修補會讓暫存資料夾改用隨機名稱，但安裝這個修補的更新，用的仍是網站上舊的程式碼來解壓縮，這就是問題所在。
在執行 5.9 或更新版本的網站上，舊程式碼會用下載的檔案名稱來命名資料夾，因此名稱還能被預測最後一次。4.4 到 5.8 版的舊程式碼則會在資料夾名稱加上隨機字元，名稱因此被隱藏，除非網站透過錯誤訊息等管道洩漏名稱。
修補前，攻擊者可用安裝程式把新的設定檔 wp-config.php 寫入暫存副本，更新再把這個檔案覆蓋掉網站真正的檔案。修補中阻止這件事的部分，在安裝修補的更新期間已經生效，因為 WordPress 是用新程式碼把檔案複製到位。但攻擊者若抓住更新期間的窗口，仍可讓暫存副本使用自己的資料庫，登入後以網頁伺服器權限執行 PHP，然後在副本被刪除前讀寫正式網站內的檔案。
曝露條件很細，決定因素不是套件種類
不是每次更新都會曝露安裝程式。完整套件一定包含安裝程式檔案，為特定起始版本打造的精簡套件，只有在剛好包含安裝程式檔案時才會曝露。允許自動背景更新的網站，WordPress 會用同一個更新程式與相同步驟自動安裝修補，因此自動更新並不是額外的保護層。
查詢 WordPress.org 更新服務的結果是，分支內更新例如 7.1.3 到 7.1.4 提供的是精簡套件，自動更新也一樣，跨分支更新例如 7.0.7 到 7.1.4 則只提供完整套件。網站也不一定拿得到精簡套件，若網站核心檔案的校驗碼與官方不符，或更新屬於重新安裝，WordPress 會退回完整套件。
Bayram 在 11 月 6 日補充，精簡更新是否曝露取決於該套件包含什麼，精簡套件只含兩個版本間變更的檔案，若這些檔案不包括安裝程式，暫存副本就無法以 WordPress 安裝的形式執行。他有提到，決定因素不是精簡套件或完整套件，而是網站上已安裝的更新程式是否已經修補。
攻擊窗口只有幾秒，掃描者卻盯了 14.5 小時
指派 CVE 編號的 Wordfence 在發布當天部署防火牆規則後 9 分鐘，就開始看到攻擊嘗試。兩個最忙碌的來源持續檢查小批網站約 14.5 小時，Wordfence 認為這與嘗試抓住網站更新那一刻的行為吻合。
Wordfence 在 CVE 紀錄給的 CVSS 分數為 8.1，實驗室測試中窗口只持續幾秒，WordPress 自己的公告卻把這個漏洞評為低風險。這個落差反映的是利用條件嚴格，而非後果輕微。本週稍早起，公開 GitHub 儲存庫已出現被作者描述為該漏洞利用程式的程式碼，其中一個說自己的程式碼也能用在完整套件更新期間仍使用可預測資料夾的網站，但尚未確認是否真的有效。
最簡單有效的動作：趕快先封鎖 wp-content/upgrade 的網頁存取
第一優先是讓網頁伺服器完全不提供 wp-content/upgrade。WordPress 是直接在磁碟上操作該資料夾，封鎖網頁存取不會影響更新。Nginx 可在設定檔加入 location ^~ /wp-content/upgrade/ 區塊並設定 deny all，Apache 可在虛擬主機設定的 Directory 區塊加入 Require all denied。
若只能改 .htaccess，可在 WordPress 根目錄的 .htaccess 加入 RedirectMatch 403 ^/wp-content/upgrade/，並放在 WordPress rewrite 規則之前。要注意不要在 wp-content/upgrade 內放 .htaccess，因為舊更新程式在解壓縮前會刪除該資料夾內所有東西，需要時檔案已經不見。設定完成後，確認請求 /wp-content/upgrade/ 回應 403。
另一條安全路線是手動更新，並在網頁根目錄外進行。先備份檔案與資料庫，在網頁伺服器不會提供的資料夾解壓縮新版本，複製核心檔案時不要動到 wp-config.php 或 wp-content，再執行 WordPress 資料庫更新，這樣就不會在網頁可達的資料夾產生暫存安裝程式。WP-CLI 的 wp core update 不能取代上述做法，因為它執行同一個更新程式，也把套件解壓縮到同一個資料夾。
版本落後的網站要正視分支結束支援的問題。WordPress 4.6 及更早版本已不再收到安全更新，沒有修補，Bayram 說這個漏洞可追溯到 2008 年發布的 WordPress 2.7，這些網站應遷移到受支援的版本。留在受影響版本、未及時更新的網站，Wordfence 建議檢查 wp-content/upgrade 下出現非預期的 PHP 檔案請求、沒人認識的管理員帳號、沒人安裝的外掛、以及 wp-content/upgrade 裡沒人放過的 PHP 檔案。
CyberQ 觀點
本站以市場上幾個大網站的實際 generator 標籤確認，許多網站執行 WordPress 7.1.4，已包含這次修補。實測 /wp-content/upgrade/ 原先回應 HTTP 200，現已改為 403，且該資料夾內不存在的檔案同樣回應 403，其他目錄的不存在檔案則是 404，可確認封鎖規則確實生效，不是缺少索引檔造成的假象。
7.1.4 之後的更新已使用隨機資料夾名稱，風險大幅降低，但依研究員建議，仍應加上 403 規則做縱深防禦。這次事件確實有它的重要性，修補流程本身也是攻擊面，最簡單有效的動作是先關掉不該對外開放的門扉。
