只要改一個數字就能變管理員？MemberDash 帳號接管漏洞全解析（CVE-2026-16310／CVSS 9.8）

🔥 懶人包：
知名 WordPress 會員管理外掛 MemberDash（目前已併入 LearnDash 家族）被抓到一個「不用登入、不用密碼，光靠改一個數字就能洗掉任何人密碼」的重大漏洞（CVE-2026-16310，CVSS 9.8 嚴重等級）。攻擊者只要在「新會員註冊」這個公開表單裡動一點小手腳，就能直接竄改網站管理員的密碼，整個過程不會發任何通知信，你完全不會發現。目前尚未觀察到大規模攻擊災情，但強烈建議所有還在使用 1.8.5 以下版本的網站，盡快升級到 1.8.6 以上 ☄️

🧊 冷知識：為什麼駭客特別愛鎖定「1 號會員」？
你知道嗎，幾乎所有 WordPress 網站，第一個被系統建立的管理員帳號，資料庫裡的編號永遠是 1，這是 WordPress 安裝流程的內建慣例，二十年來幾乎沒變過。也因為這個規律「太好猜」，只要外掛程式沒把「使用者身分」跟「使用者能改誰的資料」這兩件事分開檢查，攻擊者連試都不用試，直接打 id=1 命中率就高得嚇人——這次 MemberDash 的漏洞，某種程度上就是拿這個大家都知道、卻很少有人真的去防的老規律，狠狠將了一軍 🎯

🌐 檢視 Nexcess 官方 MemberDash 1.8.6 更新日誌 ^[1]

^[2]

---

🧐 一支密碼是怎麼在你毫無察覺下被換掉的？

先問你一個問題：如果有一台自動發卡機，你只要在申請表上填「我是 1 號會員」，它就會二話不說把 1 號會員原本的密碼洗掉、換成你自己設的新密碼——你會不會覺得這台機器根本沒在檢查身分證 🤔

這種漏洞在資安圈有個專有名詞，叫做「不安全直接物件參考」，英文縮寫 IDOR。講白話一點，就是系統把「你是誰」跟「你要改的東西是誰的」這兩件事搞混了——它只顧著把你要求的動作做完，卻忘了先問一句「這真的是你的東西嗎」。而且要抓出這個漏洞根本不需要什麼進階駭客技巧，純粹就是把網址或表單裡那個數字換一換，看看系統會不會照單全收 🔓

🧊 碎碎念：這招其實比 SQL 隱碼攻擊更「省力」
早年駭客熱衷鑽研複雜的資料庫隱碼攻擊，得懂語法、懂資料庫結構才玩得起來。但這幾年他們發現一條更輕鬆的路：很多系統的網址或表單裡會直接寫著像 id=123 這樣的東西，只要手動把數字改一改，後台沒做好身分驗證的話，別人的資料就直接攤在眼前。這招完全不用寫程式、不用懂資料庫，純靠「換數字」，也因此被國際資安組織 OWASP 列為近年 API 安全威脅的第一名 🥇

真正讓這台機器「照單全收」的原因，出在後端程式碼收到註冊請求時，過度信任了前端傳過來的 id 參數。系統應該做的事情是：先確認「現在發起這個請求的人，究竟有沒有權限去動這個 id 對應的帳號」，但 MemberDash 在這個環節上直接跳過了這一步，看到 id 就直接拿去對資料庫下更新指令。這也是為什麼即使你完全沒有帳號密碼，光靠一個 POST 請求就能把管理員的密碼洗掉 🔍

---

⏱️ 從一行不起眼的更新日誌，到 9.8 分的極高危漏洞

回頭看這起事件的時間軸，其實蠻值得玩味的——一開始根本沒人把它當一回事：

這裡有個蠻諷刺的地方：官方其實早在 8 月 18 日就把洞補起來了，只是更新日誌寫得太低調（「加強資料驗證」聽起來就像例行保養，誰會多想），結果整整晚了將近三週，外界才搞清楚這行雲淡風輕的描述背後，其實是一個能讓陌生人直接接管網站的重大破口 😮

^[54]

---

😨 講白了，這件事最後會怎麼影響到我？

跟大部分資安事件不一樣，這次的威脅完全不需要駭客擁有任何帳號密碼——我們照事實確定程度，一層一層拆給你看：

• 🏮 ✅ 已確認事實：不用登入、不用會員身分，就能直接改別人密碼。攻擊者只需要對外公開的註冊端點發出一個特製的網路請求，並在其中夾帶指定的 id 參數（例如管理員的帳號編號），系統就會未經任何驗證直接覆寫該帳號的密碼。
• 🏮 ✅ 已確認事實：這是一場「靜默接管」，你不會收到任何警示信。因為整個過程並沒有經過 WordPress 核心標準的「忘記密碼」流程，你不會收到「您的密碼已變更」這類系統通知信。你只會在某天正常想登入時，才驚覺密碼一直顯示錯誤。
• 🏮 🟡 合理推論：一旦被公開的攻擊工具流出，自動化掃描很可能很快鋪天蓋地而來。由於這個攻擊手法完全不需要任何前置條件（不用帳號、不用密碼、不用社交工程），一旦有現成的攻擊腳本流入駭客社群，針對全網已知安裝 MemberDash／LearnDash 的網站進行無差別掃描，幾乎是遲早的事。
• 🏮 🔴 假設情境：如果被接管的是擁有完整權限的管理員帳號，後果可能一路燒到伺服器層級。駭客登入後台後，理論上能透過佈景主題編輯器植入惡意程式碼，或直接安裝帶有後門的外掛，進一步取得伺服器的遠端操控能力，導致資料外洩、內容竄改，甚至把你的網站變成攻擊其他站台的跳板。

🧊 冷知識：MemberDash 其實才剛換過招牌
如果你覺得 MemberDash 這個名字有點陌生又有點熟悉，那是因為它原本是 StellarWP 軟體集團旗下獨立的會員管理外掛。2026 年 5 月左右，母公司 Liquid Web 進行了一次大規模品牌整併，把龐大的 StellarWP 產品線收攏，將 MemberDash 整個併入知名的線上課程外掛 LearnDash 之下。如果你是 LearnDash 用戶，這時候特別建議回頭檢查一下自己有沒有順帶啟用了這個會員模組，別讓它變成漏網之魚 🐟

