🚨 批發申請表填一填，居然能讓陌生人直接當上你網站的老闆？WooCommerce 批發外掛雙重高危漏洞全解析（CVE-2026-27540／CVE-2026-27542）

🔥 懶人包：
專門做「批發客戶開發＋審核」的付費外掛 WooCommerce Wholesale Lead Capture（Rymera Web Co 開發，Wholesale Suite 系列產品），在 2.0.3.1 以下版本同時存在兩個 CVSS 9.8 的致命漏洞：一個是不用登入就能上傳「會自己執行的檔案」（CVE-2026-27540），另一個是不用登入就能自己勾選「我要當管理員」（CVE-2026-27542）。這兩個漏洞已經被拿去在網路上「真的打」，Wordfence 統計攔截次數超過 10 萬次。好消息是修補版本 2.0.3.2 早在 2026 年 2 月就已經釋出，壞消息是拖到現在還沒更新的站，風險等級已經不是「可能」，而是「機率正在累積」☄️

🧊 冷知識：芬蘭是資安研究員密度最高的國家之一
這兩個漏洞的發現者叫 Teemu Saarentaus，是一位芬蘭資安研究員。芬蘭這個國家人口不到 600 萬，但每年揭露的 CVE 數量長年名列全球前段班，有人猜跟他們的資工教育特別重視邏輯訓練有關。這次他一口氣挖出同一個外掛的兩個 9.8 分漏洞，等於同時拆穿了這張批發申請表的兩個破口🧋

🌐 前往官方 Changelog 確認你的外掛版本

🧐 第一章：一張「填表換批發價」的表單，怎麼會變成駭客的萬能鑰匙？

先問你一個問題：如果有間店的櫃檯，把「客人可以帶什麼東西進來」這條規則寫在一張讓客人自己填的紙上，你會不會覺得怪怪的？這次的漏洞，玩的正是這套邏輯 🧧

檔案上傳那一條，就是 CVE-2026-27540：外掛在處理上傳請求時，會去讀取一個叫 file_settings 的參數，並把裡面的內容當成「目前允許上傳的檔案類型清單」。正常情況下這份清單應該由店家（伺服器端）鎖死，但外掛卻讓客人（前端請求）自己說了算——只要在這個參數裡塞進 php，等於直接跟系統說「今天起，副檔名 .php 的檔案也算合法」，一個會被伺服器執行的程式，就這樣被光明正大地收進來了 🫢

身分判斷那一條，就是 CVE-2026-27542：外掛處理註冊請求的 wwlc_create_user 這支程式，同樣沒有把「你註冊完是什麼角色」這件事鎖死，攻擊者只要在請求裡塞進代表「管理員」身分的欄位（技術上是 wp_capabilities[administrator]），系統就會照單全收，直接生出一個貨真價實的管理員帳號，完全不用密碼、不用審核、不用等人核准 😰

🧊 冷知識：外掛裡有一個「關掉安全檢查」的隱藏開關
WordPress 內建的檔案上傳函式 wp_handle_upload 原本就有兩道內建關卡：test_form 檢查這是不是合法表單送出的請求、test_type 檢查檔案類型是否可信。很多外掛開發者為了避免自己家的自訂表單被這兩道關卡誤判成「無效」，圖方便直接把這兩個參數都設成 false，等於連同第二道防線也一起拆掉。這次的外掛正是這樣做的，結果第一道防線又被前端參數繞過，兩道鎖同時失守，才會鬧出這麼大的事 🪤

⏱️ 從被挖出來到修好，時間軸整理給你看

我們把兩份資安情報來源交叉比對，把重要節點都攤開來看看，順便告訴你哪些是雙方一致確認的事實💯

從揭露到修好，官方幾乎是當天就把新版本生出來，這速度在資安圈算是相當有誠意。但真正該讓你緊張的，其實是後半段——距離修補版本釋出已經超過半年，攻擊活動不但沒有消失，反而一波接一波往上衝，這代表還在用舊版的網站數量顯然不少，才會讓攻擊者持續有利可圖 🥟

🧑‍🔧 DevOps 小知識：兩份情報來源對 CVSS 向量的描述其實有落差
針對 CVE-2026-27540，Wordfence 給出的 CVSS 向量是 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H（Base 9.8），但 Patchstack 作為 CVE 官方登記機構（CNA），給出的是 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H（Base 9.0）——差異出在「攻擊複雜度（AC）」與「影響範圍是否跨界（Scope）」的判定不同。【❓待確認：確切以哪組向量為準，建議直接查詢 NVD 官方頁面上最新公告的向量字串】不過不管採用哪一組，兩者都落在 CVSS 9.0 以上的「嚴重」等級，這場架構性的判斷落差不影響你「該不該立刻更新」這個結論🔍

😨 講白了，這兩個漏洞加起來對我的網站到底是什麼等級的威脅？

這次比較特別的地方是——這不是「一個大洞」，而是「兩把可以互相搭配的鑰匙」。我們照確定程度一層一層拆給你看 🔍

• 🏮 ✅ 已確認事實：不用登入、不用密碼，攻擊者就能把一個會執行的程式塞進你的伺服器。攻擊者對 /wp-admin/admin-ajax.php 發送 action=wwlc_file_upload_handler 的請求，並偽造 file_settings 參數，就能讓 PHP 檔案通過檢查、被寫進伺服器。
• 🏮 ✅ 已確認事實：即使你把上傳漏洞補好，攻擊者還有第二條路能直接拿到管理員身分。透過 wwlc_create_user 這支未受保護的註冊處理程式，直接在請求裡塞進代表管理員的角色欄位，系統就會照單全收。
• 🏮 ✅ 已確認事實：這不是理論上的風險，是已經被大規模掃描與攻擊的現在進行式。Wordfence 統計 CVE-2026-27540 相關攻擊已累計攔截超過 10 萬次，光是前兩名高頻攻擊 IP（92.241.13.213 與 31.59.129.150）就合計貢獻了將近 5 萬次嘗試，代表這波攻擊背後其實是少數幾台 24 小時不停工的自動化掃描機器。
• 🏮 🟡 合理推論：兩個漏洞很可能被組合成連環攻擊。攻擊者可能先用檔案上傳漏洞取得程式執行能力，再用權限提升漏洞建立一個「看起來很正常」的管理員帳號當備用後門；也可能反過來，先拿到管理員身分，再從後台安裝更進階的惡意外掛。不管先後順序，最終結果都是網站被完全接管。
• 🏮 🔴 假設情境：如果你的主機是多站共用，風險可能不會只停在一個網站上。假如你的伺服器同時代管好幾個網站，一旦其中一站被植入後門，攻擊者理論上有機會透過檔案系統權限或共用的資料庫憑證，進一步讀取到同主機上其他網站的敏感設定，讓災情從一站擴散到整台主機。這是基於一般主機架構原理的推論，並非官方公告內容。

💡 趣味彩蛋：抓到的後門檔案裡，藏著一句「sohai」
Wordfence 公布的攻擊請求範例中，有一款被上傳的後門檔案，回應內容裡寫著 echo “sohai”; 這個字。這在馬來語裡帶有調侃、揶揄的意味，也成了資安研究員之間拿來快速辨認「這是同一波攻擊活動」的小暗號——駭客大概沒想到自己留下的一句玩笑話，反而變成了研究員的破案線索 🥟

🎭 第二章：先別自己嚇自己，看看你屬於哪一種情境

不同身分的人，接下來要做的事情差很多。你先找找自己比較接近下面哪一種吧 👇

🙋 我只是負責上架商品、處理訂單的網站小編

