wp2shell：花 25 美元、十小時內發現的原版 WordPress RCE

2026 年 7 月 17 日，Searchlight Cyber 發布了 wp2shell，這是一條存在於 WordPress 核心的未經身分驗證遠端程式碼執行鏈，不需要外掛、佈景主題或登入。只要對一個標準安裝發出匿名請求就足夠：該公司公告指出，「此攻擊沒有任何先決條件，匿名使用者即可在未安裝任何外掛的 WordPress 標準安裝中加以利用。」這條鏈結合了兩個漏洞——CVE-2026-63030，這是 WordPress REST API 批次端點中的路由混淆漏洞，專案公告將其列為嚴重；以及 CVE-2026-60137，即 SQL 注入，存在於 author__not_in 這個 WP_Query 參數中，公告將其列為中等。WordPress 同日發布了 WordPress 7.0.2，專案公告列出 WordPress 6.9.5、WordPress 6.8.6 與 WordPress 7.1 beta2 都包含相同修正。Searchlight 引用的估計指有超過 5 億個 WordPress 網站。這條鏈背後的研究人員 Adam Kues 表示，它出自一次 GPT-5.6 Sol Ultra 執行，該次執行基於 OpenAI 為一道數學問題發布的提示：最多四個代理、搜尋至少六小時，升級利用又約四小時，模型使用費約 25 美元。該紀錄以研究發現歸檔——依該檔案庫自身的評級尺度為高嚴重性、A 級信心、未記錄任何現實世界危害、日期為單一日——而 Orca AI Incident Archive 收錄了它，並在下方附上主要文件的連結。

這次披露是經過協調的。Searchlight 在7月17日暫未公布技術細節，讓防禦方有週末時間進行升級；Kues 則於7月20日發布完整技術說明。到那時，這條串聯漏洞利用鏈已被獨立重現：Searchlight 表示，Calif 與 Hacktron 在其他概念驗證程式於 GitHub 出現之前，就已重建完整攻擊鏈。WordPress 自身的兩份安全公告列出了相同的已修復版本，而 CISA 於7月21日將這兩個 CVE 加入其「已知遭利用漏洞」目錄。

兩個錯誤，以及失去同步的陣列

這個入口點是一項功能，而非錯誤。WordPress 5.6 於 2020 年引入批次端點，讓用戶端能在單一 HTTP 請求中送出多個虛擬 REST 請求，例如一次重新命名一組文章標題。無論呼叫者是否通過身分驗證，都能存取此端點，而每個子請求會攜帶呼叫者所提供的任何驗證資訊。直接請求 WordPress REST 路由會執行四步驟管線：檢查必要且有效的參數、淨化這些參數、執行權限回呼，然後執行端點回呼。端點依賴該管線來成立其型別假設——例如文章 ID 是整數、標題是字串。

批次 API 將管線分成兩部分，在第一個迴圈中驗證每個子請求，並在第二個迴圈中執行它們，且它保留兩個陣列，$matches 與 $validation，其項目理應按索引逐一對齊。在 class-wp-rest-server.php 中，如 Kues 所述，一個本身就是 WordPress 錯誤的子請求會被附加到 $validation，然後遇到 continue，跳過將其附加到 $matches 的那一行。從此時起，每個匹配都會向後偏移一個位置。執行迴圈會將某個索引上的子請求與該索引所記錄的驗證配對，但處理常式卻對應到不同的路由——因此參數會依照某個端點的規則檢查，然後由另一個端點的程式碼執行。

這就是讓看似普通的列表參數變成注入的原因。文章集合路由會將其公開的 author_exclude 參數映射到 author__not_in。當值是陣列時，WordPress 會對每個元素執行 absint 並排序；當值是純量時，它會被原封不動地串接進 SQL 片段，該片段會變成 NOT IN ($author__not_in)。因此像 0) OR 1=1 -- 這樣的字串就會落入查詢文字中。正常呼叫時，路由會拒絕它，因為 author_exclude 必須是整數陣列；不同步的批次呼叫才讓字串得以通過。

還有兩個障礙，而兩者都透過將這個手法層層嵌套而解決。批次 API 會拒絕 GET 請求，而注入點位於 GET 路由上；此外，請求方法的驗證本身是以參數驗證實作，而同一個失步問題可以繞過它。Kues 公布的酬載會送出一個格式錯誤的外層子請求，使方法檢查失步，接著送出一個內層批次，其第二個子請求攜帶惡意的 author_exclude針對一個不會驗證它的處理常式，然後送出執行它的 GET。以 UNION 為基礎的注入會在形似一般貼文的資料列中傳回任意資料庫值。

模型運行：一道數學提示，指向一個程式碼庫