---

🎭 先別自己嚇自己，看看你最接近哪一種角色

看到這裡如果已經開始緊張，先深呼吸——不同身分該做的事情差很多，我們一個一個拆給你看 🧘

🙋 我只是負責發文、管會員的網站小編

如果你平常的工作是寫文章、管理課程、回覆學員，完全不碰程式碼跟複雜設定，那你要做的事情其實很單純：確認版本、點更新，必要時請人幫忙檢查一下有沒有異常帳號。這件事完全免費，也不需要你懂任何技術背景，直接跳到下面「五分鐘無痛自救指南」照著做就好 💪

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

如果你同時顧著好幾個網站，一個一個點後台檢查太沒效率。這種情況下，用 WP-CLI 批次盤點所有站台的版本會實際很多，後面的技術深潛篇會直接給你可以貼上就用的排查指令，建議拉到那一段 👇

🏢 我的網站有付費會員，或是靠課程收入維生

如果你的網站牽涉到會員個資、課程訂閱或線上收款，這件事就不只是「更新一個外掛」這麼簡單了——一旦會員資料被證實外洩，你面對的可能不只是商譽受損，還有個資保護相關法規的責任歸屬問題。除了更新跟重置密碼之外，建議同步啟動內部的資安應變流程，把稽核紀錄留存下來，之後不管是跟保險公司對帳、還是配合調查，都用得上 🩺

🩵 荷包試算：修補這個漏洞，到底要不要花錢？
伺服器層防護規則、停用外掛這些應急措施，本質上都是免費操作，只要有後台或 SSH 權限就能自己動手。真正可能牽涉到費用的地方是：如果你的 MemberDash／LearnDash License 已經過期沒續訂，官方更新伺服器可能不會讓你直接透過後台「立即更新」拿到 1.8.6，這時候你得先續訂授權，或是聯繫 Nexcess 客戶入口網站手動下載安裝檔。這筆帳怎麼算，都是現在花小錢續訂授權，比之後花大錢請資安顧問處理已入侵網站划算得多 💸

🚨 這種情境最容易被忽略：品牌併購後被遺忘的舊會員模組

🚥 劃重點：「已經換成別的方案」不等於「舊外掛沒有風險」，只要它還在啟用清單裡，這道門就是開著的——這也是這次事件最容易被忽略的角落 🙅‍♂️

^[55]

---

🛟 電腦小白也能跟上的五分鐘自救指南

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

• ㊀ 先去哪裡確認版本？
  登入你的 WordPress 後台，點左側選單的「外掛（Plugins）」，再點「已安裝的外掛（Installed Plugins）」。在清單裡找到名字叫 MemberDash 的那一項，它下方會標示目前的版本號碼 🔢
• ㊁ 看到版本號之後，怎麼判斷自己安不安全？
  如果版本號寫著 1.8.5 或更小的數字（例如 1.8.0、1.8.4），代表你目前正暴露在風險裡；如果已經顯示 1.8.6 或更新，那就可以先鬆一口氣。判斷標準就是這一個數字 ㊙️
• ㊂ 需不需要馬上更新？
  需要，而且優先程度排在今天所有代辦事項的第一位。直接在同一個畫面點「立即更新（Update Now）」按鈕，跑完之後重新整理頁面，確認版本號已經變成 1.8.6 以上即可 💪
• ㊃ 如果點了更新卻沒反應，或是根本找不到更新按鈕怎麼辦？
  這通常代表你的授權（License）已經過期，或系統暫時無法連上官方更新伺服器。這種情況不需要自己硬著頭皮排除，直接把這篇報告轉傳給你的網站維護工程師、外包商，或是主機代管服務商，請他們優先處理，同時順便檢查一下有沒有已經被入侵的跡象。找人幫忙是很正常的事，不用不好意思開口 🙇
• ㊄ 如果暫時真的沒辦法更新，該怎麼辦？
  既然這個漏洞是透過「新會員註冊」這個功能觸發的，如果你的網站目前並不開放公開註冊，可以請懂技術的朋友或工程師先在後台把 MemberDash 停用，等準備好更新再重新啟用。這能百分之百截斷這條攻擊路徑 🤔
• ㊅ 如果你完全找不到「外掛」這個選單，或不熟悉整套流程呢？
  請立刻聯絡你的網站建置商、維護團隊或代管主機客服。跟他們溝通時，直接提供「CVE-2026-16310」這個編號，專業技術人員就能立刻理解問題的嚴重性並協助處置。在還沒完整備份前，請不要自己貿然進入主機底層刪除任何檔案❗

🫂 新手求助：完全看不懂「後台」「授權」這些詞怎麼辦？
完全沒關係，這篇報告本來就不是要你變成資安專家。如果你連「已安裝外掛」這個選單都找不到，最快的方式就是把整篇報告網址直接轉傳給你的主機商客服或網站外包商，跟他們說「我這個外掛有嚴重漏洞，麻煩幫我更新並檢查」，這件事本來就不該是每個網站主一個人扛 🤗

---

🤿 技術控請進：這串攻擊的破口到底藏在程式碼哪個角落

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

🧑‍🔧 DevOps 小知識：這次 CVSS 向量裡的 PR:N，是玩真的
有些漏洞的 CVSS 向量會寫著低權限（PR:L），但實際上第一步的「埋雷」階段根本不需要驗證，容易誤導防禦者掉以輕心。這次 MemberDash 的 PR:N（不需任何權限）倒是老老實實反映了真實狀況：因為這是「一次性」的單階攻擊，攻擊者從頭到尾都不需要取得任何合法身分，發出的請求本身就足以直接完成密碼覆寫，沒有像某些「先埋雷、等你自己觸發」的二階漏洞那樣需要拆成兩段來看權限要求 ⚙️

問題出在 MemberDash 處理未授權使用者的註冊流程時，對於「物件擁有權」缺乏足夠深度的校驗。🟡 合理推論，當前端發起註冊請求，後端對應的處理邏輯過度信任了由使用者端傳入的 id 參數（也就是俗稱的 User-controlled key）。正常設計應該是：伺服器自己決定新帳號要分配哪個編號，並且在處理任何「更新」動作前，先核對「發起請求的這個人，到底有沒有資格去改這個編號對應的資料」。但 MemberDash 在這個環節上直接省略了這道核對手續 🔎