如果你平常的工作是上新品、回客服訊息，完全沒碰過外掛設定或程式碼，那這篇文章對你來說最重要的其實只有一件事：確認版本、按下更新。你不需要懂後面的技術深潛篇，直接跳到「五分鐘無痛自救指南」照著做就好，不會花你太多時間 💪

👨‍💻 我自己架站，或同時幫好幾個客戶管理 WooCommerce 網站

如果你手上不只一個網站，一個一個點後台更新太沒效率。這種情況適合用 WP-CLI 批次盤點所有站台的外掛版本，後面的技術深潛篇會直接給你可以貼上就用的排查指令，建議往下拉到那一段 📜

🏢 我的網站有批發客戶資料，或本身就是靠 WooCommerce 收單做生意

如果你的網站牽涉到批發客戶的公司資料、聯絡方式、營業登記檔案，甚至串接了金流跟訂單紀錄，這件事就不只是「更新一個外掛」這麼單純——它同時牽涉到客戶個資外洩的通報責任。一旦被證實資料曾經暴露，面對的往往不只是商譽受損，還有相關法規下的合規壓力。除了更新跟重置密碼之外，建議同步啟動內部的資安應變流程，把稽核紀錄留存下來，之後不管是要跟保險公司對帳，還是配合調查，都用得上 🩺

🩵 荷包試算：修一個漏洞跟收拾一個殘局，價差有多大？
這款外掛本身是付費商業外掛（Wholesale Suite 產品線），意味著你已經花了錢在用它，更新通常不會再額外收費，頂多花你幾分鐘操作時間。但如果拖到真的被植入後門，事情就不是「幾分鐘」能解決的了——請人做鑑識清查、重建乾淨環境、甚至因為客戶個資外洩而衍生的法律與商譽成本，怎麼算都比現在花五分鐘點更新貴上好幾個量級 💸

🚦 這個情境最容易被忽略：那個「辦完一次活動就沒再理過」的批發表單

🚥 畫重點：「很久沒用」不等於「沒有風險」，只要外掛還在啟用清單裡，攻擊者就有機可乘——這也是這兩個漏洞最容易被忽略的地方 🙅‍♂️

🛟 第三章：五分鐘無痛自救指南（電腦小白也能跟著做）

不管你屬於上面哪一種情境，接下來這幾步建議每個人都先跑一遍，不用懂程式，跟著畫面點就好 🤏

• ㊀ 先去確認版本，去哪裡點？
  登入你的 WordPress 後台，點左側選單的「外掛（Plugins）」，再點「已安裝外掛（Installed Plugins）」。在整串清單裡找名字叫 WooCommerce Wholesale Lead Capture 的那一項，它右側或下方會標示目前的版本號碼🔢
• ㊁ 看到版本號之後，怎麼判斷自己安不安全？
  如果版本號是 2.0.3.1 或更舊（例如 2.0.3.0、2.0.2、2.0.1 等），代表你目前正暴露在風險裡；如果已經顯示 2.0.3.2 或更新，那就可以先鬆一口氣。判斷標準就是這一組數字 ㊙️
• ㊂ 需不需要馬上更新？
  需要，而且優先程度排在今天所有代辦事項的第一位。因為這是一款付費外掛，更新按鈕的位置可能跟免費外掛不太一樣——如果你在「已安裝外掛」清單裡看不到「立即更新」的字樣，先確認外掛設定頁裡有沒有輸入「授權金鑰（License Key）」欄位，通常要先啟用授權，更新通知才會正常出現 💪
• ㊃ 如果找不到更新按鈕，或是根本不敢按怎麼辦？
  如果你擔心更新會讓批發申請表單跑掉、或是找了半天找不到授權金鑰該去哪裡拿，不需要自己硬著頭皮排除，直接把這篇報告轉傳給你的網站維護工程師、外包商，或是主機代管服務商，請他們優先處理這項更新，同時請他們順便檢查有沒有已經被入侵的跡象。找人幫忙是很正常的事，不用不好意思開口 🙇
• ㊄ 如果因為某些原因暫時真的沒辦法更新，該怎麼辦？
  既然這兩個漏洞都要靠外掛本身的功能被觸發，只要你把外掛直接點「停用（Deactivate）」，攻擊者能利用的兩條路就會同時被截斷。等未來真的需要用到批發申請功能時，再評估是否更新後重新啟用 🤔
• ㊅ 如果你在後台完全找不到這個外掛的蹤跡，或不熟悉整套流程呢？
  請立刻聯絡你的網站建置商、維護團隊或代管主機客服。跟他們溝通時，直接提供「CVE-2026-27540」與「CVE-2026-27542」這兩個編號，專業技術人員就能立刻理解問題的嚴重性並協助處置。在沒有完整備份的情況下，請不要自己貿然進入主機底層刪除任何檔案❗

🫂 新手求助：完全看不懂「授權金鑰」「AJAX端點」這些詞怎麼辦？
完全沒關係，這篇報告本來就不是要你變成資安專家。如果你連「已安裝外掛」這個選單都找不到，最快的方式就是把整篇報告網址直接轉傳給你的主機商客服或網站外包商，跟他們說「我這個批發外掛有兩個嚴重漏洞『CVE-2026-27540』跟『CVE-2026-27542』，麻煩幫我更新並檢查有沒有中招」，多數台灣主機商都有提供這類技術支援管道，這件事本來就不該是每個網站主自己一個人扛🤗

🤿 第四章：技術深潛篇：這兩條攻擊鏈的程式碼底層到底哪裡出包

接下來這段是給想知道「為什麼會這樣」的人看的——如果你只想知道怎麼補洞，上面那段其實已經夠用了。但如果你也好奇這種等級的漏洞底層長什麼樣子，我們繼續往下拆 ⚔️

🧑‍🔧 DevOps 小知識：目前已知最新版本可能不只是 2.0.3.2
兩份情報來源對「目前最新版本」的描述有出入：其中一份指出撰稿當下版本已經來到 2.0.4.1，建議直接更新到最新版而非僅僅達到 2.0.3.2 這個最低安全門檻；另一份的範例輸出則只顯示到 2.0.3.2。🟡 合理推論：不管哪個數字才是撰稿當下的絕對最新版，只要你的更新指令設定為「更新到最新版」而非寫死版本號，就不會受這個資訊落差影響。實際版本請以你外掛後台顯示的可更新版本為準 🔢

🔓 CVE-2026-27540：一個由「客人自己填」的允許清單

問題出在外掛驗證上傳檔案類型的邏輯上。它會去讀取一個叫 file_settings 的參數，把裡面 JSON 格式的內容當成「這次允許上傳的檔案類型清單」直接採信。攻擊者只要在請求裡把這個清單改成包含 php，驗證邏輯就會判定通過。更雪上加霜的是，外掛同時把 wp_handle_upload 的 test_form 與 test_type 兩個參數都設成 false，等於連 WordPress 內建的第二道 MIME 類型檢查也一併關掉。最終檔案會被寫入 wp-content/uploads/ 底下一個名稱類似 wwlc-temp-* 的暫存資料夾，攻擊者事後需要透過目錄結構猜測才能真正存取到檔案並觸發執行——不過根據已流傳的概念驗證程式碼分析，這類暴力猜測邏輯已經被寫成現成工具，門檻並不高 🔍

🔑 CVE-2026-27542：一個沒有人把關的「你想當什麼」欄位

這個漏洞出在批發客戶註冊流程的處理程式 wwlc_create_user 上。正常情況下，一個公開、不用登入就能呼叫的註冊端點，應該假設所有輸入都不可信，角色只能由伺服器端根據固定邏輯決定。但這支程式沒有對請求裡的角色欄位做任何白名單檢查，攻擊者只要在請求中夾帶代表管理員身分的能力欄位（wp_capabilities[administrator]），這筆資料就會被原封不動寫進使用者詮釋資料表，帳號建立完成的那一刻，攻擊者已經是貨真價實的網站管理員了 🦹

