💣 學生帳號按下「儲存」，主機就中風了？Tutor LMS 提款漏洞全解密（CVE-2026-78175／CVSS 8.8）

🔥 懶人包：
全球超過 10 萬 個網站在用的線上課程外掛 Tutor LMS – eLearning and online course solution，被抓到一個「填一張提款表單，就能讓伺服器幫你開後門」的物件注入漏洞（CVE-2026-78175，CVSS 8.8 高風險）。最讓人捏一把冷汗的地方，不是攻擊手法多花俏，而是門檻低到誇張——只要是剛註冊的學生帳號就摸得到，而且如果你的網站又剛好開放任何人註冊，等於連這道最低門檻都省了。目前官方已在 4.0.7 以下 版本修補完畢，強烈建議立刻升級到 4.0.8 以上 ☄️

🧊 冷知識：抓到這個洞的研究員，五年前就抓過同一款外掛一次
這次通報 CVE-2026-78175 的 Wordfence 研究員 Chloe Chamberland，其實在 2021 年 3 月也親手揪出過 Tutor LMS 的另一個越權漏洞（CVE-2021-24184）——當時同樣是因為後端 AJAX 端點沒把權限檢查做好，讓當時已安裝在超過 2 萬個網站上的外掛，被學生帳號摸到就能亂改課程資料。五年過去，同一位研究員、同一款外掛，只是這次的破口換成了更深層的序列化角落，有點像老朋友又來抓漏了 👀

🌐 前往 WordPress 官方外掛頁面確認版本

🧐 一張提款表單，怎麼會變成駭客的遙控炸彈？

先問你一個問題：如果補習班的提款申請櫃檯，警衛只檢查你手上有沒有排隊號碼牌，卻完全不看你是不是真的有教師證，你猜會發生什麼事？聽起來很扯，但 Tutor LMS 這次出包的地方，剛好就是這麼一回事 🦹

光是「學生能碰到老師的表單」還不至於直接讓伺服器淪陷，真正致命的地方，出在系統把這張表單「打包收進保險箱」的方式出了差錯。這個把資料打包成一長串文字存進資料庫的動作，技術上叫做序列化（Serialize）；反過來把它拆開還原的動作，則叫反序列化（Unserialize）。而 WordPress 核心裡有一個叫 esc_sql() 的工具，本來是用來防止 SQL 查詢被 % 符號搞亂的安全機制——它會把資料裡每一個 %，暫時放大成一串長達 66 個位元組的驗證碼再存進去 📃

🧊 冷知識：這串 66 位元組的保護機制，其實是十年前留下的老功臣
把 % 符號暫時膨脹成一長串 HMAC 驗證碼再存回資料庫，這個設計最早可以追溯到 2017 年的 WordPress 4.8.3 更新，當初核心團隊是為了堵住 LIKE 查詢容易被誤判的問題，才加上這道「先變胖再瘦身」的防護機制。問題是，這道原本用來防禦 SQL 注入的盾牌，遇上外掛開發者不小心把呼叫順序搞反，反而變成了撬開反序列化大門的槓桿——防身術用錯地方，反而傷到自己人 🛡️

問題就出在這裡：Tutor LMS 把使用者填的提款資料，先送進 esc_sql() 膨脹處理，然後才透過 update_user_meta() 序列化存檔。等到系統之後要把資料「拿出來還原」時，那串 66 位元組的驗證碼會被還原回原本那一個 % 符號，長度瞬間縮水了 65 位元組。這就好像行李箱外面貼的標籤寫著「內容物 66 公分」，但實際打開一看，裡面只塞了 1 公分的東西——系統照著標籤的長度往下讀，會一路讀到隔壁被人動過手腳的資料，把攻擊者精心埋好的物件也一併讀了進來，最後被拿去執行了不該執行的動作 📦

白話一句總結：這是一個「填一張表單，就有機會讓陌生人在你主機上跑程式」的破口，而且門檻低到只要是登入狀態的學生帳號就摸得到，完全不需要碰到管理員後台的任何一顆按鈕 🚪

⏱️ 從被抓包到補完洞，時間軸攤開來給你看

這次的通報流程走得算蠻快的，我們把幾個關鍵時間點整理成表格，方便你一眼看懂發生了什麼事：

細看這條時間軸會發現一個很有意思的細節：官方其實早在公開揭露的前一天就把補丁做好塞進版本更新裡，只是更新日誌寫得雲淡風輕，完全沒提到這是在補一個 CVSS 8.8 的高風險洞。這種「先默默補洞、事後才公開說明」的節奏，在資安圈其實不算少見，畢竟廠商也不想在補丁還沒普及前，就先幫攻擊者畫好靶心 🎯

✅ 已確認的事實是：截至報告撰寫時，公開情資中尚未看到大規模自動化攻擊的通報紀錄。🟡 但合理推論是：由於漏洞的技術細節與程式碼層面的成因已經被完整公開分析，任何懂一點 PHP 反序列化的人，理論上都能照著邏輯自己拼湊出攻擊腳本，這種「教材已公開、只等有心人動手」的狀態，通常撐不了太久 🔍

😨 講白了，這串攻擊到底能對我的網站幹嘛？

跟大部分「一定要偷到管理員密碼才會出事」的直覺不同，這次的威脅模型完全不吃這一套。我們照事實的確定程度，一層一層拆給你看：

• 🏮 ✅ 已確認事實：學生帳號就能觸發，不需要碰後台。攻擊者只要能用一個訂閱者（Subscriber）等級以上的帳號登入，就能直接呼叫這個提款儲存端點，完全不需要偷到教師或管理員的權限。
• 🏮 ✅ 已確認事實：如果網站開放任何人註冊，連「登入」這道門檻都形同虛設。官方漏洞說明特別點名，只要你的網站有開放學員或講師自由註冊——這在補習班網站上根本是標配——攻擊者花三十秒申請一個帳號，就等於拿到了鑰匙。
• 🏮 🟡 合理推論：一旦觸發成功，攻擊者能在你的主機上寫入任意檔案。技術分析指出，這條攻擊鏈最後會借用外掛內建的第三方套件元件，把攻擊者控制的內容寫進攻擊者指定的檔案路徑，等於在你的網站裡埋了一個後門檔案。
• 🏮 🔴 假設情境：如果主機沒有做好基本隔離，後果可能不只一個網站遭殃。最壞的狀況是攻擊者透過後門拿到伺服器的執行權限，不只能竄改課程頁面、竊取學員個資與交易紀錄，如果你的主機還跟其他網站共用同一台伺服器，甚至可能被拿來當跳板，橫向影響到隔壁網站。