這意味著，當攻擊者在 POST 請求的 Payload 中夾帶 id=1（或任何鎖定的高權限使用者編號）時，外掛並不會去檢查這個 id 是否屬於當前發起請求的 Session，而是直接對該 id 執行資料庫的密碼覆寫操作，因而導致嚴重的越權行為 🔍

^[56]

---

🎯 一支密碼是怎麼在三個動作內被換掉的

整條攻擊路徑其實比想像中還要單純，完全不需要繞路，拆開來看邏輯相當直接 🕵️‍♀️

• 🏮 第一步：找到公開的註冊端點。攻擊者只需要鎖定 MemberDash 對外開放的前端註冊表單或對應的 API 端點，這個端點原本的設計就是給「還沒有帳號的陌生人」使用，因此完全不需要任何 Access Token、Session Cookie 或會員身分。
• 🏮 第二步：在請求裡夾帶偽造的 id 參數。攻擊者在發送的 HTTP POST 請求中，把原本應該由系統自動配發的 id 欄位，改成自己指定的數值（例如管理員帳號的編號），同時附上自己設定的新密碼。
• 🏮 第三步：後端未經驗證直接覆寫密碼。由於外掛沒有比對這個 id 是否真的屬於當前請求者，系統會直接執行資料庫更新，把該帳號的密碼換成攻擊者剛剛指定的新密碼。整個過程並未呼叫 WordPress 核心標準的密碼重設流程，因此不會觸發任何通知信，受害者只會在下次登入失敗時才驚覺異常。

🟡 合理推論：由於攻擊手法高度自動化，且完全沒有任何身分前置條件，一旦公開的概念驗證腳本在資安社群或地下論壇流傳，很可能出現大規模的自動化掃描，針對全網已知安裝 MemberDash／LearnDash 的主機發動無差別攻擊。🔴 假設情境：若被接管的管理員帳號擁有佈景主題編輯器或外掛安裝權限，攻擊者理論上能進一步植入後門檔案，達成遠端程式碼執行，讓整台伺服器的安全性一併淪陷 😥

---

🕵️‍♀️ DevOps 排查手冊：三種架構、五道關卡，一次講清楚

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

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

🔥 一句話先記住：「版本已升級到 1.8.6」代表你已經跨過這道漏洞的修補門檻，但不等於「網站歷史上從來沒被摸過」。版本修補與入侵排查應該視為兩件不同的工作，缺一不可 🧯

🧑‍🔧 DevOps 小知識：先判斷地圖，再決定走哪條路
「一台伺服器上有 10 個 WordPress」跟「一個 WordPress Multisite 裡面有 10 個 Site」看起來很像，實際上卻是兩種完全不同的架構。前者應該逐一找到各網站的 wp-config.php；後者才應該使用 wp site list。WP-CLI 官方對 wp site list 的定義就是列出 Multisite installation 中的 Sites，不是一般獨立站 🫠

🧭 關卡一：你到底是在管一個 WordPress，還是一整台 WordPress 伺服器？

決策原理：環境判斷錯誤會直接導致後續盤點、Log 排查、備份、更新全部跑偏——單一站、獨立多站、Multisite 三者的 WP-CLI 參數與資料範圍完全不同，必須先用官方指令確認，而不是憑印象猜 🤔

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

決策原理：先確認目前路徑真的能載入 WordPress，再往下查外掛版本，這比直接執行一長串批次指令安全許多 🛡️

💡 新手避坑指南：關於路徑與指令替換
接下來的指令中會出現📂 /var/www/example.com/public_html 這類路徑，以及 www-data 這類使用者。如果你用的是 Cloudways，路徑通常會有 public_html；如果是 cPanel，通常在 /home/你的帳號/public_html；👥 記得替換下方的使用者為真實使用者：www-data:www-data。複製貼上執行前，務必將這些變數替換成你主機的真實環境，且指令中的引號包覆（如 “$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

# 進一步確認是否為 Multisite，檢查 wp-config.php 內的常數
grep -E "MULTISITE|SUBDOMAIN_INSTALL|DOMAIN_CURRENT_SITE|PATH_CURRENT_SITE" "$WP_PATH/wp-config.php"

預期輸出範例：

OK: WordPress installation detected.

分支判斷邏輯：

• ⭕ 顯示 OK，且 grep 沒有找到 MULTISITE 常數 👉 確定是單一網站，可以進入盤點階段
• 🟠 顯示 ERROR 👉 先停止，不要把錯誤目錄當成網站處理
• 🟡 如果網站路徑含空格或特殊字元，保留 “$WP_PATH” 的雙引號，不要自行刪除，避免指令從中被切斷

❇️ 獨立多站：用官方推薦的 NUL 分隔寫法，安全地找出每一個 WordPress

決策原理：HestiaCP、cPanel 或自行管理 VPS 時，「同一台伺服器有很多 WordPress」不代表 Multisite。這時應該從各站的 wp-config.php 建立 Inventory，並取得檔案實際擁有者，避免用單一 Linux 帳號跑遍所有網站造成權限錯亂。這裡刻意採用 find -print0 搭配 read -r -d ” 的寫法，而不是常見的 -exec … \; | while read，原因是前者能正確處理路徑中含有空格、換行等特殊字元的極端情況，這是 WP-CLI 官方文件也建議的批次遍歷寫法 ⚙️

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -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/public_html (owner: site-a)
WordPress: /var/www/site-b/public_html (owner: site-b)
WordPress: /var/www/site-c/public_html (owner: site-c)

分支判斷邏輯：

• ⭕ 每個路徑都能通過 👉 代表可以建立獨立多站 Inventory
• 🟠 找到 wp-config.php 卻無法載入 WordPress 👉 先確認 PHP、檔案權限或網站路徑，不要直接更新
• 🟡 同一個網站被找到多個 wp-config.php 👉 先人工確認哪個才是 Production，避免誤更新備份或 Staging 副本

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

決策原理：wp site list 是 Multisite 專用指令，WP-CLI 官方文件明確將它定義為列出 Multisite installation 中的 Sites，因此不能拿來掃描一台 VPS 上互不相干的獨立多站 📔

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

if wp --path="$WP_PATH" core is-installed; then
    wp --path="$WP_PATH" site list \
        --fields=blog_id,url \
        --format=table