🎯 兩條攻擊鏈路，怎麼串成一套組合拳

• 🏮 ✅ 已確認的影響：攻擊者可上傳並執行 PHP webshell，也可直接建立管理員帳號，兩者結合等於完全接管網站，能竊取 WooCommerce 的訂單與客戶個資、植入持久化後門。
• 🏮 🟡 合理推論：由於這款外掛是付費商業外掛，公開資料顯示的安裝數約落在 6,000 站上下【❓待確認：確切安裝數僅見於單一來源，實際數字可能隨時間變動】，攻擊者更傾向使用自動化掃描而非針對性攻擊，風險集中在長期沒有更新習慣的長尾站點。
• 🏮 🔴 假設情境：若站台同時把 uploads 目錄設定成可直接對外執行 PHP（沒有做伺服器層的禁止執行設定），攻擊者上傳的檔案可能在不需要猜測暫存目錄名稱的情況下就被直接觸發，等於把暴力猜測那一關也省了。

🧑‍🔧 DevOps 小知識：這是一款「不在 wordpress.org 上」的付費外掛，代表什麼？
因為這款外掛是透過 Wholesale Suite 官網購買授權，不是從 wordpress.org 免費目錄下載，這件事會直接影響你後面做排查與修補時能用的工具：第一，wp plugin verify-checksums 這個指令依賴的是 wordpress.org 官方提供的 checksum 資料庫，對這款外掛大概率會直接回傳找不到資料，不能拿來驗證檔案是否被竄改；第二，wp plugin update 是否能真正抓到新版本，取決於外掛後台是否已經輸入有效的授權金鑰並連上原廠的 updater 伺服器，如果指令回傳「找不到套件」或版本毫無變化，代表你可能得先去後台補上授權金鑰，或乾脆從官網下載新版壓縮檔手動覆蓋 📥

🕵️‍♀️ 第五章：資安排查 Checklist：DevOps 該怎麼確認自己有沒有已經中招

🤖 重要提醒：以下指令與排查流程由 DeepSeek、Meta AI 產生，經 Claude 複查與修正
兩份原始情報中的部分批次指令存在潛在風險（例如用 for x in $(find …) 處理含空白路徑時可能斷裂、部分變數未在腳本區塊內宣告、wp user session destroy 缺少必要參數等），以下版本已重新檢查並修正這些問題。但仍可能因伺服器環境、權限設定或外掛版本差異而產生疏漏。正式環境（尤其是正在營業中的批發／電商站）的高風險操作——包含更新、停用、刪除檔案、變更權限或執行批次腳本——請務必由熟悉該站架構的專業人員進行最後確認與執行，切勿直接複製貼上後就按下 Enter 🧙

如果你是自己架 VPS、同時管理多個 WordPress，這一節最重要的不是「背一條神奇迴圈指令」，而是先搞清楚自己到底是哪一種 WordPress 架構。搞錯架構，後面的批次指令就算語法完全正確，也可能處理錯對象；因此這一節會依序走過環境判斷 👉 盤點（版本比對）→ Log 日誌排查 👉 後門檢查點 👉 加固檢查五個關卡，並且分別涵蓋單一網站、獨立多站、Multisite 三種環境 📜

🔥 一句話先記住：「版本已升級到 2.0.3.2 以上」代表你已經跨過這道漏洞的修補門檻，但不等於「網站歷史上從來沒有被摸過」。如果舊版本曾經對外公開超過一段時間（尤其考量到這波攻擊已經橫跨半年以上），版本修補與入侵排查應該視為兩件不同的工作，缺一不可 🛟

🧭 ㊀ 環境判斷：你到底是在管一個 WordPress，還是一整台 WordPress 伺服器？

決策原理：單一站、獨立多站、Multisite 三者的 WP-CLI 參數與資料範圍完全不同，必須先用官方指令確認，而不是憑印象猜 🤔

💠 單一網站：先確認 WP-CLI 真的站在 WordPress 裡

💡 新手避坑指南：關於路徑與指令替換
接下來的指令中會出現📂 /var/www/example.com/public_html 這類路徑。如果你用的是 Cloudways，路徑通常會有 public_html；如果是 cPanel，通常在 /home/你的帳號/public_html；複製貼上執行前，務必將這些變數替換成你主機的真實環境，且指令中的引號包覆（如 “$WP_PATH”）已經過嚴格測試，請勿自行刪除，避免路徑含空格導致指令斷裂喔 ⛓️‍💥

WP_PATH="/var/www/example.com/public_html"

if wp --path="$WP_PATH" core is-installed; then
    echo "OK: WordPress installation detected."
else
    echo "ERROR: WordPress installation not detected."
fi

wp --path="$WP_PATH" core is-installed --network \
    && echo "MULTISITE" \
    || echo "SINGLE-OR-STANDALONE"

grep -E "define\s*\(\s*['\"]MULTISITE['\"]" "$WP_PATH/wp-config.php" \
    || echo "wp-config.php 未定義 MULTISITE 常數"

預期輸出範例：

OK: WordPress installation detected.
SINGLE-OR-STANDALONE
wp-config.php 未定義 MULTISITE 常數

分支判斷邏輯：

• ⭕ 顯示 OK、SINGLE-OR-STANDALONE 👉 進入單一網站流程
• 🟠 顯示 ERROR 👉 先停止，確認路徑是否正確，不要把錯誤目錄當成網站處理
• 🟡 若路徑含空格或特殊字元，保留 “$WP_PATH” 的雙引號，不要自行刪除

❇️ 獨立多站：用安全的迴圈找出每一個真正的 WordPress

決策原理：「同一台伺服器有很多 WordPress」不代表 Multisite。這時應該從各站的 wp-config.php 建立 Inventory，並取得檔案實際擁有者，避免用單一 Linux 帳號跑遍所有網站造成權限錯亂⚙️

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -maxdepth 4 -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    owner="$(stat -c '%U' -- "$config")"

    if sudo -u "$owner" -- wp --path="$path" core is-installed 2>/dev/null; then
        printf 'WordPress: %s (owner: %s)\n' "$path" "$owner"
    fi
done

預期輸出範例：

WordPress: /var/www/site-a.com/public_html (owner: siteA)
WordPress: /var/www/site-b.com/public_html (owner: siteB)

分支判斷邏輯：

• ⭕ 每個路徑都能通過 👉 代表可以建立獨立多站 Inventory
• 🟠 找到 wp-config.php 卻無法載入 WordPress 👉 先確認 PHP、檔案權限或網站路徑，不要直接更新

🧑‍🔧 DevOps 小知識：這裡用 find … -print0 | while IFS= read -r -d ” 而不是 for x in $(find …)
兩份原始情報都採用了 for CFG in $(find /var/www …) 這種寫法，這在路徑名稱含有空格（例如 /var/www/My Client Site/）時會被錯誤拆成多個字串，導致指令跑錯目標甚至直接失敗。改用 -print0 搭配 IFS= read -r -d ” 是處理檔案路徑時公認比較安全的寫法，本篇後面所有批次迴圈都統一採用這個版本 🧑‍🎨

✴️ Multisite：這時才把 Network 裡的 Site 列出來

WP_PATH="/var/www/network/public_html"

if wp --path="$WP_PATH" core is-installed --network; then
    wp --path="$WP_PATH" site list \
        --fields=blog_id,url \
        --format=table
else
    echo "ERROR: 這不是一個 Multisite 安裝。"
fi