💡 碎碎念：這條攻擊鏈用到的那把「萬能鑰匙」，其實是別人家的工具
攻擊鏈最後用來寫檔的關鍵元件，是知名 HTTP 工具套件 Guzzle 裡的 GuzzleHttp\Cookie\FileCookieJar 類別，原本的設計初衷單純是幫命令列腳本把 Cookie 存到硬碟，避免程式重啟就要重新登入。但因為它在「被銷毀」的那一刻會自動觸發寫檔動作，而寫入的內容跟路徑又剛好可以被外部操控，這幾年下來已經變成 PHP 資安圈裡橫跨好幾個知名框架與外掛的經典「借刀殺人」工具，這次只是它又被借用了一次而已 🔪

🎭 先別慌，看看你比較接近哪一種情境

看到這裡如果已經開始緊張也不用太自責，畢竟不同身分的人，該做的事情真的差很多。我們把常見的四種情境攤開來，你先對照看看自己比較像哪一種 🧭

🙋 我只是兼職小編，平常只負責發文跟回覆學生

如果你平常的工作是上架課程、回覆學員問題、處理退費，完全不碰後台深層設定，那你要做的事情其實很單純：找到版本號、按下更新、必要時先把外掛關掉爭取時間。你不需要理解後面 DevOps 那段技術深潛，直接跳到下面「五分鐘無痛自救指南」照著做就好，不會花你太多時間 💪 升級外掛本身完全免費，唯一要注意的是如果你有付費使用 Tutor LMS Pro，記得確認授權序號還在有效期內，不然升級可能會卡住 💵

👨‍💻 我自己架站，手上還管著好幾個客戶的 WordPress

如果你身兼數職，同時顧著好幾個補習班或個人教學網站，光靠手動一個一個點後台更新太沒效率。這種情況下，用 WP-CLI 批次盤點所有站台的外掛版本會實際很多，後面的技術深潛篇會直接給你可以貼上就用的排查指令，建議拉到那一段 👇

🏢 我的網站有在收學費、發證書，或是有講師分潤機制

如果你的網站牽涉到學員繳費、講師抽成、發放結業證書，這件事就不只是「更新一個外掛」這麼簡單了——它同時牽涉到個資外洩的通報責任。一旦被證實學員或講師的資料曾經暴露，機構面對的往往不只是招生信任度受損，還有主管機關的裁罰風險。除了更新跟重置密碼之外，建議同步啟動內部的資安應變流程，把稽核紀錄留存下來，之後不管是要跟保險公司對帳、還是配合調查，都用得上 🩺

🧑‍🔧 DevOps 小知識：為什麼「只停用外掛」有時候還不夠？
單純停用外掛能百分之百切斷這次「提款端點觸發」的攻擊鏈路，這點沒問題。但如果你懷疑自己已經中招，光停用是不夠的——因為攻擊者留下的後門檔案跟外掛本身無關，就算你把外掛整個移除，後門依然會繼續運作。停用只能防止「新的入侵」，已經進門的東西，還是得靠後面 Checklist 章節的排查手段才清得掉 🛡️

🚨 這種情境最容易被忽略：開放註冊＋開了提領功能，卻沒人記得關

🚥 劃重點：「開放註冊」跟「開啟提款」這兩個功能分開看都很正常，湊在一起卻剛好是這次漏洞最容易被摸到的組合——這也是最容易被忽略的地方 🙅‍♂️

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

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

• ㊀ 先去哪裡看目前版本？
  登入你的 WordPress 後台，點左側選單的「外掛（Plugins）」，再點「已安裝外掛（Installed Plugins）」。在整串清單裡找名字叫 Tutor LMS – eLearning and online course solution 的那一項，它右側或下方會標示目前的版本號碼 🔢
• ㊁ 看到版本號之後，怎麼判斷自己安不安全？
  如果版本號是 4.0.7 或更舊（例如 4.0.5、3.9.x 等），代表你目前正暴露在風險裡；如果已經顯示 4.0.8 或更新，就可以先鬆一口氣。判斷標準就是這一個數字 ㊙️
• ㊂ 需不需要馬上更新？
  需要，而且優先程度排在今天所有代辦事項的第一位。直接在同一個畫面點「立即更新（Update Now）」按鈕，等它跑完，重新整理頁面確認版本號已經變成 4.0.8 以上即可 💪 若是使用 Tutor LMS Pro 付費版本，建議同時登入 Themeum 官方會員後台，確認付費套件版本也已經對齊。
• ㊃ 如果按了更新按鈕卻沒反應，或是不敢按怎麼辦？
  如果你擔心更新會讓課程頁面跑掉、或是按了半天沒動靜，不需要自己硬著頭皮排除，直接把這篇報告轉傳給你的網站維護工程師、外包商，或是主機代管服務商，請他們優先處理這項更新，同時請他們順便檢查有沒有已經被入侵的跡象。找人幫忙是很正常的事，不用不好意思開口 🙇
• ㊄ 如果暫時真的沒辦法更新，該怎麼辦？
  既然這個漏洞得靠「開放註冊」加上「提款功能被觸發」才會被引爆，你可以先進入後台「設定」選單的「一般（General）」分頁，把「任何人皆可註冊」的勾選取消掉，關閉新使用者的註冊入口。如果你的網站本來就不需要處理講師提款，也可以進入 Tutor LMS 的設定選單，把提款相關功能先暫時關閉，這樣就能大幅降低被摸到的機會，爭取一點修補的時間 🤔

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