else
    echo "ERROR: WordPress installation not detected."
fi

預期輸出範例：

blog_id  url
1        https://example.com/
2        https://courses.example.com/
3        https://members.example.com/

分支判斷邏輯：能列出多個 Site 👉 進入 Multisite 流程；只能列出單一網站，並不代表一定是獨立多站，還要搭配前面「單一網站」段落的 MULTISITE 常數檢查結果一起判斷 🧭

^[57]

---

🔎 關卡二：先搞清楚「哪些站裝了 MemberDash、目前是哪一版」

目前已知公開資料把 1.8.5 以下列入受影響範圍，1.8.6 為官方修補版本。這一節不建議把版本號寫死在腳本裡，而是讓 WP-CLI 直接回報目前安裝的版本與可用更新版本這兩個欄位。特別提醒：若查無版本號（例如外掛檔案本身遭到破壞或移除），依照保守防禦原則，應直接假設該站處於受影響狀態，一併列入強制更新與後續排查清單，而不是略過不管 🔍

💠 單一網站：不要自己猜版本，讓 WP-CLI 回報

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

wp --path="$WP_PATH" plugin get "memberdash" \
    --fields=name,status,version,update,update_version

預期輸出範例：

name: memberdash
status: active
version: 1.8.5
update: available
update_version: 1.8.6

分支判斷邏輯：

• 🔴 1.8.5 或更舊 👉 視為受影響，進入後續備份／應急／修補流程
• 🟢 1.8.6 或更新 👉 此漏洞的版本條件已解除，但若網站曾經使用過舊版，仍應繼續往下做 Log 與後門排查
• 🟠 找不到 Plugin，或指令回傳空白 👉 依保守原則，直接假設此站受影響並列入強制排查清單，不要略過

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

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -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 "memberdash" \
        --field=version 2>/dev/null || true)"

    if [ -n "$version" ]; then
        printf 'Site: %s | Owner: %s | Version: %s\n' "$path" "$owner" "$version"
    else
        printf 'Site: %s | Owner: %s | Version: 【未安裝或無法取得，依保守原則列入待處理清單】\n' "$path" "$owner"
    fi
done

預期輸出範例：

Site: /var/www/site-a/public_html | Owner: site-a | Version: 1.8.6
Site: /var/www/site-b/public_html | Owner: site-b | Version: 1.8.5
Site: /var/www/site-c/public_html | Owner: site-c | Version: 1.8.0

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

🚨 注意：上面的 owner 是從檔案實際擁有者取得，而不是硬編碼 www-data。這對 HestiaCP、cPanel、DirectAdmin、多租戶 VPS 特別重要，因為不同網站可能由不同 Linux 使用者管理；所有路徑變數與檔名一律使用雙引號包覆，避免空格或特殊字元造成指令中斷 ⛓️‍💥

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

決策原理：Multisite 共用同一套 WordPress Plugin 檔案，因此不能把每個 Site 當成一個獨立 Plugin 安裝來反覆查詢版本，這樣只是在浪費查詢次數 🧩

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

wp --path="$WP_PATH" plugin get "memberdash" \
    --fields=name,status,version,update,update_version

wp --path="$WP_PATH" plugin is-active "memberdash" --network
echo "Network activated exit code: $?"

預期輸出範例：

name: memberdash
status: active
version: 1.8.5
update: available
update_version: 1.8.6

Network activated exit code: 0

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

---

📊 關卡三：Log 日誌不是看到 200 就慌，而是找「端點＋時間＋回應碼」的組合

決策原理：官方目前並未公開完整的攻擊 Payload 細節，我們只能依據漏洞成因（未驗證的註冊端點＋可被竄改的 id 參數）合理推論攻擊者可能鎖定的請求特徵。因此排查 Log 時，真正有價值的不是尋找某個「神奇 IP」，而是確認是否曾經出現對應端點、HTTP 方法與異常回應碼的組合，並把時間軸跟後面的帳號排查對齊 🎯

💠 單一網站／✴️ Multisite：先找得到 Log，再做關鍵字與時間範圍搜尋

決策原理：不同主機環境的 Access Log 路徑完全不同，因此不要把 /var/log/nginx/access.log 當成所有伺服器的固定答案，先確認檔案是否存在，找不到反而是重要訊號 🔦

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

if [ -f "$LOG_FILE" ]; then
    grep -E "wp-json/memberdash|/register" "$LOG_FILE" |
    tail -n 100
else
    echo "LOG NOT FOUND: $LOG_FILE"
fi

預期輸出範例：

LOG NOT FOUND: /var/log/nginx/access.log

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

... "POST /wp-json/memberdash/v1/register HTTP/1.1" 200 ...

分支判斷邏輯：

• 🟢 沒有異常密集的請求 👉 目前沒有直接證據顯示已被觸發，但仍建議繼續往下做後門檢查
• 🟡 出現對此端點的密集 POST，且伴隨大量不同的參數值 👉 提高事件優先級，接著比對同一時間附近的帳號異動紀錄
• 🔴 出現對此端點的 POST 且回應碼為 2xx／3xx，時間點恰好落在管理員反映「密碼失效」附近 👉 高度懷疑已被成功觸發，進入下方「已中招」流程

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

決策原理：不要只查其中一站，任何一站都可能是受影響對象，因此要用 NUL 分隔的方式安全掃過整個 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 "wp-json/memberdash|/register" "$log" 2>/dev/null || true)"

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

預期輸出範例：只會列出有命中的 Log 檔案，方便你把注意力集中在真的需要調查的站 🎯

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

🧑‍🔧 DevOps 小知識：與其用 awk 硬拆欄位，不如先確認你的 Log 格式
很多排查腳本會用 awk ‘{print $1}’ 這種方式硬拆 Log 欄位取出 IP、端點、狀態碼，但這種寫法非常依賴你的 Nginx／Apache Log Format 設定，換了一種 Log 格式就整組壞掉。比較穩健的做法是先用 nginx -T 或檢查 log_format 設定確認欄位順序，或直接改用結構化的 JSON Log，排查時就能用 jq 精準取值，不用賭欄位的位置 🔧

^[58]

---

🕳️ 關卡四：後門檢查不能只看外掛版本，帳號跟檔案都要翻

