Skip to content
AI Ferryman Alex
Go back

WordPress 一週前就發了補丁,CISA 現在還要求查有沒有被動手腳

CISA 是美國網絡安全和基礎設施安全局。它在 11 月 3 日要求聯邦機構把這個漏洞補上,而且補完之後還要再查一遍,看有沒有人已經進來過。

這個要求是寫給聯邦機構的,所以它管不到你。但是它要求去查的那一遍,你在自己的網站上同樣值得做,因爲這個漏洞傷網站的方式,不會因爲網站是不是聯邦機構的就有什麼不同。

你上次登錄自己 WordPress 網站的後臺,是什麼時候?我說的後臺,是網站自己的那個後臺,就是能看到版本號的那個頁面。主機商給你的控制面板是另一個東西,所以那個不算數。

如果你想了半天才想起來,那麼這篇就是在說你的網站。因爲會被這個漏洞傷到的,正是那些沒有人登錄的網站:它們一直跑着舊軟件,而站長以爲有別人在替自己盯着。

10 月 28 日,WordPress 發佈了 7.1.4,這次發佈裏的一個修復,堵住了核心更新過程中的一個漏洞。到了 11 月 3 日,CISA 把這個漏洞列進了已知被利用漏洞清單,它的編號是 CVE-2026-119977。

這份清單隻收已經被攻擊者在真實系統上用過的漏洞,所以一個漏洞能進這份清單,就說明已經有人在真實系統上拿它動過手了。這一條還多帶了一項要求,因爲 CISA 給它標了取證排查。

取證排查的意思是,受影響的系統不光要把補丁裝上,而且還要去查有沒有已經被人動過手腳的痕跡。

CISA 給聯邦機構定的處理期限是 11 月 6 日。對一個 WordPress 網站來說,處理是一個很具體的動作,因爲它指的就是升到 7.1.4,或者升到你所在分支上那個已經修好的版本。

你的網站沒有這個期限,因爲這條要求和這個日期都是寫給聯邦機構的。但是你也不能把這個日期當成寬限期,因爲試探根本沒有等這個日期。補丁發佈後的頭 21 小時裏,衝着更新解包出來的安裝文件去的請求就已經超過了 18500 次。

核心更新換掉的是網站正在跑的那套軟件,而換的過程當中,服務器還在照常給訪客提供頁面。更新進行時,WordPress 會把新版本解包到一個叫 wp-content/upgrade/ 的文件夾裏。

在很多服務器上,網頁服務器會把這個文件夾裏的文件直接發給任何來要的人,就跟發普通頁面一樣。解包出來的那份副本會在文件夾裏停留幾秒鐘,安裝文件也在裏面,然後 WordPress 把更新做完,再把文件夾清掉。

如果攻擊者的請求正好落進這幾秒鐘,那麼他就能把文件夾裏那些解包出來的安裝文件跑起來。然後他可以順着這一步,走到在你的服務器上運行他自己的代碼,而且整個過程他不需要登錄。

這就是這件事裏所說的遠程代碼執行:一個在你的網站上沒有賬號、也沒有密碼的人,最後在你的機器上跑起了他自己選的代碼。

更新窗口的機制,與排查的五站

Wordfence 是一家給 WordPress 網站做防護的公司,它也發佈 WordPress 漏洞方面的研究。它給這個漏洞打了 8.1 分,滿分是 10 分,屬於高危那一檔。

11 月 3 日,主機公司 Carthage Electronics 在它的安全博客上發了一份威脅簡報,這份簡報解釋了分數爲什麼沒有打到頂。因爲攻擊者必須正好撞上一個很短的時間窗口,所以分數停在了高危這一檔。

一個人坐在鍵盤前面,一邊刷新一邊碰運氣,他幾乎不可能撞進一個只有幾秒的窗口,因爲一個人能試的次數就那麼多。但是腳本不一樣,因爲腳本可以把安裝文件一次又一次地要,成千上萬次,要多久都行。而腳本等的只有一件事,就是它在要的這段時間裏,你的網站正好開始一次核心更新。