分支判斷邏輯：能列出多個 Site 👉 進入 Multisite 流程；只能列出單一網站，還要搭配 wp-config.php 裡是否存在 MULTISITE 常數一起判斷才準確 🧭

🔎 ㊁ 盤點（版本比對）：先回答「哪些站裝了這款外掛、目前到底是哪一版？」

決策原理：不寫死版本號，讓 WP-CLI 直接回報目前版本與可更新版本，比自己猜測準確得多📊

💠 單一網站

WP_PATH="/var/www/example.com/public_html"

wp --path="$WP_PATH" plugin get "woocommerce-wholesale-lead-capture" \
    --fields=name,status,version,update,update_version

預期輸出範例：

name: woocommerce-wholesale-lead-capture
status: active
version: 2.0.3.1
update: available
update_version: 2.0.3.2

分支判斷邏輯：

• 🔴 2.0.3.1 或更舊 👉 視為受影響，進入第 6 章備份／應急／修補流程
• 🟢 2.0.3.2 或更新 👉 此漏洞的版本條件已解除，但若網站曾經使用過舊版，仍應繼續往下做 Log 與後門排查
• 🟠 找不到 Plugin，或 update: none 卻版本明顯落後 👉 很可能是授權金鑰未啟用導致更新資訊沒有正常回報，請先到外掛設定頁確認授權狀態

❇️ 獨立多站：逐站查，不要把不同網站混成一份結果

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -maxdepth 4 -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    owner="$(stat -c '%U' -- "$config")"

    if ! sudo -u "$owner" -- wp --path="$path" core is-installed 2>/dev/null; then
        continue
    fi

    version="$(sudo -u "$owner" -- wp --path="$path" \
        plugin get "woocommerce-wholesale-lead-capture" \
        --field=version 2>/dev/null || true)"

    if [ -n "$version" ]; then
        printf 'Site: %s | Owner: %s | Version: %s\n' "$path" "$owner" "$version"
    fi
done

預期輸出範例：

Site: /var/www/site-a.com/public_html | Owner: siteA | Version: 2.0.3.2
Site: /var/www/site-b.com/public_html | Owner: siteB | Version: 2.0.3.1
Site: /var/www/site-c.com/public_html | Owner: siteC | Version: 2.0.2

分支判斷邏輯：這份結果就是你的第一張「風險地圖」——Site B、Site C 應優先列入第 6 章修補名單；Site A 可以繼續進行歷史排查，確認舊版暴露期間有沒有留下痕跡 🗺️

✴️ Multisite：Plugin 檔案只盤點一次，再從 Site 層確認狀態

WP_PATH="/var/www/network/public_html"

wp --path="$WP_PATH" plugin get "woocommerce-wholesale-lead-capture" \
    --fields=name,status,version,update,update_version

wp --path="$WP_PATH" plugin is-active "woocommerce-wholesale-lead-capture" --network
echo "Network activated exit code: $?"

分支判斷邏輯：Exit code 0 代表 Network Activated，處理範圍要以整個 Network 為單位；Exit code 1 則代表只在部分 Site 啟用，需再逐一確認各站啟用狀態🧭

📊 ㊂ Log 日誌排查特徵：找「動作＋時間＋結果」的組合，不是找單一神奇 IP

決策原理：這兩條攻擊鏈都會留下明確的請求特徵——CVE-2026-27540 一定涉及 wwlc_file_upload_handler，CVE-2026-27542 一定涉及 wwlc_create_user，排查 Log 時要把這兩個關鍵字跟時間、回應碼一起比對 🎯

💠 單一網站

LOG_FILE="/var/log/nginx/access.log"

if [ -f "$LOG_FILE" ]; then
    grep -E "wwlc_file_upload_handler|wwlc_create_user" "$LOG_FILE" |
    tail -n 100
else
    echo "LOG NOT FOUND: $LOG_FILE"
fi

這不是失敗，而是提醒你先找出實際的 Log 路徑。如果找到 Log，可能會看到類似：

92.241.13.213 - - [05/Jun/2026:14:22:11 +0800] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 ...
31.59.129.150 - - [06/Jun/2026:03:11:02 +0800] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 ...

分支判斷邏輯：

• 🟢 只有零星請求、沒有 200 回應 👉 目前沒有直接證據顯示已被成功利用，但仍建議繼續往下做後門檢查
• 🟡 大量來自同一 IP 的請求，且命中 Wordfence 公布的高頻 IP（92.241.13.213、31.59.129.150） 👉 提高事件優先級
• 🔴 wwlc_file_upload_handler 或 wwlc_create_user 出現 200 回應 👉 高度懷疑已被成功呼叫，進入第 6 章「A. 已中招」流程

❇️ 獨立多站：每一個站都要對應自己的 Log

LOG_ROOT="/var/log"

find "$LOG_ROOT" -type f \
    \( -name "*access*.log" -o -name "*access*.log.*" \) \
    -print0 |
while IFS= read -r -d '' log; do
    matches="$(grep -E "wwlc_file_upload_handler|wwlc_create_user" "$log" 2>/dev/null || true)"

    if [ -n "$matches" ]; then
        printf '\n===== %s =====\n' "$log"
        printf '%s\n' "$matches" | tail -n 50
    fi
done

分支判斷邏輯：某個 Log 出現命中 👉 依檔名或 VirtualHost 設定回推是哪一站，把該站標記為需要進一步鑑識；全部沒有命中 👉 風險降低，但不能證明「絕對沒被摸過」，因為 Log 可能已輪替、遺失 ♻️

✴️ Multisite：同一份 Log，從 URL／時間再回推 Site

LOG_FILE="/var/log/nginx/access.log"

if [ -f "$LOG_FILE" ]; then
    grep -E "wwlc_file_upload_handler|wwlc_create_user" "$LOG_FILE" |
    tail -n 100
fi

分支判斷邏輯：找到可疑時間點後，再使用 wp site list –field=url 取得 Network Site 清單，依 Log 中的 Host／URL 判斷哪個 Site 受到影響🔗

🚨 畫重點：Log 裡出現這兩個 action 字串並不等於「一定成功入侵」；同樣地，完全沒有找到，也不能保證「完全沒被攻擊」。Log 是證據之一，不是唯一證據 🛟

🕳️ ㊃ 後門檢查點：檔案完整性不能只看外表

決策原理：這款外掛不是 wordpress.org 免費目錄的外掛，Checksum 驗證極可能完全查不到資料，因此後門排查必須額外仰賴 uploads 目錄的異常 PHP 檔案、wwlc-temp-* 暫存目錄、資料庫留言與帳號變化，這幾項缺一不可 🕵️

💠 單一網站

WP_PATH="/var/www/example.com/public_html"
MU_PLUGINS="$WP_PATH/wp-content/mu-plugins"

if [ -d "$MU_PLUGINS" ]; then
    find "$MU_PLUGINS" -maxdepth 2 -type f -iname "*.php" -print
else
    echo "MU-PLUGINS DIRECTORY NOT FOUND: $MU_PLUGINS"
fi

echo "=== uploads 目錄異常 PHP 檔案 ==="
find "$WP_PATH/wp-content/uploads" -type f -iname "*.php" -print 2>/dev/null

echo "=== 檢查 wwlc-temp-* 暫存目錄（漏洞落點） ==="
find "$WP_PATH/wp-content/uploads" -type d -iname "wwlc-temp-*" -print 2>/dev/null

資料庫端則用 mktemp 搭配單引號 heredoc，避免 SQL 裡的萬用字元跟 Shell 自己的跳脫規則打架：

# 使用 heredoc 確保 SQL 不受引號干擾，維持邏輯閉環
WP_PATH="/var/www/example.com/public_html"
QUERY_FILE="$(mktemp)"