決策原理：這次漏洞的核心影響是「密碼遭竄改」與「帳號被接管」，因此首要檢查目標是資料庫裡的管理員清單，看看有沒有出現陌生的高權限帳號、或是原本的管理員帳號突然無法登入。其次，要檢查伺服器上有沒有偽裝成必要外掛的隱藏 mu-plugins 檔案，以及近期是否有異常修改的 PHP 檔案 🕵️

💠 單一網站：先查管理員清單，再查近期異動與隱藏外掛

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

# 1. 檢查所有管理員帳號與註冊時間
wp --path="$WP_PATH" user list \
    --role=administrator \
    --fields=ID,user_login,user_email,user_registered \
    --format=table

# 2. 檢查近期遭修改的 PHP 檔案（過去 3 天內）
find "$WP_PATH" -type f -name "*.php" -mtime -3 -ls

# 3. 檢查隱藏的 mu-plugins 目錄
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

預期輸出範例：

+----+-------------+---------------------+---------------------+
| ID | user_login  | user_email          | user_registered      |
+----+-------------+---------------------+---------------------+
| 1  | admin_real  | admin@example.com   | 2020-01-10 08:30:00  |
| 999| hacker_ninja| evil@hacker.com     | 2026-09-06 14:33:01  |
+----+-------------+---------------------+---------------------+

分支判斷邏輯：

• 🔴 出現不認識的 Administrator 帳號，或原本的管理員反映突然無法登入 👉 已確認中招，先不要動手清理，直接進入下方「已中招／疑似中招」流程保存證據
• 🟡 發現異常修改的 .php 檔案 👉 不要直接刪除，先用 mv 隔離保存以供後續鑑識，並記下檔案時間與權限
• 🟢 找不到可疑 mu-plugins 檔案、管理員清單也正常 👉 這一項沒有發現異常，但任何不認識的帳號仍值得進一步確認，「陌生」不等於「惡意」，可能是既有維運商帳號

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

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -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

    printf '\n===== 檢查網站: %s (owner: %s) =====\n' "$path" "$owner"

    sudo -u "$owner" -- wp --path="$path" user list \
        --role=administrator \
        --fields=ID,user_login,user_registered \
        --format=table

    find "$path" -type f -name "*.php" -mtime -3 -ls
done

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

✴️ Multisite：帳號要分 Network／Site 兩層看，mu-plugins 屬於 Network 只查一次

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

# Multisite 架構下，最高權限的角色是 Super Admin，必須額外檢查
wp --path="$WP_PATH" super-admin list

MU_PLUGINS="$WP_PATH/wp-content/mu-plugins"
if [ -d "$MU_PLUGINS" ]; then
    find "$MU_PLUGINS" -maxdepth 2 -type f -iname "*.php" -print
fi

wp --path="$WP_PATH" site list --field=url |
while IFS= read -r url; do
    printf '\n===== %s =====\n' "$url"
    wp --path="$WP_PATH" --url="$url" user list \
        --role=administrator \
        --fields=ID,user_login,user_registered \
        --format=table
done

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

---

🔧 關卡五：付費外掛沒辦法用官方 Checksum，該怎麼確認檔案沒被動過手腳

決策原理：這一關要先戳破一個常見的誤解——不是所有外掛都能用 wp plugin verify-checksums 驗證。這個指令的原理是拿你本機的檔案，去跟 WordPress.org 官方 SVN 提供的 checksum 資料庫比對，但 MemberDash 是一款透過 Nexcess／LearnDash 官方授權系統發佈的商業外掛，並沒有公開上架在 WordPress.org Repository 上，因此這個指令對它完全無效，會直接回傳「Plugin not found on WordPress.org」的警告，而不是「驗證通過」😵

🧑‍🔧 DevOps 小知識：商業外掛的完整性驗證，換一套邏輯來想
遇到沒有上架 WordPress.org 的商業外掛（不只 MemberDash，Avada、ACF Pro、WP Rocket 這類付費外掛都是同樣狀況），與其依賴原生的 verify-checksums 指令（本來就不是為它設計的），不如自己動手做 SHA256 雜湊值比對：先從官方管道（例如 Nexcess 客戶入口網站）下載一份「乾淨」的官方安裝包，跟你正在運行的檔案逐一比對雜湊值，只要有任何一個檔案對不起來，就代表它被動過手腳 🔐

💠 單一網站：拿官方安裝包，跟現況做逐檔比對

WP_PATH="/var/www/example.com/public_html"
PLUGIN_DIR="$WP_PATH/wp-content/plugins/memberdash"
REFERENCE_ZIP="$HOME/memberdash-1.8.6-official.zip"
REFERENCE_DIR="$(mktemp -d)"

# 先確認官方安裝包確實存在，避免比對到空目錄產生誤判
if [ ! -f "$REFERENCE_ZIP" ]; then
    echo "ERROR: 找不到官方安裝包，請先從 Nexcess 客戶入口網站下載 1.8.6 官方 ZIP：$REFERENCE_ZIP"
else
    unzip -q "$REFERENCE_ZIP" -d "$REFERENCE_DIR"
    diff -rq "$REFERENCE_DIR/memberdash" "$PLUGIN_DIR"
fi

預期輸出範例：

（沒有任何輸出，代表所有檔案內容完全一致）

分支判斷邏輯：

• 🟢 diff 沒有任何輸出 👉 目前運行的外掛檔案與官方版本一致，可信度高
• 🔴 diff 顯示有檔案內容不同，尤其出現原版沒有的新檔案 👉 不要忽略，代表檔案可能被植入額外程式碼，應立即進一步做入侵鑑識，先隔離保存再處理
• 🟡 官方安裝包一時無法取得 👉 至少先執行下方 WordPress Core 的 Checksum 驗證，並優先確認管理員帳號清單是否正常，作為過渡手段

WordPress Core 本體仍然是公開上架在 WordPress.org 的，因此 Core Checksum 驗證照樣有效，建議一併確認：

wp --path="$WP_PATH" core verify-checksums

# 若網站上還有其他一般（免費）外掛，這個指令對它們同樣有效
wp --path="$WP_PATH" plugin verify-checksums --all

❇️ 獨立多站：逐站比對，結果保留路徑方便追蹤