🤿 工程師來看：這串攻擊的程式碼底層到底哪裡壞了

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

🧑‍🔧 DevOps 小知識：CVSS 向量裡的 PR:L 有點會誤導人
官方把這條漏洞的「所需權限」標示為 PR:L（低權限），這代表攻擊者確實需要一個訂閱者等級以上的帳號才能觸發。但別忘了漏洞說明裡特別點名：只要網站開放公開註冊，這道「登入」門檻等於形同虛設，任何路人都能自己申請一個帳號滿足這個條件。所以從防禦者的角度來看，只要你的網站有開放註冊，就應該把邊界防護當成「完全未授權攻擊」在防，不能因為向量上寫著 PR:L 就掉以輕心 ⚙️

問題出在外掛檔案 classes/Withdraw.php 裡負責處理提款帳號儲存的 AJAX 動作常式 tutor_save_withdraw_account。這段程式接到前端送來的儲存請求時，只透過 check_ajax_referer() 檢驗 Nonce 是否有效，卻完全沒有呼叫 current_user_can() 來檢查對方是不是講師或管理員身分——這正是前面比喻裡「只看號碼牌、不核對身分」的技術版說法 🔢

更麻煩的是後半段的資料處理邏輯。當這段程式處理參數 withdraw_method_field 時，會先把整包 POST 資料丟進 WordPress 核心的 esc_sql() 進行跳脫轉義。這個函式底層會呼叫 wpdb::placeholder_escape()，把輸入字串裡每一個 % 替換成一段 66 位元組長的隨機 HMAC 佔位標記。接著外掛透過 update_user_meta() 儲存這筆資料，而這個函式底層又會呼叫 maybe_serialize()，導致包含 66 位元組佔位標記的字串，被錯誤計算並標記了偏大的序列化長度。等到資料庫日後查詢還原這筆中繼資料時，HMAC 標記被還原為原始的單一 % 符號，讓實際字串比宣告長度整整少了 65 位元組。配合 POST 欄位鍵名完全沒有經過過濾的特性，攻擊者就能精準構造出這段長度落差，讓自訂的序列化物件逃逸出原本的資料邊界，被硬生生塞進反序列化的資料流裡 🔠

🎯 從埋雷到奪權，攻擊者只走了三步

整條攻擊鏈揉合了免驗證輸入、資料庫序列化落差跟自動載入機制濫用，拆開來看邏輯其實相當工整 🕵️‍♀️

• 🏮 第一步：用低權限帳號打進提款端點。攻擊者以訂閱者等級以上的帳號登入，向 /wp-admin/admin-ajax.php 發送 HTTP POST 請求，指定 action=tutor_save_withdraw_account，並在 withdraw_method_field 裡攜帶精心計算過的 % 符號數量與注入用的物件內容。
• 🏮 第二步：資料寫入資料庫後，反序列化時邊界破裂。資料經過 esc_sql() 膨脹後序列化，存進 wp_usermeta 資料表。當系統之後讀取這筆資料並呼叫 maybe_unserialize() 時，前面提到的長度落差就會讓解析器讀過頭，把攻擊者的物件注入進反序列化流程裡。
• 🏮 第三步：借用現成的元件完成寫檔。外掛檔案 classes/RestAPI.php 裡的 TUTOR\RestAPI 類別，透過 spl_autoload_register 註冊了外掛內建的 PayPal Composer 自動載入器，這讓反序列化引擎能順勢動態載入相依套件裡的 GuzzleHttp\Cookie\FileCookieJar 類別。這個物件在生命週期結束、被系統銷毀時會觸發 __destruct() 魔術方法，呼叫內建的寫檔函式把陣列資料寫入攻擊者指定的伺服器路徑，等於直接在你的網站裡放了一個後門檔案。

🧑‍🔧 DevOps 小知識：這種借用現成元件的手法，早在十幾年前就有專有名詞了
在 PHP 物件導向安全研究中，這種不需要在伺服器上憑空生出程式碼、而是把現有程式庫裡早已定義好的魔術方法（例如 __destruct、__wakeup）像樂高積木一樣串聯起來達成攻擊目的的手法，稱為屬性導向程式設計（Property-Oriented Programming，POP），最早由德國安全研究員 Stefan Esser 在 2010 年提出。這次的 GuzzleHttp\Cookie\FileCookieJar 就是一塊被反覆借用的經典積木，過去在 Laravel、WordPress 等多個生態系的物件注入案例裡都能看到它的身影 🧩

🟡 合理推論：由於整條攻擊鏈完全利用外掛內建的合法功能與自動載入機制，特徵比對型的 WAF 很難在第一時間攔截。🔴 假設情境：如果伺服器沒有做好目錄權限限縮，攻擊者透過後門進一步橫向讀取 wp-config.php 裡的資料庫密碼，甚至波及同主機上其他網站，也不是完全不可能的事 😥

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

🤖 重要提醒：以下指令與排查流程由 Gemini 產生、Claude 複查
雖然已盡力對照常見實務經驗與 WP-CLI 官方文件，但仍可能因伺服器環境、權限設定或外掛版本差異而產生疏漏。正式環境（尤其是正在收費招生的補習班網站）的高風險操作——包含更新、停用、刪除檔案、變更權限或執行批次腳本——請務必由熟悉該站架構的專業人員進行最後確認與執行，切勿直接複製貼上後就按下 Enter 🧙

如果你是自己架 VPS、同時管理多個 WordPress，這一節最重要的不是「背一條神奇迴圈指令」，而是先搞清楚自己到底是哪一種 WordPress 架構。搞錯架構，後面的批次指令就算語法完全正確，也可能處理錯對象；更麻煩的是，就算外掛版本已經衝到 4.0.8 以上，也不代表舊版暴露期間完全沒被摸過，因此這一節會依序走過環境判斷 👉 盤點（版本比對）👉 Log 日誌排查 👉 後門檢查點 👉 加固檢查五個關卡，每一關都拆成「決策原理 👉 具體指令 👉 預期輸出範例 👉 分支判斷邏輯」四個段落，並分別涵蓋單一網站、獨立多站、Multisite 三種環境 📜

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

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