cat > "$QUERY_FILE" <<'EOF'
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE user_registered >= '2026-02-20'
ORDER BY user_registered DESC
LIMIT 20;
EOF

wp --path="$WP_PATH" db query < "$QUERY_FILE"

rm -f -- "$QUERY_FILE"

wp --path="$WP_PATH" user list \
    --role=administrator \
    --fields=ID,user_login,user_email,display_name,user_registered \
    --format=table

再檢查 wp_options 中有沒有藏著跟本次漏洞相關的異常資料：

WP_PATH="/var/www/example.com/public_html"
QUERY_FILE="$(mktemp)"

cat > "$QUERY_FILE" <<'EOF'
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE option_name LIKE '%wwlc%'
   OR option_value LIKE '%shell%'
ORDER BY size DESC
LIMIT 20;
EOF

wp --path="$WP_PATH" db query < "$QUERY_FILE"

rm -f -- "$QUERY_FILE"

🧑‍🔧 DevOps 小知識：為什麼 SQL 要另外存成暫存檔，而不是直接塞進雙引號字串？
LIKE ‘%wwlc%’ 這類 SQL 語法如果混在 Shell 雙引號中，很容易跟 Shell 自己的變數展開、萬用字元規則打架，用 mktemp 建一個暫存檔、搭配單引號 <<‘EOF’ heredoc，是最不容易寫錯、也最容易複查的方式，查完用 rm -f — 清掉暫存檔即可 📜

預期輸出範例：

/var/www/example.com/public_html/wp-content/uploads/wwlc-temp-a1b2c3/shell.php

分支判斷邏輯：

• 🔴 uploads 目錄出現 .php 檔案，或 wwlc-temp-* 資料夾內有可執行檔 👉 WordPress 上傳目錄本來就不應該出現 PHP 檔案，這是極度可疑的訊號，不要直接刪除，先保留檔案時間、權限、雜湊供鑑識，並進入第 6 章「A. 已中招」流程
• 🟡 管理員清單出現 2026-02-20 之後註冊、Email 看起來陌生的帳號 👉 標記該帳號，之後清理時只針對這幾筆處理，不要整批刪除所有使用者
• 🟢 找不到可疑檔案、留言與帳號也正常 👉 這一項沒有發現異常，但仍建議定期複查，因為這波攻擊持續了超過半年

❇️ 獨立多站：每站各自檢查，結果要帶上網站路徑

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -maxdepth 4 -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    owner="$(stat -c '%U' -- "$config")"
    uploads="$path/wp-content/uploads"

    hits="$(sudo -u "$owner" -- find "$uploads" -type f -iname "*.php" -print 2>/dev/null)"

    if [ -n "$hits" ]; then
        printf '\n===== SUSPICIOUS UPLOADS: %s (owner: %s) =====\n' "$path" "$owner"
        printf '%s\n' "$hits"
    fi
done

分支判斷邏輯：每個站獨立判斷，不要看到 A 站乾淨就把 B、C 站一起視為乾淨；找到命中的站優先進入事件調查，其餘站繼續走一般盤點流程 🧭

✴️ Multisite：mu-plugins 屬於 Network，各站上傳目錄要分開看

WP_PATH="/var/www/network/public_html"
MU_PLUGINS="$WP_PATH/wp-content/mu-plugins"

if [ -d "$MU_PLUGINS" ]; then
    find "$MU_PLUGINS" -maxdepth 2 -type f -iname "*.php" -print
fi

find "$WP_PATH/wp-content/uploads/sites" -type f -iname "*.php" -print 2>/dev/null

wp --path="$WP_PATH" user list \
    --fields=ID,user_login,user_email,display_name,user_registered \
    --format=table

分支判斷邏輯：發現可疑 mu-plugins 檔案 👉 把整個 Network 都納入事件調查範圍，因為 mu-plugins 是 Network 共用資源；發現未知帳號後，再進一步確認它屬於哪個 Network／Site 層級的權限 🧾

🚨 檔案完整性驗證不是完整的入侵鑑識。
尤其這款外掛不在 wordpress.org 官方目錄裡，wp plugin verify-checksums 很可能直接失效。就算網站看似正常，只要曾經暴露在受影響版本下超過一段時間，仍然必須檢查 mu-plugins、uploads、資料庫使用者與 Web Server Log，這幾項缺一不可 🔐

🔧 ㊄ 加固檢查：就算修好了，也把第二道門鎖起來

決策原理：這起事件的教訓之一，是把「檔案類型能不能上傳」跟「角色能不能自己選」這兩件高風險的事，都交給了不可信的前端輸入決定。因此加固不能只靠「更新外掛」單一動作，還要從伺服器層與帳號安全兩個角度一起收斂攻擊面 🔒

💠 單一網站：刷新 Salt、強制登出所有 Session

WP_PATH="/var/www/example.com/public_html"

wp config shuffle-salts --path="$WP_PATH"

wp --path="$WP_PATH" user list --field=ID |
xargs -I{} wp --path="$WP_PATH" user session destroy {} --all

chmod 600 "$WP_PATH/wp-config.php"

🧑‍🔧 DevOps 小知識：wp user session destroy 一定要帶使用者 ID，不能只加 –all
這個指令的官方語法是 wp user session destroy <user-id> [–all]，<user-id> 是必填參數，代表要銷毀哪個使用者的 Session，–all 才是「連同這個使用者的所有裝置都登出」的選項。如果想要一次讓全站所有使用者都被踢出，正確做法是先用 wp user list –field=ID 抓出所有使用者 ID，再搭配 xargs 逐一銷毀，就像上面這段指令一樣。單獨打 wp user session destroy –all 這種寫法會因為缺少必填的使用者 ID 而直接失敗，這也是原始情報草稿中曾經出現、後來被修正掉的一個錯誤用法 🧑‍🔧

接著檢查並收斂 PHP 層級的危險函式，這裡採用冪等替換（Idempotent Replacement），重複執行也不會出錯：

# ❶ 備份設定檔
sudo cp "/etc/php/8.4/fpm/php.ini" "/etc/php/8.4/fpm/php.ini.BAK.$(date +%F_%H%M%S)"
# ❷ 停用高風險的函式
sudo sed -i -E 's/^[;#]*\s*disable_functions\s*=.*/disable_functions = exec,passthru,shell_exec,system,proc_open,popen/' "/etc/php/8.4/fpm/php.ini"
# ❸ 改完重載 php-fpm 設定
sudo systemctl restart php8.4-fpm
# ❹ 確認有生效
php -i | grep disable_functions

說明：⚠️ 為了安全性，建議停用 exec,passthru,shell_exec,system,proc_open,popen 這些高風險函式。若因業務需求必須保留，請再三確認必要性，並搭配額外的隔離措施 🛡️

最後在伺服器層加上兩道防線：一道禁止 uploads 目錄執行 PHP、一道阻擋這兩個高風險 AJAX 動作（Nginx 範例，套用前請先在 Staging 驗證）：

location ~* "/wp-content/uploads/.*\.php$" {
    deny all;
}

location = /wp-admin/admin-ajax.php {
    if ($arg_action ~* "wwlc_file_upload_handler|wwlc_create_user") {
        return 403;
    }
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}

📂 記得替換上面的 fastcgi_pass 路徑為你主機實際的 PHP-FPM socket 位置

❇️ 獨立多站：逐站刷新，owner 動態取得

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -maxdepth 4 -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    owner="$(stat -c '%U' -- "$config")"

    printf '\n===== HARDEN: %s =====\n' "$path"

    sudo -u "$owner" -- wp config shuffle-salts --path="$path"
    sudo chmod 600 -- "$config"