SEARCH_ROOT="/var/www"
REFERENCE_ZIP="$HOME/memberdash-1.8.6-official.zip"
REFERENCE_DIR="$(mktemp -d)"

if [ ! -f "$REFERENCE_ZIP" ]; then
    echo "ERROR: 找不到官方安裝包：$REFERENCE_ZIP"
else
    unzip -q "$REFERENCE_ZIP" -d "$REFERENCE_DIR"

    find "$SEARCH_ROOT" -type f -name "wp-config.php" -print0 |
    while IFS= read -r -d '' config; do
        path="$(dirname -- "$config")"
        plugin_dir="$path/wp-content/plugins/memberdash"

        if [ -d "$plugin_dir" ]; then
            printf '\n===== CHECKSUM: %s =====\n' "$path"
            diff -rq "$REFERENCE_DIR/memberdash" "$plugin_dir"
        fi
    done
fi

分支判斷邏輯：每個網站獨立判斷，不要拿 A 站的比對結果代替 B、C 站；任何一站出現差異，就先暫停該站的自動化排程，避免可疑檔案被排程覆寫掉，干擾後續鑑識 ⏸️

✴️ Multisite：Plugin 檔案共用，比對也只做一次

WP_PATH="/var/www/network/public_html"
PLUGIN_DIR="$WP_PATH/wp-content/plugins/memberdash"
REFERENCE_ZIP="$HOME/memberdash-1.8.6-official.zip"
REFERENCE_DIR="$(mktemp -d)"

if [ -f "$REFERENCE_ZIP" ]; then
    unzip -q "$REFERENCE_ZIP" -d "$REFERENCE_DIR"
    diff -rq "$REFERENCE_DIR/memberdash" "$PLUGIN_DIR"
fi

wp --path="$WP_PATH" core verify-checksums

分支判斷邏輯：Plugin 與 Core 檔案屬於同一個 WordPress installation，因此不需要對每個 Site URL 重複比對；驗證通過後，才進入下方「加固」與「密碼／Session 強制清空」兩項收尾動作 🧱

加固層面，建議同步強制刷新安全性鹽值「Salt」，把所有既有 Session（包含潛伏中的駭客）一次踢出：

# 💠 單一網站：
WP_PATH="/var/www/example.com/public_html"
wp --path="$WP_PATH" config shuffle-salts

# ❇️ 獨立多站：
SEARCH_ROOT="/var/www"
find "$SEARCH_ROOT" -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    owner="$(stat -c '%U' -- "$config")"
    sudo -u "$owner" -- wp --path="$path" config shuffle-salts
done

# ✴️ Multisite：所有子站共用同一個 wp-config.php，執行一次即可阻斷全網 Session
WP_PATH="/var/www/network/public_html"
wp --path="$WP_PATH" config shuffle-salts

🫂 新手求助：如果不熟悉 WP-CLI 或 SSH 操作，可以直接參考 WP-CLI 官方文件的 plugin verify-checksums、core verify-checksums 指令頁面，上面有完整的參數說明與範例，或請你的主機商客服協助執行這一節的排查指令 🤗

^[59]

---

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

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

🚨 A. 已中招／疑似中招：先止血、留證據，再談修補

決策原理：一旦第五節排查出現明確跡象（陌生管理員帳號、密碼異常失效、Log 出現對註冊端點的可疑成功請求），優先目標是「切斷攻擊鏈＋保留證據＋恢復掌控權」，而不是立刻更新外掛，更新只是後續步驟；最忌諱在沒有留下證據的情況下直接清理，反而把最有價值的鑑識線索一起刪掉 🧯

💠 單一網站：先建立事件證據，再止血

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

mkdir -p "$INCIDENT_DIR"

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

tar -czf "$INCIDENT_DIR/nginx-logs.tar.gz" "/var/log/nginx/"

echo "Incident evidence: $INCIDENT_DIR"

預期輸出範例：

Incident evidence: /home/admin/memberdash-incident-20260907_121500

分支判斷邏輯：證據已建立 👉 接續下方止血動作；如果是企業、電商或課程收費網站，同步通知內部資安或維運負責人，並保留這份 Incident Directory 到受保護的位置 📦

止血：立即停用外掛截斷攻擊入口、強制刷新 Salt 踢出所有 Session、重置合法管理員密碼、清除偽冒帳號：

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

# 1. 立即隔離：停用有風險的外掛
wp --path="$WP_PATH" plugin deactivate "memberdash"

# 2. 強制刷新 Salts，讓所有現有登入 Session（包含駭客的）瞬間失效
wp --path="$WP_PATH" config shuffle-salts

# 3. 重置你自己合法管理員帳號的密碼
wp --path="$WP_PATH" user reset-password "你的合法管理員帳號" --skip-email

# 4. 若確認 999 為駭客新建的偽冒帳號，刪除並將其發文歸戶給安全帳號（ID:1）
wp --path="$WP_PATH" user delete 999 --reassign=1 --yes

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

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

決策原理：獨立多站的最大優勢就是隔離性。某一站疑似遭入侵時，先確認受影響網站，再依主機架構進行站點級隔離，不要因為緊張就把整台 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)"
    sudo -u "$INCIDENT_OWNER" -- wp --path="$INCIDENT_PATH" plugin deactivate "memberdash"
    sudo -u "$INCIDENT_OWNER" -- wp --path="$INCIDENT_PATH" config shuffle-salts
else
    echo "ERROR: target is not a WordPress installation."
fi

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

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

決策原理：Multisite 共用核心、Plugin 與 mu-plugins 目錄，因此某個 Site 出現入侵跡象時，不能只處理那個 Site 就宣稱「完成」，必須把整個 Network 納入事件範圍 🌐

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

wp --path="$WP_PATH" plugin deactivate "memberdash" --network
wp --path="$WP_PATH" config shuffle-salts
wp --path="$WP_PATH" super-admin list

分支判斷邏輯：任一 Site 出現明確入侵跡象 👉 對整個 Network 執行證據保存、外掛停用與鹽值「Salt」刷新；接著再逐一檢查各 Site 的管理員帳號是否有異常，不要遺漏權限層級較低但仍具備發文能力的帳號 🔍

---

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

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

💠 單一網站：不開放公開註冊的話，優先直接停用