補丁發佈後的頭 21 個小時裏,Wordfence 記錄到超過 18500 次請求,這些請求要的都是那些解包出來的安裝文件。所以第一個數字數的是請求,因爲每一次請求,都是向服務器要一個那樣的文件。

The Hacker News 在 10 月 30 日報道說,在那篇報道之前的 24 小時裏,Wordfence 攔下了 62969 次嘗試。第二個數字數的是被攔下來的嘗試。它跟第一個數字數的不是同一段時間,因爲第一個數字覆蓋的是補丁發佈後的頭 21 小時,而第二個數字覆蓋的這 24 小時在那之後。

這兩個數字都不能證明已經有網站被拿下了,而且 Carthage 那份簡報也記了同樣的界限:到 11 月 3 日簡報發出的時候,還沒有人公開確認過有網站是通過這個漏洞被拿下的。

這個漏洞影響 WordPress 從 4.7 到 7.1.3 的每一個版本,而修復它的版本是 7.1.4。如果你的網站釘在一箇舊分支上,那麼你不用跳到最新的 WordPress 也能拿到這個修復,因爲同一份修復被向後移植了。

向後移植的意思是,把這份修復搬回舊的分支,再在舊的分支上發佈出來。舊分支上的版本從 7.0.8 一路到 4.7.39,中間的 6.9.11、6.8.12、6.7.11 也都有對應的版本。

Carthage 的簡報說,大多數網站上週已經通過後臺自動更新自己拿到了 7.1.4,所以如果你的網站也是這樣,那麼打補丁這一環就已經做完了。

同一份簡報還點名了它擔心的網站。它先說的是自動更新被關掉的那些網站。因爲在那樣的網站上,不管 WordPress 發出什麼安全版本,都不會有任何版本自己送上門來。

簡報還點名了釘在舊分支上的網站。釘在舊分支上並不等於拿不到修復,因爲它所在的分支裏也有帶着同一份修復的向後移植版本。但是向後移植版本仍然要靠一次真的在那個網站上跑起來的更新來安裝,而釘在舊分支上的網站,往往正是那些很久以前就不再跑更新的網站。

簡報說的第三種網站,纔是這篇真正想說的那種:名義上有人管的網站。這樣的網站,要麼是開發者給搭的,要麼是服務商在託管,而且每個相關的人都覺得它有人在照看。

但是照看這件事要算數,得先有一個人真的登錄進去。這個人要讀過版本號,也要確認過更新到底裝沒裝上。所以在這種名義上有人管、實際上沒有人登錄的網站上,一次沒裝上的更新可以幾個月都沒人發現。因爲沒有任何人會專門留一個時刻,去看這個網站現在是什麼狀態。

一個網站通過這樣的漏洞被人拿下之後,它很少會自己喊出來。首頁通常照樣能打開,看上去也照樣正常,因爲首頁要是被人改得亂七八糟,當天就會被發現,然後被清理掉。

安安靜靜的那種版本能留得更久:網站開始掛垃圾頁面,或者替別人的騙局存放文件,或者把訪客送到釣魚頁面上去。而站長往往是最後一個知道的,而且消息是從外面傳到他耳朵裏的:要麼是主機商把他的賬號停了,要麼是訪客的瀏覽器開始警告大家不要進這個網站。

CISA 這次的要求比打補丁多,就是因爲結局可以這麼安靜。CISA 給這條標了取證排查,翻成大白話就是:把修復裝上,然後再去找有沒有已經被人動過手腳的痕跡。

裝上補丁能把這個漏洞去掉,所以下一次更新的時候,那些解包出來的文件就不能再用這個辦法被人利用了。但是補丁刪不掉攻擊者可能已經留在你服務器上的代碼,而且它也撤不掉攻擊者可能已經給自己建好的管理員賬號。

要查的東西一共五站,第一站就是後臺。打開後臺,再打開更新,把屏幕上的版本號讀出來。它應該是 7.1.4,或者是你所在分支的最新版本。