Kues 並非從頭撰寫這個提示詞。OpenAI 曾公布它在研究循環雙覆蓋猜想時所使用的提示詞，而 Kues 寫道，他曾讀到該模型最近解出了那個猜想，且安全社群裡似乎沒有人在談論這個提示詞。他的推論是：如果它對艱深數學來說夠好，那它對安全研究大概也夠好。他改編了它，並將其對準 WordPress。

這個設定是刻意限縮的。他將最新的穩定版 WordPress 克隆到一個名為 main/的目錄中，並刪除其 .git目錄，告訴模型不要使用變更日誌、git 歷史或公開網際網路來將程式碼與已修補版本進行差異比對——他陳述的理由是，對於發現新型漏洞而言，查閱歷史或網路是浪費 token。提供了一個空的 third_party/目錄，以便模型在判斷此利用鏈需要 WordPress 底層函式庫中的漏洞時，可以克隆 PHP 或 MySQL 原始碼等相依項目。任務被指定為在 MySQL 上的一般生產環境部署中進行認證前 RCE，最多可使用四個代理，且至少六小時。Kues 寫道，他之所以明確陳述此設定要求，是因為模型否則會「作弊」——藉由選擇極不可能使用的設定選項，或捏造攻擊者永遠無法達成的前置條件。

在執行輸出中回傳的內容，是一項關於認證前 SQL 注入的聲稱。Kues 對此存疑：他寫道，WordPress 是有史以來被審查得最密集的目標之一，而且在那個十年間並未出現過有意義的認證前漏洞。他在遠端伺服器上安裝了一個原版 WordPress 執行個體，並要求模型竊取管理員的電子郵件；幾分鐘內，它就印出了他當初用來設定該執行個體的電子郵件地址。接著他問，這種唯讀注入是否能被提升權限，約四小時後，模型回答可以——提升至管理員權限，且無需破解任何密碼，也無需離線運算。

他自己的成本估算：每週用量額度的 50%，他按 200 美元訂閱費的比例折算，約為 25 美元，而這換來的是一條僅用十多個小時就產出的漏洞利用。人力部分並非免費——Kues 花了隔天一整天的時間拆解模型做了什麼，並寫道，他理解後滲透階段工作所花的時間，遠比生成這些工作所花的時間更長。他的結論異常直白，且範圍限定得很窄：「我沒有提出任何普遍性主張，但我可以完全自信地說，沒有資安研究員能在沒有 AI 的情況下，於 10 小時內發現並完成這條漏洞利用鏈。」

從唯讀 SELECT 到系統管理員

權限提升是紀錄中最關鍵的部分，因為正是在這裡，一次資料庫讀取轉變成了對伺服器的控制。Kues 的敘述把它串成六個動作，每一個動作都拿一個普通的 WordPress 功能去對付另一個功能。

首先，污染記憶體中的文章快取。WordPress 會保留一份每次請求專屬的 WP_Post 物件快取，讓同一篇文章在單一請求中被引用多次時，只需付出一次資料庫往返的成本。SQL 注入可以憑空捏造文章，因此攻擊者能精確控制哪些內容會被快取——但這些捏造的文章並不是資料庫中的資料列，而且快取會隨著請求結束而消失。

第二，將偽造的文章變成真實的資料列。 WordPress 的嵌入功能會將解析後的嵌入內容快取在資料庫中，作為類型為 oembed_cache 的文章。以相對路徑嵌入本機文章，例如 [embed]/?p=S[/embed]，會讓 WordPress 略過 HTTP 抓取，且永遠不會檢查所參照的文章是否存在，因此會建立一筆資料列。三個這類嵌入若使用不同的查詢字串權杖，會產生三個不同的快取雜湊，攻擊者就是藉此取得多筆可操作的資料列。

第三，繞過唯一保持不變的欄位。當文章在記憶體中的版本與資料庫中的版本不一致時，WordPress 會透過一個呼叫來調和它們，而該呼叫會明確地設定 post_content（即來自嵌入輸出）。文章的一切都受攻擊者控制，除了其內容；而這正是 customize_changeset 用來儲存待處理的佈景主題與網站變更 JSON 的欄位。

第四，循環機制。文章具有父文章，而 WordPress 拒絕循環：wp_insert_post_parent 篩選器會沿著樹狀結構向上遍歷，一旦發現迴圈，就呼叫更新，將 post_parent 設為零。該呼叫不會覆寫 post_content，因此記憶體中偽造的版本能在核對後存活——一個 JSON 完好無損的變更集，背後由真實的資料列支撐。

第五，借用管理員的權限。一個變更集的狀態顯示為排定在未來，但日期卻在過去時，會立即被套用。其 JSON 中的每個項目都會指名一個 user_id，而 Kues 鏈中的項目指名的則是 user_id 1，也就是管理員，因此 WordPress 會暫時採用該身分來套用這項變更。第一個變更是對 nav_menus_created_posts看似無害的更新。