決策原理：如果網站目前並不需要開放公開會員註冊，而正式更新必須等維護窗口，停用受影響外掛通常比讓它持續暴露在公網更容易控制，而且可以百分之百截斷這條攻擊路徑 💪

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

wp --path="$WP_PATH" plugin deactivate "memberdash"

預期輸出範例：

Plugin 'memberdash' deactivated.
Success: Deactivated 1 of 1 plugins.

分支判斷邏輯：

• 🟢 可以安全停用 👉 保留停用狀態，盡快排入「C. 正式修補」窗口
• 🟠 網站核心流程依賴公開註冊（例如正在招生的線上課程） 👉 不要在 Production 直接停用，改採下方伺服器層防護規則，並儘速安排升級

伺服器層防護規則（Nginx 範例，套用前請先在 Staging 驗證）：

location ~* "/wp-json/memberdash/v1/register" {
    deny all;
    return 403;
}

📂 記得替換下方的目錄為真實網站目錄：/var/www/
👥 記得替換下方的使用者為真實使用者：www-data:www-data

❇️ 獨立多站：逐站應急，不要一次停掉整台 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 "memberdash"

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

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

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

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

分支判斷邏輯：如果是 Network Activated，停用時要把整個 Network 視為影響範圍；如果只是部分 Site 各自啟用，才適合用 –url=”$url” 針對個別 Site 停用 🔀

✅ 為什麼停用就能擋？
整條攻擊鏈完全依賴「公開註冊端點」才能觸發，停用外掛能百分之百截斷這個入口，是目前最乾淨、風險最低的短期緩解手段，但不能取代正式升級 🏎️

---

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

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

以下流程同時涵蓋單一網站、獨立多站、Multisite 三種環境，每一階段都必須完成才能進入下一階段，正式環境升級外掛前，務必先於測試環境備份並驗證，避免網站崩潰 🧪

① 判斷環境（再次確認）

回到「關卡一：環境判斷」重新執行判斷，確認自己屬於哪一種架構後再繼續，不要在還沒確認架構前就執行下面任何批次指令。

② 盤點（Inventory）

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

③ 備份（Backup）

決策原理：外掛更新主要改的是 Plugin 檔案，但網站內容、設定與媒體檔案仍可能需要回復，因此至少要有資料庫備份，並依既有維運政策保留必要檔案，備份檔案統一集中放在 $HOME/wp-security-backup。這裡要特別提醒一個常見的手滑陷阱：路徑字串如果寫成 “~/wp-security-backup”（把波浪符號包在雙引號裡），Bash 並不會把它展開成家目錄，而是會照字面在目前所在資料夾底下建立一個名字真的叫做 ~ 的資料夾，備份檔案就這樣悄悄消失在錯誤的地方——正確寫法是用 $HOME 這個環境變數，它在雙引號裡一樣能正常展開 💾

💠 單一網站：

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_memberdash_update_${STAMP}.sql"

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

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

預期輸出範例：

Success: Exported to '/home/admin/wp-security-backup/example-com_pre_memberdash_update_20260907_123000.sql'.
Backup completed:
/home/admin/wp-security-backup

分支判斷邏輯：SQL 與檔案備份都存在 👉 進 Dry-run；任一備份失敗 👉 停止，不進入正式更新，先排除磁碟空間或權限問題 🛑

🧑‍🔧 DevOps 小知識：獨立多站備份最容易踩到的權限地雷
獨立多站環境下，如果直接用 sudo -u “$SITE_OWNER” wp db export “$BACKUP_ROOT/xxx.sql”，很可能會噴出 Permission denied——因為集中備份目錄 $HOME/wp-security-backup 通常屬於執行腳本的管理帳號，個別網站的 Linux 使用者根本沒有寫入權限。解法是讓 wp db export – 把內容輸出到標準輸出（– 就是代表「印到終端機」的意思），再由外層真正擁有備份目錄寫入權限的帳號負責重導向存檔，權限問題就自然消失，不用額外做一堆 chmod／chown 補丁 🔧

❇️ 獨立多站：每一個 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" -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}_db_pre_memberdash_update_${STAMP}.sql"
    files_archive="$BACKUP_ROOT/${site_name}_wp-content_pre_memberdash_update_${STAMP}.tar.gz"

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

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

    # 以 site owner 身分匯出到標準輸出，再由目前使用者（有 BACKUP_ROOT 寫入權限）重導向存檔
    sudo -u "$owner" -- wp --path="$path" db export - > "$db_file"

    # tar 只需要讀取來源檔案的權限，用目前使用者（通常是 root）執行即可，不需要再切換 owner
    sudo tar -czf "$files_archive" -C "$path" "wp-content"

    printf 'Database backup: %s\nFiles backup: %s\n' "$db_file" "$files_archive"
done

預期輸出範例：

Database backup: /home/admin/wp-security-backup/site-a_db_pre_memberdash_update_20260907_124000.sql
Files backup: /home/admin/wp-security-backup/site-a_wp-content_pre_memberdash_update_20260907_124000.tar.gz

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

✴️ 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/multisite_pre_memberdash_update_${STAMP}.sql"

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

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

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

決策原理：WP-CLI 官方的 wp plugin update 原生支援 –dry-run，用途就是預覽哪些 Plugin 會被更新，而不真正執行更新，這是進入正式更新前最後一道確認 🧪

💠 單一網站：

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

wp --path="$WP_PATH" plugin update \
    "memberdash" \
    --dry-run

預期輸出範例：

Plugin memberdash 1.8.5 will be updated to 1.8.6.

分支判斷邏輯：

• ⭕ 顯示目標版本 👉 可以正式更新
• 🟠 顯示 No updates available，但版本明明還是舊的 👉 這通常代表 MemberDash／LearnDash 的授權（License）已過期或尚未在這台主機上啟用，系統連不上官方更新伺服器。此時必須手動登入 Nexcess 客戶入口網站下載 1.8.6 以上的 .zip 檔，並使用 wp plugin install “/path/to/memberdash.zip” –force –path=”$WP_PATH” 進行強制覆蓋安裝

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

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -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 "memberdash" \
        --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 \
            "memberdash" \
            --dry-run
    fi
done

分支判斷邏輯：先確認每站 Dry-run 結果都合理，再進正式更新；建議仍採「一站完成 👉 驗證 👉 下一站」的節奏，不要一次對所有站下手 🚶