done

分支判斷邏輯：每個網站獨立判斷，不要因為某站刷新失敗就跳過整批；若主機為共享主機無法修改 php.ini 👉 改用 .htaccess 或 Nginx 層阻擋作為替代方案 🛡

✴️ Multisite：Salt 只需刷新一次，但影響全網 Session

WP_PATH="/var/www/network/public_html"

wp config shuffle-salts --path="$WP_PATH"
echo "⚠️ Multisite 刷新 Salt 會讓全網使用者 Session 一次失效，請提前公告維護時間"

wp --path="$WP_PATH" user list --field=ID |
xargs -I{} wp --path="$WP_PATH" user session destroy {} --all

🧑‍🔧 DevOps 小知識：Salt 刷新為什麼能把駭客踢出去？
wp-config.php 裡的八個 AUTH_KEY、SECURE_AUTH_KEY 等常數統稱 Salt，它們不是用來加密密碼，而是為登入 Cookie 加上額外的隨機性。刷新之後，所有已簽發的登入 Cookie 立刻全部失效，等於強制所有人（包含已經潛伏在裡面的攻擊者）重新登入——這對已經偷到 Session 卻還沒設好持久後門的攻擊者特別有效 🔑

📋 ㊅ 第五章速查表：三種架構的排查地圖

🔥 核心原則：「批次」不代表「把所有東西塞進一條 Bash 迴圈」。真正安全的批次排查，是先判斷環境，再逐層縮小範圍，尤其多站 VPS 與 Multisite 必須分開處理，否則很容易把正確的 WP-CLI 指令用在錯誤的架構上 🎯

🛠️ 第六章：修不了就先擋：短期應急與正式修補三部曲

前一節解決的是「怎麼判斷」，這一節則進入真正的維運 Runbook。無論你屬於哪一種情境，強制流程都是同一套：盤點 👉 備份 👉 Dry-run 👉 更新 👉 驗證，每個階段都必須完成，才能進入下一階段，正式環境升級外掛前，務必先於測試環境備份並驗證，避免網站崩潰 🧹

🚨 ㊀ A. 已中招／疑似中招：先止血再修補

決策原理：一旦第五章排查出現明確跡象（uploads 目錄可疑 PHP、陌生管理員帳號、Log 出現 200 命中），優先目標是「切斷攻擊鏈＋保留證據＋隔離後門」，而不是立刻更新——更新只是後續步驟；最大的敵人不是漏洞本身，而是在沒有留下證據的情況下直接清理，反而把最有價值的線索一起刪掉 🛟

💠 單一網站：先隔離，再建立事件證據

WP_PATH="/var/www/example.com/public_html"

wp --path="$WP_PATH" plugin deactivate "woocommerce-wholesale-lead-capture"

PLUGIN_DIR="$WP_PATH/wp-content/plugins/woocommerce-wholesale-lead-capture"
if [ -d "$PLUGIN_DIR" ]; then
    sudo mv -- "$PLUGIN_DIR" "${PLUGIN_DIR}.disabled.$(date +%F_%H%M%S)"
fi

分支判斷邏輯：若外掛停用後批發申請表單無法送出 👉 這是預期中的正常現象，不是網站故障，因為隔離的目的正是截斷這條攻擊鏈路

WP_PATH="/var/www/example.com/public_html"
STAMP="$(date +%Y%m%d_%H%M%S)"
INCIDENT_DIR="$HOME/wwlc-incident-${STAMP}"

mkdir -p "$INCIDENT_DIR"

cat > "$INCIDENT_DIR/summary.txt" <<EOF
=== Incident collection ===
$(date -Is)
WP_PATH=$WP_PATH

$(wp --path="$WP_PATH" plugin get "woocommerce-wholesale-lead-capture" \
    --fields=name,status,version,update,update_version)
EOF

wp --path="$WP_PATH" user list \
    --role=administrator \
    --fields=ID,user_login,user_email,display_name,user_registered \
    --format=csv \
    > "$INCIDENT_DIR/administrators.csv"

find "$WP_PATH/wp-content/uploads" -type f -iname "*.php" \
    -printf '%TY-%Tm-%Td %TH:%TM:%TS %u:%g %m %p\n' \
    2>/dev/null \
    > "$INCIDENT_DIR/suspicious-uploads.txt"

wp --path="$WP_PATH" db export "$INCIDENT_DIR/db_snapshot_${STAMP}.sql" \
    --add-drop-table --single-transaction

echo "Incident evidence: $INCIDENT_DIR"

預期輸出範例：

Incident evidence: /home/admin/wwlc-incident-20260916_121500

接著止血：隔離可疑檔案（先隔離不刪除）、刷新 Salt、逐一重設管理員密碼（不要一次全部重設以免鎖死自己）、銷毀所有 Session：

WP_PATH="/var/www/example.com/public_html"
QUARANTINE_DIR="$HOME/wwlc-quarantine-$(date +%Y%m%d_%H%M%S)"

mkdir -p "$QUARANTINE_DIR"

find "$WP_PATH/wp-content/uploads" -type f -iname "*.php" -print0 |
while IFS= read -r -d '' f; do
    printf 'Quarantine candidate: %s\n' "$f"
    chmod 000 -- "$f"
    mv -- "$f" "$QUARANTINE_DIR/"
done

wp config shuffle-salts --path="$WP_PATH"

wp --path="$WP_PATH" user list --role=administrator --field=ID |
while IFS= read -r uid; do
    printf 'Resetting password for user ID: %s\n' "$uid"
    wp --path="$WP_PATH" user update "$uid" --user_pass="$(openssl rand -base64 24)"
done

wp --path="$WP_PATH" user list --field=ID |
xargs -I{} wp --path="$WP_PATH" user session destroy {} --all

分支判斷邏輯：隔離與重置動作全部成功 👉 進入清除資料庫殘留內容與正式修補流程；任一步驟失敗（例如檔案權限不足） 👉 先解決權限問題，不要略過這一步直接升級外掛版本，否則同一個入侵路徑可能再次被利用 🔁

❇️ 獨立多站：只隔離有證據的站，避免整台 VPS 一起誤傷

INCIDENT_PATH="/var/www/site-b/public_html"
INCIDENT_OWNER="$(stat -c '%U' -- "$INCIDENT_PATH/wp-config.php")"

if sudo -u "$INCIDENT_OWNER" -- wp --path="$INCIDENT_PATH" core is-installed; then
    echo "Incident target confirmed: $INCIDENT_PATH (owner: $INCIDENT_OWNER)"
else
    echo "ERROR: target is not a WordPress installation."
fi

分支判斷邏輯：確認路徑與擁有者正確 👉 對這一站套用單一網站流程中的證據保存與隔離指令；不要把整個 /var/www 當成單一網站處理，也不要因為同一台 VPS 其他站看起來正常，就跳過對它們的第五章排查 🧭

✴️ Multisite：先把事件視為 Network 級問題

WP_PATH="/var/www/network/public_html"

wp --path="$WP_PATH" plugin deactivate "woocommerce-wholesale-lead-capture" --network

wp --path="$WP_PATH" site list --fields=blog_id,url --format=table

find "$WP_PATH/wp-content/uploads/sites" -type f -iname "*.php" -print 2>/dev/null

分支判斷邏輯：任一 Site 出現明確入侵跡象 👉 對整個 Network 執行證據保存、Salt 刷新；接著再逐一檢查各 Site 的管理員帳號是否有異常🔍

🧯 ㊁ B. 短期應急：尚未確認中招，但現在還不能立刻升級