第六，以該身分重播此請求。發佈文章會觸發一個動態命名的動作，{status}_{post_type}。由於文章是偽造的，該狀態與類型可以是任何值——包括 parse 與 request，這會產生 parse_request 掛鉤，並在仍持有借用的管理員身分時，從頭重新啟動請求處理管線。原始批次請求包含一個建立新管理員的子請求；它在第一輪以訪客身分失敗，並在重播時成功。接著，攻擊者以該新帳號登入，並從 ZIP 檔案上傳後門外掛，這就是程式碼執行。

這項技術附帶一個條件。Hacker News 引用 Cloudflare 報導，CVE-2026-63030 僅在未使用持久性物件快取時才會導致遠端程式碼執行；注入本身自 WordPress 6.8 起就已存在，而完整攻擊鏈則需要 6.9 或更新版本。標準安裝沒有持久性物件快取，這就是為什麼 Searchlight 的「無先決條件」措辭與 Cloudflare 的限定條件，從不同角度描述同一個預設情況。

主要文件所確立的事項

WordPress 自身的安全公告是最有力的佐證，因為這是廠商承認其中機制並發布修補。GHSA-ff9f-jf42-662q 評為嚴重（critical），描述 WordPress 6.9 及以上版本的 REST API 批次路由混淆弱點，該弱點與注入串聯即可達成程式碼執行，並歸功於 Assetnote 與 Searchlight Cyber 的 Adam Kues。GHSA-fpp7-x2x2-2mjf 評為中度（moderate），描述author__not_in 注入（存在於 WordPress 6.8 及以上版本），並指出這兩個問題已在 WordPress 7.0.2、WordPress 6.9.5、WordPress 6.8.6 與 WordPress 7.1 beta2 中修正。NVD 對這兩項 CVE 的記錄（由 WPScan CNA 而非 NIST 評分）分別為：CVE-2026-63030 為 9.8，向量為 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H；CVE-2026-60137 為 5.9，向量為 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N——第一種情況是可經網路觸及、無需任何權限的漏洞，第二種則需要高攻擊複雜度，且僅造成機密性影響。該檔案庫本身對此條目的嚴重性欄位標為 high，而 WordPress 將批次缺陷標為 critical；這兩者是分別套用於整條攻擊鏈與單一元件上的不同評分尺度，並非對漏洞本身意見分歧。

CISA 的目錄條目（如 NVD 的擴充欄位所反映）於 2026 年 7 月 21 日新增，其中 CVE-2026-63030 的修復期限為 7 月 24 日，CVE-2026-60137 則為 8 月 4 日。CISA 將第一個命名為「WordPress 核心解釋衝突漏洞」，第二個命名為「WordPress 核心 SQL 注入漏洞」。Searchlight 也在 wp2shell.com 發布了公開檢查工具，讓操作人員不必等待掃描器特徵碼即可測試執行個體。

獨立重現是由 Searchlight 本身記錄，因此是關於第三方的說法，而非第三方陳述：根據 7 月 20 日的文章，Calif 與 Hacktron 在其他概念驗證於 GitHub 出現之前，已重建完整鏈路。可獨立驗證的是效果——數日內出現的概念驗證、利用流量與廠商遙測資料，詳見下文。

什麼是被宣稱但尚未確立的？

同一個注入漏洞出現兩筆致謝，在公開紀錄中卻無法相互吻合。WordPress 針對 CVE-2026-60137 的公告指出，該瑕疵「由 TF1T、dtro 與 haongo 以團隊身分發現並負責任地揭露」。Searchlight 的說法則將同一個身分驗證前注入描述為其模型執行時所浮現的結果，且未提及該團隊；WordPress 的公告僅就批次路由混淆一事致謝 Kues，並未提及任何模型。兩份文件都未解釋這種重疊，本文所查到的任何資料也無法化解此一問題——這兩者是否為同一漏洞的獨立發現，此一可能性並未被排除；而其中一份報告是否為較晚的重新發現，也同樣未獲確立。公開紀錄並未對此作出裁斷，本文亦然。

Searchlight 7月20日那篇文章的標題數字，並未獲其自身內文支持。標題寫道「漏洞利用仲介商為一個 WordPress RCE 支付 50 萬美元。我用 GPT5.6 Sol Ultra 找到了一個，只花 25 美元」。內文以具體措辭記載了那 25 美元與那十小時；文中沒有提及任何仲介商名稱、沒有任何報價、沒有任何往來通訊，也沒有 50 萬美元這個數字的來源。針對這篇文章，並未找到任何獨立報導可佐證 wp2shell 曾有人支付或提出某個價格。請將 50 萬美元理解為標題的框架手法，而非已成定論的市場價格。