決策原理：單一網站、獨立多站（同一伺服器上多個各自獨立的 wp-config.php）與 WordPress Multisite（單一核心程式管理多個子站）在 WP-CLI 執行範圍、資料庫架構與權限處理上完全不同，判斷失誤會直接讓後續盤點、備份、更新全部跑偏，必須先用官方指令確認，而不是憑印象猜 🤔

先用一段安全的判斷腳本，掃出伺服器上所有的 WordPress 安裝，並自動分類是哪一種架構。這裡刻意採用 -print0 搭配 read -r -d ” 的寫法，而不是直接把 find … -exec … | while read 接在一起，原因是路徑裡萬一有空格或特殊字元，後者很容易整個指令從中斷裂 ⚙️

SEARCH_ROOT="/var/www"
SITE_LIST="$(mktemp)"

find "$SEARCH_ROOT" -maxdepth 4 -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    if [ -f "$path/wp-load.php" ]; then
        printf '%s\n' "$path" >> "$SITE_LIST"
    fi
done

echo "=== 掃描到的 WordPress 安裝目錄 ==="
cat "$SITE_LIST"
SITE_COUNT="$(wc -l < "$SITE_LIST")"
echo "共找到 $SITE_COUNT 個獨立目錄"

echo "=== 逐一判斷是否為 Multisite ==="
while IFS= read -r path; do
    IS_MULTISITE="$(grep -E "define\(\s*['\"]MULTISITE['\"]\s*,\s*true\s*\)" "$path/wp-config.php" || true)"
    if [ -n "$IS_MULTISITE" ]; then
        echo "✴️ Multisite：$path"
    else
        echo "（先歸類為候選單站／獨立多站，待下方統一判斷）：$path"
    fi
done < "$SITE_LIST"

rm -f -- "$SITE_LIST"

預期輸出範例：

=== 掃描到的 WordPress 安裝目錄 ===
/var/www/example.com/public_html
共找到 1 個獨立目錄
=== 逐一判斷是否為 Multisite ===
（先歸類為候選單站／獨立多站，待下方統一判斷）：/var/www/example.com/public_html

分支判斷邏輯：

• ⭕ 若掃描結果中有任何一個目錄被標示為「✴️ Multisite」👉 該目錄底下的所有子站，都必須用 Multisite 的方式處理，不可拆開當成獨立多站來看。
• 🟠 若總共只找到 1 個目錄、且不是 Multisite 👉 歸類為 💠 單一網站。
• 🟡 若找到超過 1 個目錄、且各自都不是 Multisite 👉 歸類為 ❇️ 獨立多站，後續必須逐站取得目錄擁有者，禁止用同一組全域指令帶過。

🔎 盤點：哪些站裝了這款外掛、目前到底是哪一版？

決策原理：這一節不建議把版本號寫死在腳本裡，而是讓 WP-CLI 直接向 WordPress.org 官方資料比對。同時務必動態取得檔案實際擁有者再執行指令，避免用 root 身分批次操作，造成日後檔案權限錯亂 📊

💠 單一網站

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

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

預期輸出範例：

name: tutor
status: active
version: 4.0.7
update: available
update_version: 4.0.8

❇️ 獨立多站

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 tutor --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/public_html | Owner: site-a | Version: 4.0.8
Site: /var/www/site-b/public_html | Owner: site-b | Version: 4.0.7
Site: /var/www/site-c/public_html | Owner: site-c | Version: 3.9.13

✴️ Multisite

決策原理：Multisite 共用同一套外掛檔案，因此不需要對每個子站重複查詢版本，但必須先確認外掛是「Network 全站啟用」還是「各子站各自啟用」，才能決定後續處理範圍要多大 🧩

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

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

if sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin is-active tutor --network; then
    echo "外掛狀態：Network 全站啟用，處理範圍須以整個 Network 為單位"
else
    echo "外掛狀態：非全站啟用，需搭配 --url 逐一確認各子站狀態"
fi

分支判斷邏輯：

• 🔴 4.0.7 或更舊 👉 視為受影響，優先排入後面的備份／更新流程。
• 🟢 4.0.8 或更新 👉 此漏洞的版本條件已解除，但若網站曾經使用過舊版，仍應繼續往下做 Log 與後門排查。
• 🟠 找不到外掛 👉 先確認是否已被移除、資料夾名稱是否被改過，並確認沒有查錯網站路徑。

📊 Log 日誌排查特徵：不是看到請求就緊張，而是找「動作＋時間＋結果」的組合

決策原理：這條攻擊鏈完全利用外掛內建的合法 AJAX 通道，特徵比對型的 WAF 很難第一時間攔截，所以排查 Log 時真正有價值的不是找某個「神奇 IP」，而是確認是否曾經出現指向 tutor_save_withdraw_account 這個動作、且參數異常龐大或帶有序列化物件特徵的請求 🎯

WP_PATH="/var/www/example.com/public_html"
LOG_DIR="/var/log/nginx"

echo "=== 1. 檢查是否有針對提款端點的可疑 POST 請求 ==="
if [ -d "$LOG_DIR" ]; then
    zgrep -aE "admin-ajax\.php" "$LOG_DIR"/*access*.log* 2>/dev/null |
        grep -E "tutor_save_withdraw_account" | tail -n 100 ||
        echo "未在 URL Query 中發現明文特徵（🟡 提醒：攻擊者通常把參數放在 POST 內文，並不會顯示在網址列）"
else
    echo "LOG NOT FOUND：$LOG_DIR（請先確認實際 Web Server 的 Log 路徑）"
fi

echo "=== 2. 檢查是否有異常大小或非 200 回應的 admin-ajax 請求 ==="
zgrep -aE "POST .*admin-ajax\.php" "$LOG_DIR"/*access*.log* 2>/dev/null |
    awk '{ if ($9 >= 400 || $10 > 5000) print $1, $4, $7, $9, $10 }' | head -n 30

echo "=== 3. 檢查 PHP 錯誤日誌中的反序列化崩潰紀錄 ==="
ERR_LOG_DIR="/var/log/nginx"
zgrep -aEi "(unserialize\(\)|FileCookieJar|classes/Withdraw\.php)" "$ERR_LOG_DIR"/*error*.log* 2>/dev/null |
    head -n 30 || echo "日誌中未發現反序列化相關報錯"

預期輸出範例：

=== 1. 檢查是否有針對提款端點的可疑 POST 請求 ===
未在 URL Query 中發現明文特徵（🟡 提醒：攻擊者通常把參數放在 POST 內文，並不會顯示在網址列）
=== 3. 檢查 PHP 錯誤日誌中的反序列化崩潰紀錄 ===
日誌中未發現反序列化相關報錯

分支判斷邏輯：

• 🟢 只有零星請求、沒有異常大小封包或反序列化報錯 👉 目前沒有直接證據顯示已被引爆，但仍建議繼續往下做後門檢查。
• 🟡 出現頻繁的異常大小 POST 請求 👉 提高事件優先級，接著比對同一時間附近的檔案建立紀錄。
• 🔴 錯誤日誌中頻繁出現 unserialize(): Error at offset 或 FileCookieJar 拋錯 👉 高度懷疑已被觸發，立即進入下方「已中招」流程。

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

決策原理：這條攻擊鏈的落地方式是「把攻擊者控制的內容寫入指定檔案」，因此檢查焦點要鎖定：❶ wp-content/mu-plugins 強制載入目錄、❷ wp-content/uploads/ 靜態目錄裡新建的 .php 檔案、❸ 資料庫 wp_usermeta 表裡被塞入的異常物件字串 🕵️

資料庫查詢的部分刻意用 heredoc 把 SQL 寫成獨立的暫存檔，而不是直接把整段 SQL 塞進雙引號字串裡，原因是攻擊者塞進去的內容常常帶有大量 % 符號跟單引號，混在 Shell 的雙引號字串裡很容易跟變數展開規則互相打架，heredoc 反而是最不容易寫錯的方式 📜

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

echo "=== 1. 清查 mu-plugins 強制載入目錄 ==="
if [ -d "$MU_PLUGINS" ]; then
    find "$MU_PLUGINS" -maxdepth 2 -type f -iname "*.php" -ls
else
    echo "未發現 mu-plugins 目錄（正常狀態）"
fi

echo "=== 2. 清查 uploads 目錄中所有 PHP 執行檔 ==="
find "$WP_PATH/wp-content/uploads" -type f -iname "*.php" -ls

echo "=== 3. 搜尋過去 7 天內異動之 PHP 檔案 ==="
find "$WP_PATH" -type f -iname "*.php" -mtime -7 \
    -not -path "*/wp-content/cache/*" -ls

echo "=== 4. 檢查資料庫 usermeta 提款欄位是否被塞入異常物件 ==="
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"
QUERY_FILE="$(mktemp)"

cat > "$QUERY_FILE" <<'EOF'
SELECT user_id, meta_key, LEFT(meta_value, 100) AS preview
FROM wp_usermeta
WHERE meta_key LIKE '%withdraw%'
   AND (meta_value LIKE '%FileCookieJar%' OR meta_value LIKE '%O:%')
ORDER BY umeta_id DESC
LIMIT 20;
EOF

sudo -u "$OWNER" -- wp --path="$WP_PATH" db query < "$QUERY_FILE"
rm -f -- "$QUERY_FILE"

echo "=== 5. 檢查目前的管理員帳號清單，留意是否有陌生面孔 ==="
sudo -u "$OWNER" -- wp --path="$WP_PATH" user list \
    --role=administrator \
    --fields=ID,user_login,user_email,display_name,user_registered \
    --format=table

預期輸出範例：

=== 1. 清查 mu-plugins 強制載入目錄 ===
未發現 mu-plugins 目錄（正常狀態）
=== 4. 檢查資料庫 usermeta 提款欄位是否被塞入異常物件 ===
+---------+-------------------+----------------------+
| user_id | meta_key          | preview              |
+---------+-------------------+----------------------+
+---------+-------------------+----------------------+
=== 5. 檢查目前的管理員帳號清單，留意是否有陌生面孔 ===
ID  user_login  user_email          display_name    user_registered
1   admin       admin@example.com   Site Admin      2024-03-10 08:30:00

分支判斷邏輯：

• 🔴 mu-plugins 出現非部署流程建立的 PHP 檔案，或 uploads 目錄下出現任何 .php 檔案 👉 不要直接刪除，先保留檔案時間、權限、副本供鑑識，並進入下方「已中招」流程。
• 🟡 wp_usermeta 查詢結果非空、或出現含 FileCookieJar 字樣的內容 👉 標記該筆使用者 ID，之後清理時只針對這幾筆處理，不要整張表清空。
• 🟢 找不到可疑檔案、查詢結果也是空的 👉 這一項沒有發現異常，但管理員清單裡任何不認識的帳號仍值得進一步確認，「陌生」不等於「惡意」，也可能是既有維運帳號。

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

決策原理：加固不能只靠「更新外掛」單一動作，還要從伺服器層與檔案完整性兩個角度收斂攻擊面。這裡也是驗證「目前檔案是不是真的變成官方修補版本」最務實的做法：不去手動比對正則表達式或序列化邏輯，而是讓 WP-CLI 直接向 WordPress.org 官方提供的 checksum 資料庫比對 🔒

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

echo "=== 1. 外掛與核心檔案 Checksum 驗證 ==="
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin verify-checksums tutor
sudo -u "$OWNER" -- wp --path="$WP_PATH" core verify-checksums

echo "=== 2. 檢查關鍵檔案與目錄的權限 ==="
stat -c "%a %n" "$WP_PATH/wp-config.php"
stat -c "%a %n" "$WP_PATH/wp-content"

echo "=== 3. 檢查 php.ini 是否已停用高風險函式 ==="
php -r 'echo "已停用函式：" . ini_get("disable_functions") . "\n";'

echo "=== 4. 驗證 uploads 目錄是否禁止直接執行 PHP ==="
TEST_FILE="$WP_PATH/wp-content/uploads/sec_probe_$(date +%s).php"
echo "<?php echo 'EXECUTABLE'; ?>" > "$TEST_FILE"
HTTP_CODE="$(curl -s -o /dev/null -w "%{http_code}" "https://example.com/wp-content/uploads/$(basename -- "$TEST_FILE")" || true)"
rm -f -- "$TEST_FILE"
echo "靜態目錄 PHP 存取狀態碼：$HTTP_CODE（安全標準應為 403 或 404）"

預期輸出範例：

=== 1. 外掛與核心檔案 Checksum 驗證 ===
Success: Verified 1 of 1 plugins.
Success: WordPress installation verifies against checksums.
=== 2. 檢查關鍵檔案與目錄的權限 ===
440 /var/www/example.com/public_html/wp-config.php
755 /var/www/example.com/public_html/wp-content
=== 3. 檢查 php.ini 是否已停用高風險函式 ===
已停用函式：exec,passthru,shell_exec,system,proc_open,popen
=== 4. 驗證 uploads 目錄是否禁止直接執行 PHP ===
靜態目錄 PHP 存取狀態碼：403（安全標準應為 403 或 404）

🧑‍🔧 DevOps 小知識：Checksum 驗證只能保護「官方檔案」，管不到 Pro 版
wp plugin verify-checksums tutor 能有效驗證，是因為 Tutor LMS 的免費核心版本有上架在 WordPress.org 官方目錄。但如果你有另外安裝 Tutor LMS Pro 這種透過 Themeum 官網單獨銷售的商業附加套件，它並不在 WordPress.org 的 checksum 資料庫裡，這個指令對它完全無效。要確認 Pro 版檔案是否被竄改，只能自己下載官方 ZIP，用 SHA256 雜湊比對或 diff -rq 逐檔案比對，這是商業附加套件跟開源核心版本在驗證上最大的差異 🗝️

分支判斷邏輯：

• 🔴 若 wp-config.php 權限為 644 或更寬鬆 👉 立即執行 chmod 440 “$WP_PATH/wp-config.php”。
• 🔴 若靜態目錄測試回傳 200 👉 代表伺服器允許在使用者上傳目錄裡直接執行 PHP 檔案，必須立即在 Nginx 或 Apache 補上阻擋規則（見下方短期應急段落的範例）。
• 🟡 若 Checksum 出現 mismatch 👉 代表檔案內容跟官方版本不同，可能有人手動修改過外掛檔案，應立即進一步做入侵鑑識，不要視為正常現象。

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

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

• 🌠 Q：按了更新，課程頁面會不會跑掉或當機？
  A：Tutor LMS 4.0.8 主要是針對底層驗證機制與序列化流程進行修正，並沒有大幅更動課程資料或前台版面配置，一般情況下不會影響既有課程顯示。但保險起見，動手前先備份資料庫絕對是不變的真理 💾
• 🌟 Q：外包廠商說「我們又沒開提款功能，不用管它」，我該聽他的嗎？
  A：建議別急著這樣結案。就算你目前沒開講師分潤或提款功能，只要外掛還處於「啟用」狀態，日後哪天需要用到這個功能而打開它，攻擊者就有機會摸到這個端點。更保險的做法還是直接更新到安全版本，而不是靠「反正沒開」來自我安慰 🛟

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

前一節解決的是「怎麼判斷」，這一節則進入真正的維運 Runbook。無論你屬於哪一種情境，強制流程都是同一套：盤點 👉 備份 👉 Dry-run 👉 更新 👉 驗證，每個階段都必須完成，才能進入下一階段 🧹

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

⚠️ 安全提醒：即將進行系統隔離、金鑰刷新與檔案封裝操作，執行前請務必再三確認路徑正確、且已預留備份空間！

決策原理：一旦上一節的排查出現明確跡象（mu-plugins 出現可疑檔案、usermeta 資料異常、Log 中出現反序列化報錯），優先目標是「切斷攻擊鏈＋保留證據＋隔離後門」，而不是急著立刻更新——更新只是後續步驟。最大的敵人不是漏洞本身，而是在沒有留下證據的情況下直接清理，反而把最有價值的線索一起刪掉 🛟

處理步驟：❶ 立即隔離 👉 ❷ 緊急取證 👉 ❸ 強制刷新鹽值銷毀所有 Session 👉 ❹ 隔離可疑檔案並乾淨更新

# 適用於單一網站、獨立多站、Multisite（Multisite 請把 WP_PATH 換成 Network 根目錄）
WP_PATH="/var/www/example.com/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"
EVIDENCE_DIR="$HOME/forensics_$(date +%Y%m%d_%H%M%S)"

mkdir -p "$EVIDENCE_DIR"

# ❶ 立即隔離：啟用全站維護模式並停用外掛
sudo -u "$OWNER" -- wp --path="$WP_PATH" maintenance-mode activate
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin deactivate tutor

# ❷ 緊急取證：封裝日誌、可疑目錄與受污染的資料庫內容
cp -a "/var/log/nginx" "$EVIDENCE_DIR/nginx-logs" 2>/dev/null || true
cp -a "$WP_PATH/wp-content/mu-plugins" "$EVIDENCE_DIR/mu-plugins" 2>/dev/null || true

QUERY_FILE="$(mktemp)"
cat > "$QUERY_FILE" <<'EOF'
SELECT * FROM wp_usermeta WHERE meta_key LIKE '%withdraw%';
EOF
sudo -u "$OWNER" -- wp --path="$WP_PATH" db query < "$QUERY_FILE" > "$EVIDENCE_DIR/withdraw_meta_dump.txt"
rm -f -- "$QUERY_FILE"

grep -E "POST .*admin-ajax\.php" /var/log/nginx/*access*.log 2>/dev/null |
    tail -n 100 > "$EVIDENCE_DIR/suspicious_requests.txt"

# ❸ 強制刷新鹽值：這是最關鍵的一步，能瞬間讓所有已核發的登入 Cookie 全部失效
# 因為 WordPress 的登入驗證 Cookie 是用這組鹽值簽章的，鹽值一換，舊 Cookie 全數作廢，攻擊者手上的任何既有登入態都會直接被踢出
sudo -u "$OWNER" -- wp --path="$WP_PATH" config shuffle-salts

# 針對每一個管理員帳號強制設定新密碼（不透過可能失效的登入態，直接改資料庫紀錄）
sudo -u "$OWNER" -- wp --path="$WP_PATH" user list \
    --role=administrator --field=ID |
while IFS= read -r admin_id; do
    NEW_PASS="$(openssl rand -base64 24)"
    sudo -u "$OWNER" -- wp --path="$WP_PATH" user update "$admin_id" \
        --user_pass="$NEW_PASS"
    printf '已重設管理員 ID %s 的密碼，請透過安全管道另行通知本人\n' "$admin_id"
done

# ❹ 隔離 uploads 目錄下的可疑 PHP 檔案（先隔離、不要直接刪除，保留鑑識價值）
QUARANTINE_DIR="$EVIDENCE_DIR/quarantine"
mkdir -p "$QUARANTINE_DIR"
find "$WP_PATH/wp-content/uploads" -type f -iname "*.php" -print0 |
while IFS= read -r -d '' suspicious_file; do
    printf '隔離可疑檔案：%s\n' "$suspicious_file"
    chmod 000 -- "$suspicious_file"
    mv -- "$suspicious_file" "$QUARANTINE_DIR/"
done

# 完成止血後才進行乾淨更新
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin update tutor
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin activate tutor
sudo -u "$OWNER" -- wp --path="$WP_PATH" maintenance-mode deactivate

echo "事件證據保存位置：$EVIDENCE_DIR"

預期輸出範例：

Enabling Maintenance mode...
Plugin 'tutor' deactivated.
Success: Rotated the salt keys.
已重設管理員 ID 1 的密碼，請透過安全管道另行通知本人
隔離可疑檔案：/var/www/example.com/public_html/wp-content/uploads/2026/09/x1a2b3.php
Updating plugin 'tutor'...
Success: Updated 1 of 1 plugins.
Plugin 'tutor' activated.
Disabling Maintenance mode...
事件證據保存位置：/home/admin/forensics_20260913-101530

分支判斷邏輯：若隔離區裡確實找到具備遠端操作能力的 PHP 後門檔案 👉 代表主機系統層可能已遭橫向滲透，強烈建議依據乾淨備份重建主機環境，而不是只靠「移除後門」就當作結案；若隔離與重設動作全部順利完成、且沒有找到具體後門檔案 👉 可以放心進入正式修補流程繼續往下走 🔁

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

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

# 關閉使用者公開註冊，直接斷開這次漏洞最常見的取得帳號管道
WP_PATH="/var/www/example.com/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"
sudo -u "$OWNER" -- wp --path="$WP_PATH" option update users_can_register 0

若暫時無法更新，也可以直接在 Web 伺服器層擋掉這個特定動作。以下 Nginx 範例刻意只做「攔截這個 action 就回傳 403」，不去覆蓋你原本既有的 PHP 執行區塊設定，避免不小心把你主機商設定好的 PHP-FPM 連線路徑蓋掉：

location ~* /wp-admin/admin-ajax\.php {
    if ($arg_action = "tutor_save_withdraw_account") {
        return 403;
    }
    # 這裡不覆寫 fastcgi_pass，讓請求繼續往下走你原本既有的 PHP 執行區塊設定
}

預期輸出範例：

Success: Updated 'users_can_register' option.

分支判斷邏輯：若業務上真的需要維持講師線上登記提款、無法直接關閉這個功能 👉 這條 Nginx 規則會連合法講師都一併擋下，此時應儘速排入下方「C. 正式修補」的更新窗口，而不是把這條規則當成長期解方 🚦

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

🩵 荷包試算：這幾道防線要花多少錢？
更新免費版 Tutor LMS 完全不用花錢，只要有後台或 SSH 權限就能自己動手。真正會花到錢的地方，通常是「已經中招之後」——請資安顧問做鑑識、清除後門的工時，或是網站被搜尋引擎標記危險之後重建招生流量的成本，這筆帳，怎麼算都是現在花半小時走完這套 Runbook 比較划算 💸

③ 備份：依 3-2-1 備份原則，至少 3 份、2 種媒介、1 份異地

# 💠 單一網站
WP_PATH="/var/www/example.com/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"
BACKUP_DIR="$HOME/wp-security-backup"
STAMP="$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"

sudo -u "$OWNER" -- wp --path="$WP_PATH" db export \
    "$BACKUP_DIR/site_pre_update_${STAMP}.sql"

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

# ❇️ 獨立多站：逐站備份，檔名帶入站台名稱避免互相覆蓋，每站之間加入短暫延遲
SEARCH_ROOT="/var/www"
BACKUP_DIR="$HOME/wp-security-backup"
STAMP="$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"

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")"

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

    echo "備份 $path（擁有者：$owner）"
    sudo -u "$owner" -- wp --path="$path" db export \
        "$BACKUP_DIR/${site_name}_db_${STAMP}.sql"
    tar -czf "$BACKUP_DIR/${site_name}_wp-content_${STAMP}.tar.gz" \
        -C "$path" "wp-content"
    sleep 2
done

# ✴️ Multisite：db export 匯出的是整個網路共用的資料庫，不需要對每個子站重複執行
WP_PATH="/var/www/network/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"
BACKUP_DIR="$HOME/wp-network-backup"
STAMP="$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"

sudo -u "$OWNER" -- wp --path="$WP_PATH" db export \
    "$BACKUP_DIR/network_full_db_${STAMP}.sql"
tar -czf "$BACKUP_DIR/network_wp-content_${STAMP}.tar.gz" \
    -C "$WP_PATH" "wp-content"

🚨 不要在 Multisite 的每個子站網址上重複執行整個 wp db export。這只是把同一個 Network 共用資料庫重複匯出好幾次，既浪費空間也沒有增加實質備份價值 🗄️

④ Dry-run：正式更新前先預覽會發生什麼事

# 三種環境語法相同，差別只在 WP_PATH 是否需要逐站帶入
WP_PATH="/var/www/example.com/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin update tutor --dry-run

預期輸出範例：

Plugin tutor 4.0.7 will be updated to 4.0.8.

分支判斷邏輯：看到目標版本 👉 可以正式更新；顯示沒有可用更新 👉 回頭確認目前版本與更新來源，不要因為「No updates」就直接認定網站安全，也可能是外掛來源已被鎖定在某個舊版鏡像 🔮

⑤ 更新（「正確做法」與「危險做法」對比）

🚨 危險做法（強烈禁止）：for d in /var/www/*; do wp –path=”$d” plugin update –all & done——缺少目錄檢查、沒有逐站備份、單一巨大迴圈一次平行更新所有站台，中途若撞上資料庫鎖死，很容易讓整台伺服器負載直接崩潰 🙅

✅ 正確做法（逐站完成備份 👉 停用外掛 👉 更新 👉 重新啟用 👉 驗證）：

# 💠 單一網站
WP_PATH="/var/www/example.com/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"

sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin deactivate tutor
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin update tutor
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin activate tutor

# ❇️ 獨立多站：逐站處理，每站之間加入 3 秒延遲緩衝伺服器 I/O 負載
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" plugin is-installed tutor 2>/dev/null; then
        continue
    fi

    echo "開始為站台執行外掛更新：$path"
    sudo -u "$owner" -- wp --path="$path" plugin deactivate tutor
    sudo -u "$owner" -- wp --path="$path" plugin update tutor
    sudo -u "$owner" -- wp --path="$path" plugin activate tutor
    echo "該站升級完成，進入 3 秒資源緩衝……"
    sleep 3
done

# ✴️ Multisite：外掛檔案於 Network 層只需要更新一次
WP_PATH="/var/www/network/public_html"
OWNER="$(stat -c '%U' -- "$WP_PATH/wp-config.php")"

sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin update tutor
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin activate tutor --network

⑥ 驗證：更新成功 ≠ 工作完成，至少完成三層深度驗證

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

echo "=== 第一層：版本號比對 ==="
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin get tutor --field=version

echo "=== 第二層：外掛與核心檔案 Checksum 雜湊校驗 ==="
sudo -u "$OWNER" -- wp --path="$WP_PATH" core verify-checksums
sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin verify-checksums tutor

echo "=== 第三層：前後台功能與 HTTP 狀態碼確認 ==="
curl -s -o /dev/null -w "前台首頁狀態碼：%{http_code}\n" "https://example.com/"
curl -s -o /dev/null -w "後台登入頁狀態碼：%{http_code}\n" "https://example.com/wp-login.php"

預期輸出範例：

=== 第一層：版本號比對 ===
4.0.8
=== 第二層：外掛與核心檔案 Checksum 雜湊校驗 ===
Success: WordPress installation verifies against checksums.
Success: Verified 1 of 1 plugins.
=== 第三層：前後台功能與 HTTP 狀態碼確認 ===
前台首頁狀態碼：200
後台登入頁狀態碼：200

分支判斷邏輯：更新後若仍持續在 Log 裡看到可疑的 admin-ajax 請求，或 uploads 目錄又出現新的可疑檔案 👉 不要把它當成「已經更新所以沒事」，應回到上方「A. 已中招」流程重新處理，而不是單純再更新一次外掛就結案 🔁

🔥 一句話總結：真正安全的批次維運，是先盤點、再備份、再 Dry-run，確認無誤後才逐站更新，最後驗證。環境判斷錯誤比指令寫錯更致命，這套判斷環境 👉 盤點 👉 備份 👉 Dry-run 👉 更新 👉 驗證的閉環，換成下一次別的外掛、別的 CVE，一樣可以直接套用 🦸

📋 三種架構的排查地圖速查表

🧠 舉一反三：同類型漏洞的通用防禦知識庫

以下為該類型漏洞的通用防禦知識，並非本 CVE 官方要求：

• 🌟 能不用 PHP 原生序列化，就盡量別用：處理需要長期儲存或跨系統交換的複合型態資料時，現代 Web 應用應優先採用 json_encode() 與 json_decode() 取代原生序列化，從根本封堵物件注入的攻擊破口。
• 🌠 Nonce 跟權限檢查永遠要一起出現：所有 AJAX 或 REST 端點，除了驗證 Nonce，務必再加上 current_user_can() 這類角色權限檢查，避免陷入「有票就能進」的邏輯陷阱。
• ✨ 資料入庫前別過早呼叫轉義函式：嚴禁把不會直接拼進 SQL 查詢語句的資料，預先丟進 esc_sql() 處理，以免觸發前面提到的 HMAC 佔位符號長度劇變問題。

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

🔥 這起事件其實也提醒了所有教學平台經營者一件事：真正危險的破口，往往不是藏在最顯眼的登入畫面，而是藏在「提款」「金流」這類感覺應該只有老師才會碰到的角落。與其等哪天講師真的要領錢才發現不對勁，不如現在就花五分鐘，打開後台看一眼版本號碼，順便想想「開放註冊」跟「開啟提領」這兩個開關，是不是真的都需要一直開著 🔢

📚 參考資料與延伸資源

• 📌 CVE-2026-78175 官方紀錄（CVE.org）
• 📌 NVD 漏洞詳情頁
• 📌 Wordfence 威脅情資：Tutor LMS 物件注入導致 RCE 完整分析
• 📌 Tutor LMS 官方 WordPress 外掛頁面與更新日誌
• 📌 WordPress Plugin Trac 修補紀錄變更集
• 📌 CVE-2021-24184：Tutor LMS 歷史越權漏洞紀錄