🚨 短期應急 ≠ 正式修補。
停用外掛、伺服器層防護規則都屬於緩衝措施，目標是縮短攻擊面暴露時間，真正的修補仍然是安裝 2.0.3.2 或更新版本 🧱

💠 單一網站

WP_PATH="/var/www/example.com/public_html"

wp --path="$WP_PATH" plugin deactivate "woocommerce-wholesale-lead-capture"
echo "已暫時停用，批發申請表單功能會暫時無法使用，待排程更新後再重新啟用"

若批發申請功能是營收關鍵、無法直接停用，改採伺服器層阻擋（套用前請先在 Staging 驗證，且僅在確認該站使用此外掛時套用）：

location = /wp-admin/admin-ajax.php {
    if ($arg_action ~* "wwlc_file_upload_handler|wwlc_create_user") {
        return 403;
    }
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}

Apache 版本可用 .htaccess 達成類似效果：

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-admin/admin-ajax\.php$
RewriteCond %{QUERY_STRING} action=(wwlc_file_upload_handler|wwlc_create_user)
RewriteRule .* - [F,L]

❇️ 獨立多站：逐站應急，不要一次停掉整台 VPS 的所有站

INCIDENT_PATH="/var/www/site-b/public_html"
INCIDENT_OWNER="$(stat -c '%U' -- "$INCIDENT_PATH/wp-config.php")"

sudo -u "$INCIDENT_OWNER" -- wp --path="$INCIDENT_PATH" plugin deactivate "woocommerce-wholesale-lead-capture"

分支判斷邏輯：這個指令只影響 Site B，不應連 Site A、Site C 一起停掉；若要批次處理多個高風險站，建議先跑第五章的盤點迴圈，把版本落後的站篩出清單，再針對清單逐一停用 📋

✴️ Multisite：先確認是否 Network Activated，再決定停用範圍

WP_PATH="/var/www/network/public_html"

if wp --path="$WP_PATH" plugin is-active "woocommerce-wholesale-lead-capture" --network; then
    echo "Plugin is Network Activated."
    wp --path="$WP_PATH" plugin deactivate "woocommerce-wholesale-lead-capture" --network
else
    echo "Plugin is not Network Activated."
fi

✅ 為什麼停用就能擋？
這兩條攻擊鏈都完全依賴外掛自己的 AJAX 端點才會被觸發，停用外掛能百分之百截斷這兩條路，是目前最乾淨、風險最低的短期緩解手段，但不能取代正式升級 🏎️

㊂ C. 正式修補：強制流程「判斷環境 👉 盤點 👉 備份 👉 Dry-run 👉 更新 👉 驗證」

🩵 荷包試算：這幾道防線要花多少錢？
伺服器層設定與停用外掛本質上都是免費操作，只要有 SSH 權限就能自己動手。真正會花到錢的地方，通常是「已經中招之後」——請資安顧問做鑑識、清除後門的工時，或是客戶批發資料外洩後的商譽與法律成本，這筆帳，怎麼算都是現在就花時間走完這套 Runbook 比較划算 💸

① 判斷環境（再次確認）

回到第五章「㊀ 環境判斷」執行判斷，確認自己屬於哪一種架構後再繼續，不要在還沒確認架構前就執行下面任何批次指令 🙅

② 盤點（Inventory）

沿用第五章「㊁ 盤點（版本比對）」的三段指令，先確認哪些站真正安裝了受影響版本，把結果列成清單，不要在第一個迴圈裡直接更新 🔎

③ 備份（Backup）

決策原理：外掛更新主要改的是 Plugin 檔案，但批發申請資料、設定值與媒體檔案仍可能需要回復，因此至少要有資料庫備份，並依既有維運政策保留必要檔案，備份檔案統一集中放在 ~/wp-security-backup 💾

💠 單一網站：

WP_PATH="/var/www/example.com/public_html"
BACKUP_DIR="$HOME/wp-security-backup"
STAMP="$(date +%Y%m%d_%H%M%S)"

mkdir -p "$BACKUP_DIR"

wp --path="$WP_PATH" db export \
    "$BACKUP_DIR/example-com_pre_wwlc_update_${STAMP}.sql"

tar -czf \
    "$BACKUP_DIR/example-com_wp-content_pre_wwlc_update_${STAMP}.tar.gz" \
    -C "$WP_PATH" \
    "wp-content"

printf 'Backup completed:\n%s\n' "$BACKUP_DIR"

❇️ 獨立多站：每一個 WordPress 各自一份資料庫備份

SEARCH_ROOT="/var/www"
BACKUP_ROOT="$HOME/wp-security-backup"
STAMP="$(date +%Y%m%d_%H%M%S)"

mkdir -p "$BACKUP_ROOT"

find "$SEARCH_ROOT" -maxdepth 4 -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    owner="$(stat -c '%U' -- "$config")"
    site_name="$(basename -- "$path")"
    db_file="$BACKUP_ROOT/${site_name}_pre_wwlc_update_${STAMP}.sql"

    if ! sudo -u "$owner" -- wp --path="$path" core is-installed 2>/dev/null; then
        continue
    fi

    echo "=== Backup: $path ==="

    sudo -u "$owner" -- wp --path="$path" db export "$db_file"

    tar -czf "$BACKUP_ROOT/${site_name}_wp-content_pre_wwlc_update_${STAMP}.tar.gz" \
        -C "$path" "wp-content"

    sleep 2
done

分支判斷邏輯：某一站備份失敗，就把該站標記為未完成，不要因為其他站成功就直接進入批次更新 ⛔

✴️ Multisite：Network Database 不要重複 dump N 次

WP_PATH="/var/www/network/public_html"
BACKUP_DIR="$HOME/wp-security-backup"
STAMP="$(date +%Y%m%d_%H%M%S)"

mkdir -p "$BACKUP_DIR"

wp --path="$WP_PATH" db export \
    "$BACKUP_DIR/network_pre_wwlc_update_${STAMP}.sql"

tar -czf \
    "$BACKUP_DIR/network_wp-content_pre_wwlc_update_${STAMP}.tar.gz" \
    -C "$WP_PATH" \
    "wp-content"

🚨 不要在 Multisite 的每個 URL 上重複執行整個 wp db export。
這很可能只是把同一個 Network Database 重複 dump 多次，既浪費空間，也沒有增加實質備份價值。對 Network 執行時預設匯出的就是整個 installation 使用的資料庫 🗄️

④ Dry-run（正式修改前先預覽）

💠 單一網站／✴️ Multisite：

WP_PATH="/var/www/example.com/public_html"

wp --path="$WP_PATH" plugin update \
    "woocommerce-wholesale-lead-capture" \
    --dry-run

預期輸出範例：

Plugin woocommerce-wholesale-lead-capture 2.0.3.1 will be updated to 2.0.3.2.

分支判斷邏輯：看到目標版本 👉 可以正式更新；顯示沒有可用更新，但版本明顯落後 👉 很可能是授權金鑰未生效，先回外掛設定頁確認，不要因為「No updates」就直接認定網站安全 🔮

❇️ 獨立多站：每站各自 Dry-run

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -maxdepth 4 -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    owner="$(stat -c '%U' -- "$config")"

    if ! sudo -u "$owner" -- wp --path="$path" core is-installed 2>/dev/null; then
        continue
    fi

    version="$(sudo -u "$owner" -- wp --path="$path" \
        plugin get "woocommerce-wholesale-lead-capture" \
        --field=version 2>/dev/null || true)"

    if [ -n "$version" ]; then
        printf '\n===== %s | current=%s =====\n' "$path" "$version"

        sudo -u "$owner" -- wp --path="$path" plugin update \
            "woocommerce-wholesale-lead-capture" \
            --dry-run
    fi
done