該存檔條目自身的範圍比圍繞它的報導來得窄。它記錄了披露當日的一項研究發現，未標示任何現實世界危害，且日期僅限於單一天，即2026年7月17日。這並非主張之後什麼都沒發生：通告發布後數小時內即通報有利用流量，而CISA在四天後將兩個CVE都編入目錄。該標記涵蓋的是條目所描述的內容——發現與協調披露——而後續的利用行為則由其他方依據其自身證據記錄於下文。

安全公告發布後的漏洞利用

watchTowr 首席安全研究員 Jake Knott 向 The Hacker News 表示，「截至週六凌晨（UTC），成功利用行動早已全面展開，起初是使用公開的漏洞利用程式碼來外洩雜湊憑證，隨著更多細節公開後，遠端程式碼執行也隨之而來。」同一份報告引用 KEVIntel 的遙測資料，將來自瑞士、德國、英國、印尼、立陶宛、荷蘭和新加坡的 13 個不重複 IP 位址，與 CVE-2026-63030 的利用行為串聯起來，並引述 KEVIntel 創辦人 Ryan Dewhurst 的說法，指出這些請求與公開可取得的概念驗證相符，且盲注、UNION 型和布林型 payload 都被使用。

Wiz 的研究人員 Shahar Dorfman 與 Gili Tikochinski 於 7 月 20 日發表，為此提供了規模數據：在 CVE 公布時，使用 WordPress 的組織中有 60% 至少有一個有漏洞的執行個體，25% 將有漏洞的伺服器暴露在網際網路上；隨著修補工作展開，24 小時內分別降至 50% 與 10%。他們記錄到透過管理員安裝程式上傳惡意外掛、針對 users 端點的使用者列舉、本機檔案包含嘗試鎖定 wp-config，以及管理面板存取回傳 HTTP 200——這是成功登入而非探測的跡象。他們發現的惡意程式涵蓋一個極簡的單行 PHP 後門，以及一個 150 KB、偽裝成名為 CMSmap 的合法 WordPress 安全外掛的 webshell，具備檔案管理、資料庫存取、連接埠掃描與權限提升模組。

Wiz 也記錄了一項關於能得出何種結論的限制。高流量掃描而無後續滲透利用的情況相當常見，這與機會主義式的大規模掃描以及合法的安全掃描相符；該公司表示，並未發現橫向移動或資料外洩。這是關於某一家廠商的遙測資料顯示了什麼的陳述，而非認定沒有任何東西遭到竊取。

之後有什麼改變，而什麼仍懸而未決？

對營運人員而言，應變途徑很短。更新至 WordPress 7.0.2、WordPress 6.9.5 或 WordPress 6.8.6 就是解決方案。Searchlight 的緊急替代方案，是針對無法立即更新的網站，封鎖對批次 API 的匿名存取——無論是安裝外掛，完全封鎖對 REST API 的匿名存取，或是封鎖/wp-json/batch/v1 與 ?rest_route=/batch/v1在網頁應用程式防火牆上。該公司警告，這兩者都可能影響網站的合法使用，且應視為暫時措施，直到更新推出為止。wp2shell.com 上的公開檢查工具會直接測試執行個體。CISA 的目錄條目加入了合規期限：CVE-2026-63030 須在 7 月 24 日前修復，CVE-2026-60137 須在 8 月 4 日前修復。

對於這個研究問題，尚未釐清的部分是：相對於操作者，模型實際貢獻了什麼。Kues 對這個分工說得很精確：模型大約花了十小時產出這條攻擊鏈，而他理解它所需的時間比生成它還久。他不願作出一般性論斷，只表示這項十小時的成果並非人類在無輔助下所能達成。提示詞本身並非秘密——它衍生自 OpenAI 公開過的一份提示詞，Searchlight 也在報告中重現了它的結構，包括要求忽略版本歷史，以及要求該漏洞利用必須在典型的正式環境配置中可行。這套做法能否移轉到其他程式碼庫，正是 Kues 說他並未回答的問題，而且至今沒有公布第二次執行結果。

因此，紀錄仍未確立的事項雖然範圍狹窄，卻影響重大：兩個被歸功的當事方中，究竟是誰先發現這起注入；是否有任何仲介曾支付標題所稱的金額；以及 Wiz 所觀察到的 webshell 實際上從它們所進入的網站取走了什麼（如果有的話）。關於最後一點，唯一的公開聲明來自 Wiz：其未發現任何橫向移動或資料外洩——這是從單一觀察角度所得的證據缺失，且 Wiz 正是以此形式提出。