如果你的網站把自動更新關掉了,那麼你今天就手動把更新跑一遍。但是在跑更新之前,你先看一眼有沒有近期的備份。如果沒有備份,那麼你先把備份做了,然後再跑更新。

然後打開服務器上的 wp-content/upgrade/ 文件夾,看看裏面留了什麼。兩次更新之間,這個文件夾裏應該什麼都沒有,所以裏面要是留下了文件夾或者 PHP 文件,那就需要一個說法。

再然後,去服務器日誌裏查,在更新跑過的那些時間前後,有沒有反覆請求 wp-content/upgrade/ 下面文件的記錄。解包出來的安裝文件裏有一個叫 setup-config.php,而在那些請求裏反覆出現的,就是這個名字。

最後兩站都是後臺裏的清單。打開用戶清單,把管理員賬號一個一個看過去。因爲一個你不認識的賬號,就是攻擊者會留下來的那種東西,而且它的名字也不會是你起的。

然後打開插件清單,用同樣的辦法看一遍,找有沒有你自己從來沒有裝過的東西。這兩份清單都不長,所以這一部分的檢查花不了幾分鐘。

如果這兩份清單裏有任何一份查出了你不認識的東西,那麼你就按網站已經被拿下來處理,不要再把它當成日常維護。先從一份乾淨的備份裏把網站恢復出來。

然後在恢復出來的網站上,把管理員密碼和數據庫密碼都換掉,再把 wp-config.php 裏的鹽值換掉。鹽值是 WordPress 混進登錄狀態裏用來保護它的一串祕密字符串,所以換掉鹽值,就會把當前所有登錄着的會話都簽出去。

把所有人簽出去,跟改密碼是兩件不同的事。這兩件事都要做。而且都要在乾淨的那份網站上做,不能在已經被動過的那份上做。

還有一處改動是在服務器那一層做的:讓網頁服務器拒絕瀏覽器對 wp-content/upgrade/ 下面任何東西的請求。在 nginx 上,這是一段 location 配置,它拒絕發往這個路徑的每一個請求。

在 Apache 上,這是一條 RedirectMatch 規則,它對這個路徑的請求回答 403。如果你自己改不了服務器配置,那麼你就請你的主機商幫你把這條規則加上。

更新的時候解包還是會發生,解包出來的副本也還是會在那個文件夾裏停留同樣的幾秒鐘。但是這條規則把從網頁進來的路堵上了,因爲對那些文件的請求現在得到的回答是拒絕,而不是文件本身,所以安裝文件從網頁上就夠不着了。

正常情況下,也沒有任何正經東西需要用瀏覽器去讀這個文件夾裏的文件。

網站前面的網頁應用防火牆會讀每一個進來的請求,並且把那些它認出來是來探安裝文件的請求擋下來。這跟上面那條服務器規則是兩件不同的事,因爲服務器規則拒絕的是發往這個路徑的每一個請求,不管是誰發的,也不管它要什麼。

而防火牆只拒絕它認得出來的請求,所以一個形狀是它不認識的探查,就會穿過它,落到網站上。而且防火牆也改不了 WordPress 裏面的更新過程,因爲它後面的解包還是照原來的樣子在發生。能把這個漏洞本身去掉的,只有把 WordPress 更新掉這一件事。

我維護別人的軟件維護了很多年,我一直學不會去相信“有人管的網站”這句話。因爲這句話要站得住,得有人能說出上次登錄的人是誰,也能說出那個人在裏面看到了什麼。

如果你跑着一個 WordPress 網站,那麼你今天就去把它的版本號讀一遍。這篇裏所有的檢查,我這週會先做的就是這一件。

要是這篇讓你打開了後臺,歡迎訂閱或者收藏這個博客。我會持續分享 AI、安全和開源方面的乾貨,下一篇還是這種你自己就能上手查的東西。

https://carthageelectronics.com/november-3-2026-cve-threat-brief/


在 X 上討論→

評論都在 X 上——回覆、引用和討論都在那邊進行。