⑤ 更新（確認備份與 Dry-run 都 OK 後才真正修改）

💠 單一網站：

WP_PATH="/var/www/example.com/public_html"

wp --path="$WP_PATH" plugin deactivate "woocommerce-wholesale-lead-capture"
wp --path="$WP_PATH" plugin update "woocommerce-wholesale-lead-capture"
wp --path="$WP_PATH" plugin activate "woocommerce-wholesale-lead-capture"

正確做法 vs 危險做法對比（多站環境）：

✅ 正確做法（逐站處理）：
  for each site:
    備份 👉 Dry-run 👉 deactivate 👉 update 👉 activate 👉 驗證
    sleep 3  # 緩衝資源
    下一站

❌ 危險做法（一次跑完所有站）：
  for each site:
    update --all  # 不備份、不驗證、不緩衝
    所有站同時更新，若一站崩潰無法回溯，且可能因資源競爭導致資料庫鎖定

❇️ 獨立多站：一站一個完整閉環

WP_PATH="/var/www/site-a/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"

sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin deactivate "woocommerce-wholesale-lead-capture"
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin update "woocommerce-wholesale-lead-capture"
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin activate "woocommerce-wholesale-lead-capture"

sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin get "woocommerce-wholesale-lead-capture" \
    --fields=name,status,version,update,update_version

🧑‍🔧 多站環境的實務原則：一次只處理一個網站，至少在第一批部署時如此。先完成一站的「備份 👉 更新 👉 驗證」，確認沒有 PHP Fatal Error、白畫面、批發申請表單無法載入等問題，再繼續下一站，這比一個巨大 Bash 迴圈從頭跑到尾更容易控制風險 🎛️

✴️ Multisite：Plugin 檔案只更新一次，再逐 Site 驗證

WP_PATH="/var/www/network/public_html"

wp --path="$WP_PATH" plugin update "woocommerce-wholesale-lead-capture"
wp --path="$WP_PATH" plugin activate "woocommerce-wholesale-lead-capture" --network

wp --path="$WP_PATH" plugin get "woocommerce-wholesale-lead-capture" \
    --fields=name,status,version,update,update_version

分支判斷邏輯：若更新後網站出現白屏 👉 立即重新啟用舊版備份（wp plugin install woocommerce-wholesale-lead-capture –version=2.0.3.1 –force），並排查衝突；若更新指令回報找不到套件 👉 回到前面提過的授權金鑰問題，先確認外掛設定頁的授權狀態是否已啟用 🔍

⑥ 驗證（更新成功 ≠ 工作完成）

WP_PATH="/var/www/example.com/public_html"

echo "=== ① 版本驗證 ==="
wp --path="$WP_PATH" plugin get "woocommerce-wholesale-lead-capture" \
    --fields=name,status,version,update,update_version

echo "=== ② Checksum 驗證（僅供參考） ==="
wp --path="$WP_PATH" core verify-checksums
wp --path="$WP_PATH" plugin verify-checksums "woocommerce-wholesale-lead-capture" \
    || echo "此為付費外掛，wordpress.org 官方通常無此外掛的 checksum 資料，改用檔案時間與大小人工比對"

echo "=== ③ 前後台功能驗證 ==="
wp --path="$WP_PATH" plugin list --status=active --format=table | \
    grep "woocommerce-wholesale-lead-capture"

echo "=== ④ AJAX 端點回應驗證 ==="
curl -s -o /dev/null -w "%{http_code}\n" \
    "https://example.com/wp-admin/admin-ajax.php?action=wwlc_file_upload_handler"

預期輸出範例：

• 版本驗證應顯示 2.0.3.2 或更新。
• core verify-checksums 應顯示 Success: WordPress installation verifies against checksums.
• 外掛 Checksum 驗證很可能直接顯示查無資料，這是正常現象，不代表外掛有問題，因為它不是 wordpress.org 目錄裡的外掛。
• AJAX 端點測試理論上應回傳 400 或 403（若外掛已修補，該 action 的驗證邏輯應已收緊）。

Checksum 驗證的侷限：Checksum 能證明檔案的內容與官方發布的版本一致，但不能證明整站沒有後門。如果攻擊者在 wp-content/uploads 中植入了 webshell，Checksum 驗證不會偵測到，也無法偵測資料庫中的異常資料。因此 Checksum 驗證必須與第五章的後門檢查點配合使用。

分支判斷邏輯：若版本驗證通過但 AJAX 端點仍回傳 200 👉 表示更新未生效或外掛快取未清除，需執行 wp cache flush 並確認 OPcache 已重啟。

⚠️ 安全提醒：在正式環境（Production）升級外掛前，務必先於測試環境（Staging）備份並驗證，避免網站崩潰。多站環境建議先挑一台 Staging 驗證後再批次推送 🐲

🤔 讀到快喘不過氣？常見焦慮 QA 大解密

看到這邊，如果是行銷小編或老闆，可能已經覺得頭昏眼花了。別緊張，我們整理了幾個大家最常問的焦慮點，幫你壓壓驚：

• 🏮 Q：按了更新，批發申請表單會不會跑掉？
  A：外掛更新通常不會影響前台版型，但保險起見，動手前先截圖目前批發申請頁的正常樣子，方便更新後比對，並且先在測試站驗證絕對是不變的真理喔 💾
• 🏮 Q：外包廠商說「這功能我們又沒在用，不用管它」，我該聽他的嗎？
  A：千萬別信這句話！漏洞最狡猾的地方在於「只要外掛還啟用著」，就算你沒在用它收批發客戶資料，駭客一樣能把後門塞進去。請堅定地要求廠商協助升級 💣
• 🏮 Q：我完全看不懂上面那些指令，是不是就沒救了？
  A：完全不會。前面「五分鐘無痛自救指南」那一段從頭到尾不需要碰任何指令，只要在後台點幾下滑鼠就能完成最基本的防護，技術深潛篇是給有 SSH 權限、想深入排查的人看的補充內容 🤗

🏆 第七章：事件綜合評估（10 分制，數字越高代表風險或應對品質越正向）

🔥 這起事件給了所有經營批發生意的網站主一個提醒：越是「幫你把麻煩事簡化」的外掛，越有可能把不該交給客人決定的事，悄悄交給了客人。批發申請表單本身沒有錯，錯的是把「檔案類型允不允許」跟「身分是什麼」這兩件事的決定權，放到了前端請求裡。與其等哪天客戶抱怨個資外洩才發現不對勁，不如現在就花五分鐘，打開後台看一眼版本號碼 🔢

📚 參考資料與延伸資源

• 📌 NVD｜CVE-2026-27540 官方詳情頁
• 📌 NVD｜CVE-2026-27542 官方詳情頁
• 📌 CVE.org｜CVE-2026-27540 紀錄
• 📌 CVE.org｜CVE-2026-27542 紀錄
• 📌 Wordfence｜Attackers Actively Exploiting Critical Vulnerability 部落格公告
• 📌 Wordfence Threat Intelligence｜Unauthenticated Arbitrary File Upload
• 📌 Wordfence Threat Intelligence｜Unauthenticated Privilege Escalation
• 📌 Patchstack｜Arbitrary File Upload 漏洞資料庫紀錄
• 📌 Patchstack｜Privilege Escalation 漏洞資料庫紀錄
• 📌 BleepingComputer｜Hackers target WordPress sites via third-party WooCommerce plugin
• 📌 GitHub｜im-hanzou 雙 CVE 技術細節分析
• 📌 Undercode News｜Critical WooCommerce Vulnerability Is Under Active Attack
• 📌 WPScan｜WooCommerce Wholesale Lead Capture 漏洞紀錄
• 📌 Wholesale Suite｜官方 Changelog