✴️ Multisite：Plugin 檔案只 Dry-run 一次

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

wp --path="$WP_PATH" plugin update \
    "memberdash" \
    --dry-run

分支判斷邏輯：不要因為 Network 裡有 10 個 Site 就執行 10 次 Dry-run，Plugin 檔案屬於同一個 WordPress installation，一次結果即可代表整個 Network 🧩

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

決策原理：標準且安全的更新流程應遵循「停用 👉 更新 👉 啟用」，避免更新過程中因為常駐記憶體的舊函式引發 Fatal Error 導致白畫面。對於獨立多站環境，嚴禁寫成一個巨大迴圈一次跑完，必須逐站處理 🎛️

💠 單一網站：

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

wp --path="$WP_PATH" plugin deactivate "memberdash"
wp --path="$WP_PATH" plugin update "memberdash"
wp --path="$WP_PATH" plugin activate "memberdash"

預期輸出範例：

Enabling Maintenance mode...
Downloading update...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
Disabling Maintenance mode...
Success: Updated 1 of 1 plugins.

分支判斷邏輯：更新成功 👉 立即進版本驗證；更新失敗 👉 不要反覆執行，先查看錯誤訊息、確認檔案權限、磁碟空間或授權狀態是否正常 ⚠️

❇️ 獨立多站：一站一個完整閉環，嚴禁大迴圈盲目批次推送

# ❌ 危險做法：直接寫一個大迴圈一次跑完 10 個站。萬一 1.8.6 導致伺服器相容性錯誤，將瞬間搞掛 10 個客戶的網站。
# ✅ 正確做法：逐站完成「備份 👉 更新 👉 驗證」，確認沒事後，再進行下一站。
# 以下示範單站安全更新邏輯，請手動依序代入 SITE_PATH 變數

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

sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin deactivate "memberdash"
sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin update "memberdash"
sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin activate "memberdash"

sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin get "memberdash" \
    --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 deactivate "memberdash" --network
wp --path="$WP_PATH" plugin update "memberdash"
wp --path="$WP_PATH" plugin activate "memberdash" --network

wp --path="$WP_PATH" plugin get "memberdash" \
    --fields=name,status,version,update,update_version

更新後再逐一檢查 Network 中的 Site 是否能正常載入外掛：

wp --path="$WP_PATH" site list --field=url |
while IFS= read -r url; do
    printf '\n===== %s =====\n' "$url"

    wp --path="$WP_PATH" --url="$url" plugin get "memberdash" \
        --fields=name,status,version
done

分支判斷邏輯：Plugin 檔案版本只需要更新一次；Site 層則逐一確認是否正常載入與啟用，任一 Site 出現錯誤 👉 暫停批次流程，先處理該 Site，不要繼續擴大變更範圍 🛑

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

正式更新後至少完成以下四層驗證，三種環境的差異主要在「一次執行」與「逐站執行」，驗證項目本身相同。

① 版本驗證

wp --path="$WP_PATH" plugin get "memberdash" \
    --fields=name,status,version,update,update_version

② 商業外掛的完整性驗證（改用 SHA256 比對，而非 verify-checksums）

PLUGIN_DIR="$WP_PATH/wp-content/plugins/memberdash"
REFERENCE_ZIP="$HOME/memberdash-1.8.6-official.zip"
REFERENCE_DIR="$(mktemp -d)"

unzip -q "$REFERENCE_ZIP" -d "$REFERENCE_DIR"
diff -rq "$REFERENCE_DIR/memberdash" "$PLUGIN_DIR"

③ WordPress Core Checksum（若曾疑似入侵，建議一併執行）

wp --path="$WP_PATH" core verify-checksums

④ 前台／後台功能與最後一輪 Log／mu-plugins 複查

• ☑️ 前台首頁可以正常開啟
• ☑️ 後台可以正常登入
• ☑️ 開啟瀏覽器無痕視窗，測試「新會員註冊」流程能正常運作，且沒有伺服器 500 報錯
• ☑️ MemberDash 設定頁面載入正常，無白畫面（WSOD）或樣式跑版
• ☑️ PHP error log 沒有突然出現大量 Fatal Error
• ☑️ 管理員清單與 mu-plugins 目錄再複查一次，確認沒有殘留的可疑帳號或檔案

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

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

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

分支判斷邏輯：更新後仍發現不認識的管理員帳號，或 mu-plugins 出現新的可疑檔案 👉 不要把它當成「已修好所以沒事」，應回到「A. 已中招」流程重新處理，而不是單純重新更新一次外掛就結案 🔁

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

^[60]

---

📋 三種架構的排查與修補速查表

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

---

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

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

• 🏮 Q：按了更新，網站的課程或會員資料會不會不見？
  A：MemberDash 這次的更新主要是加強表單驗證邏輯，並沒有變動資料庫結構，單純更新讓會員資料消失的機率微乎其微。但保險起見，動手前先備份資料庫絕對是不變的真理喔 💾
• 🏮 Q：外包廠商說「我們已經改用 LearnDash 內建功能了，MemberDash 不用管」，我該聽他的嗎？
  A：千萬別信這句話！漏洞最狡猾的地方在於「只要外掛還啟用著」，就算你已經不靠它運作，駭客一樣能找上這扇還開著的門。請堅定地要求廠商協助升級或直接停用 💣

---

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

🔥 這起事件其實給了所有網站主一個提醒：有時候漏洞的可怕之處，不是它多難懂的程式碼，而是它藏在一個「看起來理所當然」的功能背後——誰會想到，一個開放給陌生人使用的註冊表單，居然能被拿來改掉整個網站老闆的密碼？與其等哪天發現自己登不進後台才驚覺不對勁，不如現在就花五分鐘，打開後台看一眼版本號碼 🔢

^[61]

---

📚 參考資料與延伸資源

• 📌 NVD CVE-2026-16310 官方詳情頁 ^[62]
• 📌 IONIX Threat Center 漏洞情資頁 ^[63]
• 📌 Wordfence 漏洞情報頁 ^[64]
• 📌 Nexcess 官方 MemberDash 1.8.6 更新日誌 ^[1]
• 📌 WP-CLI 官方文件：plugin verify-checksums ^[65]
• 📌 WordPress Multisite 常數設定參考 ^[66]