你的房仲網站大廳，可能正把「主委萬能磁扣」發給路人：MyHome Core 高危漏洞全解析（CVE-2026-15980／CVSS 9.8）

🔥 懶人包：
專為房地產與房仲業設計的 WordPress 核心外掛 MyHome Core（開發商 TangibleWP）被爆出嚴重漏洞 CVE-2026-15980，CVSS 評分高達 9.8（近乎滿分）。問題出在負責寄送驗證信與啟用帳號的兩支程式碼完全不檢查身分，攻擊者不需要密碼、不需要登入、甚至不用誘騙任何人點擊連結，就能「合法」向系統要到一張管理員的登入通行證。目前尚未有大規模自動化攻擊的確切報告，但資安機構評估「12 小時內即可武器化」，強烈建議所有 MyHome Core 使用者立即更新至 4.4.6 以上版本 ⛑️

🌐 前往 Wordfence 官方安全公告確認細節 ^[1]

^[2]

🧐 這個漏洞到底在幹嘛？先用一個生活化比喻搞懂

先別急著看落落長的技術名詞，我們把您的房地產網站想像成一棟控管嚴格的高級公寓，而 MyHome Core 這個外掛，就是大廳裡負責「新住戶報到」的整套自動化設備 🏢

正常的報到流程應該是這樣：新住戶（新註冊會員）要先出示身分證明，大廳管理員確認無誤後，才會讓「自動發卡機」（也就是漏洞所在的 send_link() 函數）發放一組臨時通行碼；接著住戶拿著這組通行碼，走到旁邊的「驗證兌換機」（activate() 函數），兌換成一張正式的「住戶專屬磁扣」，也就是您登入後台時瀏覽器裡那組 wordpress_logged_in_* 認證 Cookie ✅

但這套系統設計出現了致命盲點：發卡機完全不檢查來者的身分。任何一個路過大廳的陌生人，只要走向機器，開口說「請幫我發一組『某某住戶（甚至是公寓管理委員會主委）』的臨時通行碼」，機器就會毫無防備地照做，直接在系統資料庫裡生成一組合法有效的代碼。攻擊者只要把這組代碼拿去驗證兌換機報到，就能換得一張暢通無阻的主委萬能磁扣，直接繞過所有登入畫面，瞬間化身為您網站的最高權限管理員 🙅‍♂️

📖 事情的來龍去脈：一場資安機構之間的接力賽

這起事件的發展過程，完整呈現了現代 WordPress 生態系裡「第三方外掛安全性」如何牽動全站風險的典型劇本 🎬

💡 碎碎念：「還沒被大規模攻擊」不代表可以放心慢慢處理
根據 IONIX 與 Wordfence 的監測數據，✅ 已確認漏洞公開的最初幾天內，尚未出現大規模自動化攻擊（Mass Exploitation）的確切報告。但 🟡 合理推論是，資安情報平台 IONIX 特別強調自身具備「12 小時內將此類 CVE 轉化為曝險驗證」的能力，這意味著攻擊者社群極可能也已掌握概念性驗證（PoC）的實作方式，隨時可能對未修補的房地產網站展開無差別掃描。這就像颱風警報已經發布、但風雨還沒真正登陸——不是「還沒事」，而是「隨時要來」⏰

⚠️ 對我的網站有什麼實質影響？

此漏洞被評定為 🔴 嚴重（CVSS 9.8），因為攻擊者完全不需要登入、不需要任何預先取得的權限或角色，任何一個網路上的陌生人都能發動攻擊 ⚠️

攻擊者可能取得什麼能力？只要您的網站上，存在一個「尚未完成 Email 驗證」的帳號（尤其是高權限的管理員帳號），攻擊者就能強制系統派發驗證權杖，並直接取得該帳號完整的登入狀態 Cookie，一旦拿到管理員 Cookie，等於同時拿到後台的萬能鑰匙 🔑

• 🏮 ✅ 已確認事實：未經授權的遠端攻擊者能成功登入為系統管理員，完全繞過所有常規的密碼與雙重認證（2FA）機制，取得網站最高控制權
• 🏮 🟡 合理推論：取得管理員權限後，攻擊者可任意竄改房屋物件的價格與聯絡資訊、竊取買賣雙方的客戶名單與經紀人個資、植入惡意博弈或色情廣告（SEO Spam），甚至暗中安裝含後門程式的惡意外掛，讓房地產網站淪為發送釣魚郵件的跳板，嚴重損害商譽並引發個資法規裁罰風險
• 🏮 🔴 假設情境：若伺服器底層權限控管不佳（例如網頁服務與主機系統權限未適當隔離），攻擊者可能進一步利用管理員的檔案上傳能力（如上傳惡意佈景主題或修改核心檔案），在伺服器上植入 Web Shell，導致同一台主機上其他代管網站遭到橫向波及

🚨 畫重點！千萬別踩雷：這個漏洞的殺傷力不是「駭客技術高超」，而是「系統本身太老實」——只要攻擊者知道怎麼問，系統就會乖乖把鑰匙交出去。更新外掛只能阻止未來的攻擊，如果您在更新前就已經被盯上，光是更新版本並不夠，後面的檢查清單章節會教您怎麼確認有沒有已經中招 🙅‍♂️

🎭 四種情境對應：您的網站到底該怎麼辦？

🙋 一般網站管理者（房仲小型網站、個人物件展示站）

您不需要看懂任何程式碼，只要做兩件事：登入後台確認 MyHome Core 版本，以及檢查佈景主題是否還在 Legacy/WPBakery 模式下運行。這決定了您到底有沒有暴露在風險裡 🌠

適合行動：高優先，免不免費？完全免費，只需要幾分鐘。登入 WordPress 後台「外掛」→「已安裝的外掛」，找到 MyHome Core 確認版本號是否 ≤ 4.4.5，若是，立即點擊「立即更新」升級至 4.4.6 以上 👍

👨‍💻 獨立開發者／代管商（DevOps／自架玩家）

如果您手上管理多個房仲客戶的 WordPress 網站，光靠手動點擊後台更新效率太低。建議透過 WP-CLI 批次檢查所有站台的外掛版本，並在 WAF 層級預先部署阻擋規則，作為修補前的緩衝防線 🔧

適合行動：中高優先。部署複雜度不高——這是一次單純的外掛版本更新，不涉及資料庫結構變更，跟現有技術棧完全相容。請直接看後段「技術深潛篇」的排查指令與應急防護規則 ⚙️

🏢 企業商業用途（房仲公司、代銷業者）

若您的網站是公司對外的房源展示與會員登入入口，這起漏洞不只是資安問題，更直接牽涉買賣雙方的個資保護責任。一旦客戶名單與聯絡資訊外洩被證實，企業面臨的可能不只是商譽受損，還有個資法規（如 GDPR，若涉及海外客戶）裁罰 🚫

適合行動：極高優先，且需留存證據。除了更新與安全設定，建議同步啟動內部資安事件應變流程，備份現有日誌以供後續調查與法遵佐證。授權條款、SLA 與維護成本方面，由於 MyHome Core 經常綁定在 ThemeForest 的付費佈景主題包中，若佈景主題授權已過期，官方更新提示可能不會自動出現，這點企業採購時務必留意 ⚠️

🚨 高風險誤用場景：您以為跟自己無關，其實正好中招

⛔️ 這類「因為相容性考量而長期停留在舊版編輯模式」的網站，反而是最容易誤判自己「應該沒事」的高風險族群，請務必優先確認佈景主題目前運行的模式 🙅‍♂️

^[27]

🔍 技術深潛篇：CVE 底層原理拆解（給 DevOps 看）

在系統架構層面，這是一個典型且致命的存取控制與邏輯驗證缺陷，反映開發者在處理非同步請求時，對邊界防護的疏忽 📊

🧑‍🔧 DevOps 小知識：CVSS 向量到底在講什麼？
AV:N（Attack Vector: Network）代表攻擊者可透過網際網路直接觸發，完全不需要碰到本地網路；AC:L（Attack Complexity: Low）代表攻擊步驟固定，只需發送兩個標準的 HTTP POST 請求，不依賴特殊時間條件或繞過底層系統防護；PR:N（Privileges Required: None）與 UI:N（User Interaction: None）合起來代表這不是需要誘騙管理員點擊連結的釣魚型攻擊（不是 XSS 型態），而是攻擊者可以完全獨立、單方面發動的兩段式 API 濫用（Two-Stage API Abuse）。S:U/C:H/I:H/A:H 則代表機密性、完整性、可用性三方面全部遭受高度衝擊 🗡

🎯 觸發此漏洞的三個必要條件（缺一不可）

要成功利用此漏洞，目標環境必須嚴格滿足以下三個設定前提的交集：

🎯 攻擊鏈路：從偵察到完全接管只要四步

🧑‍🔧 DevOps 小知識：問題出在哪一行邏輯？
根本原因出在兩支函數的組合缺陷：send_link() 完全沒有校驗發起請求者的身分與權限，也缺乏 Nonce 驗證，導致任何未經驗證的訪客都能透過 wp_ajax_nopriv_ 綁定的動作，替任何一個尚未確認的帳號生成有效驗證權杖；activate() 則因為攻擊者是「透過系統本身合法寫入」的權杖，會誤判這是合法請求，並未進一步將「請求發起者」與「權杖擁有者」做密碼學上的綁定，直接呼叫 WordPress 核心的 wp_set_auth_cookie() 派發認證 Cookie，導致完整的帳號接管。

🟡 合理推論（Probable Escalation）：一旦取得管理員權限，攻擊者可以利用 WordPress 後台其他外掛或佈景主題中僅限管理員觸發的漏洞（如已驗證的 RCE 或 SQLi）進一步加深控制力道，或匯出 wp_users 資料表竊取大量買賣雙方 PII，並植入隱蔽的 JavaScript 進行 SEO 流量劫持 ⚠️

🔴 假設情境（Worst-Case）：若 DevOps 團隊沒有落實最小權限原則，例如 PHP-FPM 以 root 身分執行、未配置 open_basedir 限制，攻擊者上傳 Web Shell 後可能進一步執行本地權限提升攻擊，導致主機被植入挖礦程式或勒索軟體，甚至波及同一虛擬機上的其他容器或服務 🚫

✅ 資安排查與自我檢查 Checklist

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

面對已公開的漏洞細節，系統管理員應假設系統可能已遭探測，必須立即執行版本比對與日誌排查。以下每一個排查動作，都會依「決策原理 → 具體指令 → 預期輸出範例 → 分支判斷邏輯」四個步驟拆解，同時涵蓋💠單一網站／❇️獨立多站（多個 wp-config.php）／✴️Multisite三種常見部署場景，請依自己的環境對號入座 🧑‍💻

💡 碎碎念：為什麼要先花時間分辨「環境」？
因為同一句「更新外掛」，在單站可能只是點一下按鈕，但在代管 50 個房仲客戶站台的獨立多站環境，或是一套主網域底下掛了 20 個分站的 Multisite，執行方式、風險範圍與回滾策略完全不同。跳過這一步直接套指令，很容易發生「以為修好了，其實只更新了其中一個分站」的悲劇 🧯

㊀ 判斷你的環境屬於哪一種戰場

【決策原理】後續所有指令都需要知道「這是不是 Multisite」以及「WP-CLI 執行時該用哪個路徑或網址參數」，所以第一步永遠是先確認地形，而不是急著跑修補指令。

# 確認目前這個路徑是不是一個合法的 WordPress 安裝
wp core version --path="/var/www/example-site"

# 確認這個安裝是否啟用了 WordPress 內建的 Multisite 網路功能
wp config is-true MULTISITE --path="/var/www/example-site"
echo "MULTISITE 判斷結果（0=是Multisite／1=不是）：$?"

【預期輸出範例】若為單站或獨立多站中的其中一站，wp core version 會直接印出版本號（例如 6.7.1），且 is-true MULTISITE 指令結束後 $? 會回傳 1；若是 Multisite 網路，$? 會回傳 0。

【分支判斷邏輯】

• 🏮 若指令直接報錯「找不到 wp-config.php」→ 代表這個目錄不是 WordPress 根目錄，請先用 find / -maxdepth 4 -iname “wp-config.php” 2>/dev/null 定位正確路徑
• 🏮 若 $? 為 1 且伺服器上還有其他獨立的 WordPress 目錄（例如 /var/www/sites/ 底下一堆各自獨立的資料夾）→ 判定為「獨立多站」，後續指令需要迴圈跑過每一個 –path
• 🏮 若 $? 為 0 → 判定為「Multisite」，後續指令改用 –url 搭配 wp site list 逐一掃過各分站，而不是切換路徑

㊁ 盤點：三種戰場的版本比對指令

【決策原理】版本號是所有後續動作的起點——低於 4.4.6 就必須進入應急或修補流程，已經 ≥ 4.4.6 則只需要走「加固檢查」確認沒有殘留風險即可，兩條路徑不能混著跑。

▍情境一：💠單一網站

wp plugin get myhome-core --path="/var/www/example-site" --allow-root

【預期輸出範例】

+----------------+---------------+
| Field          | Value         |
+----------------+---------------+
| name           | myhome-core   |
| title          | MyHome Core   |
| version        | 4.4.5         |
| author         | TangibleWP    |
| status         | active        |
+----------------+---------------+

▍情境二：❇️獨立多站（多個各自獨立安裝，批次盤點）

#!/usr/bin/env bash
# 批次盤點：掃描 SITES_ROOT 底下每一個獨立 WordPress 安裝的 MyHome Core 版本
SITES_ROOT="/var/www/sites"
REPORT_FILE="/var/log/myhome-core-audit-$(date +%Y%m%d-%H%M%S).csv"

echo "site_path,version,status" > "$REPORT_FILE"

for site_path in "$SITES_ROOT"/*/; do
  site_path="${site_path%/}"
  if [ -f "$site_path/wp-load.php" ]; then
    version=$(wp plugin get myhome-core --field=version --path="$site_path" --allow-root 2>/dev/null)
    status=$(wp plugin get myhome-core --field=status --path="$site_path" --allow-root 2>/dev/null)
    if [ -n "$version" ]; then
      echo "\"$site_path\",\"$version\",\"$status\"" >> "$REPORT_FILE"
    fi
  fi
done

echo "盤點完成，報表已輸出至：$REPORT_FILE"

▍情境三：WordPress Multisite（跑過所有分站網域）

#!/usr/bin/env bash
# Multisite 環境：外掛檔案通常共用同一份，但啟用狀態需逐分站確認
NETWORK_PATH="/var/www/multisite-network"

echo "── 檔案層級版本（整個網路共用一份程式碼） ──"
wp plugin get myhome-core --field=version --path="$NETWORK_PATH" --allow-root

echo "── 各分站啟用狀態 ──"
wp site list --field=url --path="$NETWORK_PATH" --allow-root | while IFS= read -r site_url; do
  active=$(wp plugin list --url="$site_url" --path="$NETWORK_PATH" --field=name --status=active --allow-root 2>/dev/null | grep -x "myhome-core")
  if [ -n "$active" ]; then
    echo "分站 $site_url：MyHome Core 為啟用中"
  fi
done

【分支判斷邏輯】

• 🏮 版本 ≤ 4.4.5 → 立即跳到本文「Section 4」的應急與修補流程
• 🏮 版本 ≥ 4.4.6 但從未執行過事件應變（沒有輪替過 AUTH_SALT、沒有強制登出）→ 仍建議走一次「加固檢查」，因為更新只能防止未來攻擊，無法讓更新前已外流的 Cookie 失效
• 🏮 獨立多站報表中若出現空白 version 欄位 → 代表該目錄可能是備份殘留、非啟用中安裝，或 –allow-root 權限不足，需人工複查而非直接略過

🧑‍🔧 DevOps 小知識：關於雙引號的小堅持
上面所有腳本裡的路徑、網址變數，全部都用雙引號 “$site_path” 包起來，這不是排版潔癖——如果哪個客戶的網站目錄剛好叫 /var/www/sites/信義區店 A/，沒加雙引號的話，Bash 會把它拆成好幾個獨立參數，指令直接爆掉或誤判路徑。這種坑在批次跑幾十個站台時特別容易踩到 🔑

㊂ Log 日誌排查特徵（含指令）

【決策原理】由於此漏洞不需要登入，攻擊者的行為只會留在 Web Server 的存取日誌（Access Log）與 WordPress 自身的資料庫，而不會出現在一般的登入失敗記錄裡，所以排查重點要放在 admin-ajax.php 的請求特徵，而不是傳統的暴力破解特徵 👊

【具體指令】💠單一網站／❇️獨立多站可直接對該站的 Nginx／Apache 存取日誌下手；Multisite 因為所有分站通常共用同一份主網域日誌，需要額外用網域欄位篩選出目標分站。

# 情境一／二（💠單一網站／❇️獨立多站，逐站執行）：
# 篩選出過去 7 天內針對 send_link / activate 這兩個 action 的可疑請求
LOG_FILE="/var/log/nginx/example-site.access.log"
grep -E "admin-ajax\.php" "$LOG_FILE" \
  | grep -E "action=(send_link|activate)" \
  | awk '{print $1, $4, $7}' \
  | sort | uniq -c | sort -rn > "/tmp/myhome-core-suspect-requests.txt"

echo "已輸出可疑請求彙整表：/tmp/myhome-core-suspect-requests.txt"

# 情境三（Multisite，先用分站網域篩選，再套用相同邏輯）：
SITE_DOMAIN="sub-a.example.com"
grep -E "^${SITE_DOMAIN}" "/var/log/nginx/network-access.log" \
  | grep -E "admin-ajax\.php" \
  | grep -E "action=(send_link|activate)"

【預期輸出範例】若日誌乾淨，指令執行完 /tmp/myhome-core-suspect-requests.txt 檔案會是空的，或僅有少量、來自你自己辦公室固定 IP 的正常前台註冊流量；若不乾淨，會看到類似下面這種、短時間內大量重複、來源 IP 分散或屬於雲端主機商網段的請求堆疊 🪥

【分支判斷邏輯】

• 🏮 檔案為空或只有零星幾筆、且都對應到已知的正常訪客行為 → 判定為「暫無明確跡象」，繼續走「短期應急＋正式修補」即可，不需要啟動事件應變
• 🏮 出現同一 IP 短時間內先打 action=send_link 再打 action=activate 的成對請求 → 判定為「疑似中招」，直接跳到本文「Section 4-A」的事件應變流程，不要只做應急防護
• 🏮 日誌檔案本身在 2026-08-29 前後區間缺漏（例如被清空或輪替設定異常縮短保留天數）→ 這本身就是高度可疑訊號，應直接視同疑似中招處理

💡 碎碎念：基於資安倫理，本文不提供可直接用於攻擊的完整 Request、Payload 或 Exploit 程式碼，上述僅為防禦排查用的特徵描述與比對指令。

㊃ 後門檢查點（含指令與現場虛擬修補技巧）

【決策原理】若懷疑網站已遭利用，必須先確認攻擊者沒有留下能「繞過這次更新」的持續性後門，否則就算把 MyHome Core 升級到 4.4.6，攻擊者依然可能用備用管理員帳號或後門檔案再次進來。

• 🏮 異常新增管理員帳號：檢查 wp_users 與 wp_usermeta 資料表，確認是否出現不在編制內的 Administrator 帳號，或現有帳號的 Email 被竄改
• 🏮 不明 WordPress 使用者：排查近期是否有異常大量或名稱為隨機字串的註冊帳號
• 🏮 不明 PHP 檔案：嚴格檢查 wp-content/uploads/ 目錄，正常應僅有媒體檔，若出現任何 .php 檔案即代表已遭入侵
• 🏮 檔案修改異常：檢查近期被修改的核心程式碼或佈景主題檔案
• 🏮 資料庫異常內容：檢查 wp_options 資料表的 active_plugins 欄位是否有未知的隱藏外掛被啟用，同時檢查 wp_posts 是否被大量插入垃圾連結
• 🏮 可疑排程工作：檢查 WordPress Cron Job 是否有發送異常請求或定時執行惡意腳本的排程

# ── 情境一／二：💠單一網站／❇️獨立多站，逐一 --path 執行 ──
SITE_PATH="/var/www/example-site"

echo "1) 近 14 天內被修改過的 PHP 檔案："
find "$SITE_PATH/wp-content" -type f -name "*.php" -mtime -14 -printf "%T@ %p\n" | sort -n

echo "2) uploads 目錄下不該存在的 PHP 檔案："
find "$SITE_PATH/wp-content/uploads" -type f -iname "*.php"

echo "3) 目前所有 Administrator 帳號："
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered \
  --path="$SITE_PATH" --allow-root

echo "4) 目前啟用中的外掛清單（比對是否有陌生外掛）："
wp option get active_plugins --path="$SITE_PATH" --allow-root --format=json

echo "5) 目前所有排程工作："
wp cron event list --path="$SITE_PATH" --allow-root

# ── 情境三：Multisite，額外針對每個分站跑一次帳號與外掛檢查 ──
NETWORK_PATH="/var/www/multisite-network"
wp site list --field=url --path="$NETWORK_PATH" --allow-root | while IFS= read -r site_url; do
  echo "── 分站：$site_url ──"
  wp user list --role=administrator --fields=ID,user_login,user_email \
    --url="$site_url" --path="$NETWORK_PATH" --allow-root
done

【預期輸出範例】find 指令若乾淨，只會列出你近期自己手動編輯過、有印象的檔案；wp user list –role=administrator 的結果應該剛好等於你團隊實際擁有的管理員人數，一個都不多。

【分支判斷邏輯】

• 🏮 Administrator 清單裡出現你認不出來的帳號、或帳號建立時間剛好落在可疑日誌時間範圍內 → 判定為「已中招」，直接跳到「Section 4-A」，先保留證據再處理，切勿直接刪除帳號
• 🏮 uploads 目錄出現任何 .php 檔案 → 判定為「已中招」，這是最明確的入侵指標之一
• 🏮 全部乾淨 → 可放心走「Section 4-C」的正式修補流程

# 反查目前掛在 wp_ajax_nopriv_send_link / wp_ajax_nopriv_activate 上的實際函式
wp eval '
global $wp_filter;
$hooks = array("wp_ajax_nopriv_send_link", "wp_ajax_nopriv_activate");
foreach ($hooks as $hook) {
    echo "── Hook: $hook ──\n";
    if (empty($wp_filter[$hook])) {
        echo "（尚未註冊任何回呼，或該功能目前未啟用）\n";
        continue;
    }
    foreach ($wp_filter[$hook]->callbacks as $priority => $callbacks) {
        foreach ($callbacks as $cb) {
            $fn = $cb["function"];
            if (is_array($fn)) {
                echo "優先權 $priority：" . (is_object($fn[0]) ? get_class($fn[0]) : $fn[0]) . "::" . $fn[1] . "\n";
            } else {
                echo "優先權 $priority：" . $fn . "\n";
            }
        }
    }
}
' --path="$SITE_PATH" --allow-root

【預期輸出範例】會直接印出實際綁定的函式名稱，例如 優先權 10：MyHome_Auth::send_link 這種格式（實際 class／方法名稱依外掛版本而異，需要你自己執行後才會知道，這裡無法幫你預先猜測）。

【分支判斷邏輯】

• 🏮 若查到明確的 class／方法名稱，且你評估暫時不需要前台註冊功能 → 可依「Section 4-B」的做法，寫一個 mu-plugin 暫時移除這兩個 Hook 作為虛擬修補（Virtual Patch）
• 🏮 若輸出顯示「尚未註冊任何回呼」→ 代表你的佈景主題目前並未啟用前台註冊／Email 確認功能，觸發條件本身就不成立，風險相對較低，但仍建議儘速更新版本，避免未來不小心重新開啟該功能時暴露風險

㊄ 加固檢查（更新或應變完成後的複查清單）

【決策原理】由於 MyHome Core 並非 wordpress.org 收錄的外掛，標準的 wp plugin verify-checksums 指令無法用於此外掛（該指令只能比對 wordpress.org 官方倉庫的 MD5 清單，商業外掛沒有對應資料，執行會直接回報找不到該外掛的校驗資料）。因此加固階段改用「與 TangibleWP／ThemeForest 官方下載的原版 ZIP 逐檔比對」，作為功能對等的完整性驗證手段。

# 前提：已透過 ThemeForest 帳號下載官方 4.4.6 版 ZIP 至 /tmp/myhome-core-4.4.6-official.zip
OFFICIAL_ZIP="/tmp/myhome-core-4.4.6-official.zip"
LIVE_DIR="$SITE_PATH/wp-content/plugins/myhome-core"
TMP_EXTRACT="/tmp/myhome-core-official-extract"

mkdir -p "$TMP_EXTRACT"
unzip -q -o "$OFFICIAL_ZIP" -d "$TMP_EXTRACT"

diff -rq "$TMP_EXTRACT/myhome-core" "$LIVE_DIR"
echo "比對完成，diff 結束代碼：$?"

【預期輸出範例】若兩邊完全一致，diff -rq 不會印出任何一行，結束代碼為 0；若有任何差異，會逐行印出類似 Files LIVE_DIR/xxx.php and TMP_EXTRACT/xxx.php differ 或 Only in LIVE_DIR: backdoor.php 這類訊息，結束代碼為 1。

【分支判斷邏輯】

• 🏮 無任何輸出、結束代碼 0 → 外掛檔案本身乾淨，可繼續確認其他加固項目
• 🏮 出現 Only in LIVE_DIR 開頭的行 → 代表現場多出官方版本沒有的檔案，極可能是後門，需立即隔離該檔案並進入事件應變流程
• 🏮 出現 differ 的行、但檔名看起來是官方本來就有的檔案 → 需人工檢視差異內容（可用 diff -u 印出實際變更行），排除是快取外掛或授權驗證機制正常寫入的差異後，才能排除疑慮

其餘加固複查項目，建議逐項確認打勾：

• 🏮 wp plugin get myhome-core –field=version 回傳結果 ≥ 4.4.6
• 🏮 已執行 AUTH_SALT 輪替，且時間點晚於任何可疑請求的時間戳記
• 🏮 已對所有使用者強制登出（詳見 Section 4-A 指令）
• 🏮 WAF／防火牆規則仍保留作為多一層防禦（即使已更新，belt-and-suspenders 原則）
• 🏮 所有 Administrator 帳號已重設為高強度密碼，且【❓待確認】是否已導入 2FA 雙重驗證機制（原文未提及此外掛內建 2FA 支援，屬於🟡合理推論的額外加固建議，非官方修補內容）

🛡️ 應急處置與正式修補：分三層次防禦

🩵 荷包試算：更新是免費的，事後補救才是真正花錢的地方
升級外掛完全不用花一毛錢，只要幾分鐘就能完成。但如果拖到被入侵後才處理，成本會急遽攀升：房屋物件資料被竄改需要人工逐筆核對修正、客戶個資外洩可能面臨法遵裁罰、資安顧問鑑識與清除後門的工時費用、網站被 Google 標記不安全後的信任重建成本——這些加總起來，動輒是「立刻更新」成本的數十倍甚至上百倍，這筆帳怎麼算都划不來 💸

下面依照你在 Section 3 排查出來的結果，分成三條路徑：A. 已經有明確跡象顯示已中招、B. 尚未確認中招但也還沒完成正式更新、C. 標準的正式修補流程。三條路徑不是互斥的——實務上常見的順序是「A 先做證據保全與應急止血 → 同步進行 B 的防護 → 最後收斂到 C 完成正式修補」。

A. 已中招／疑似中招情境：資安事件應變 SOP

【決策原理】一旦 Section 3 排查出現「疑似中招」或「已中招」的分支判斷結果，第一原則是先保全證據、再處理現場，順序顛倒的話（例如急著刪帳號、急著清 log），會讓後續鑑識與法遵佐證失去依據 🫆

🚨 畫重點！千萬別踩雷：看到陌生管理員帳號的當下，先別急著刪除！先完整記錄該帳號的 ID、Email、建立時間、最後登入時間，並保留一份資料庫快照，之後鑑識與存證都會用到，刪了就等於燒掉現場證據 🙅‍♂️

# 步驟 1：立即備份現況（保全證據，先於任何清除動作）
SITE_PATH="/var/www/example-site"
EVIDENCE_DIR="/var/backups/incident-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$EVIDENCE_DIR"

wp db export "$EVIDENCE_DIR/database-snapshot.sql" --path="$SITE_PATH" --allow-root
tar -czf "$EVIDENCE_DIR/wp-content-snapshot.tar.gz" -C "$SITE_PATH" "wp-content"
cp -a "/var/log/nginx/example-site.access.log" "$EVIDENCE_DIR/access-log-snapshot.log"

echo "證據快照已封存於：$EVIDENCE_DIR"

# 步驟 2：記錄可疑帳號清單（先記錄，暫不刪除）
wp user list --role=administrator \
  --fields=ID,user_login,user_email,user_registered,user_activation_key \
  --path="$SITE_PATH" --allow-root --format=csv > "$EVIDENCE_DIR/admin-accounts-snapshot.csv"

# 步驟 3：立即讓所有既有的登入 Cookie 全數失效（不需等到更新完成才做）
wp config shuffle-salts --path="$SITE_PATH" --allow-root

wp user list --field=ID --path="$SITE_PATH" --allow-root \
  | xargs -I{} wp user session destroy {} --all --path="$SITE_PATH" --allow-root

echo "所有 Session 已強制失效，即使攻擊者手上仍有舊 Cookie 也無法再使用"

【預期輸出範例】wp config shuffle-salts 成功時會回傳 Success: Shuffled the salt keys.；wp user session destroy 迴圈跑完後，每一行會分別顯示 Success: Destroyed all sessions.。

【分支判斷邏輯】

• 🏮 確認有陌生管理員帳號 → 證據封存完成後，才將該帳號改為 subscriber 角色並停用（wp user update <ID> –role=subscriber –path=”$SITE_PATH” –allow-root），而非直接刪除，保留追蹤路徑
• 🏮 確認 uploads 目錄有後門檔案 → 先複製一份到證據資料夾（cp “$SITE_PATH/wp-content/uploads/可疑檔案.php” “$EVIDENCE_DIR/”），再從正式目錄移除
• 🏮 若研判外洩範圍涉及買賣雙方個資（姓名、電話、身分證字號等）→ 依 個資法 相關規定評估通報義務，建議同步聯繫法遵或委任律師，這部分屬於法律專業判斷範疇，本文僅提供技術面建議

完成證據保全與止血後，接著同步套用下方 B. 短期應急 的防護規則，並儘速走到 C. 正式修補 完成版本更新，兩者不衝突，可以同時進行 🔄

B. 短期應急：尚未確認中招，但也還沒完成正式更新

【決策原理】若因商業邏輯考量或相容性問題，導致無法在排查完成的當下立即更新外掛版本，這段「空窗期」就需要用網路層與應用層的手段降低風險，把攻擊門檻拉高，而不是完全裸奔等更新視窗 🔃

• ㊀ 限制相關功能：立即進入 MyHome 佈景主題的控制面板，關閉「前台使用者註冊」以及「Email 確認」功能，從源頭拔除觸發漏洞的條件
• ㊁ 關閉舊版模式：若網站佈局允許，避免讓 MyHome 佈景主題運行在 Legacy/WPBakery 模式下
• ㊂ WAF 防護方向：在 Cloudflare、AWS WAF、ModSecurity 或其他 Web 應用防火牆中，建立自訂規則：阻擋未帶合法 Session Cookie，且 Payload 中包含正則特徵 action=(send_link|activate) 且目的 URI 為 /wp-admin/admin-ajax.php 的 POST 請求
• ㊃ 增強 Log 與監控：暫時調高伺服器稽核日誌層級，針對 admin-ajax.php 的異常存取頻率配置自動封鎖規則（如 Fail2Ban）與告警機制

若你沒有 WAF、或還在等 WAF 規則審核上線，可以先用下面這個 mu-plugin 作為虛擬修補（Virtual Patch）應急——原理是暫時移除掉 Section 3-㊃ 反查出來的兩個未登入（nopriv）Hook，等於暫時關閉前台觸發這兩支函數的入口：

<?php
/**
 * MU-Plugin：CVE-2026-15980 短期虛擬修補
 * 用途：暫時移除 send_link / activate 的未登入(nopriv) AJAX 綁定，降低未修補期間的曝險
 *
 * 【重要】下方的 class 名稱與方法名稱，請務必先用 Section 3-㊃ 的 wp eval
 * 指令在你自己的網站上實際反查後，替換成查到的真實名稱再上線，
 * 直接照抄範例中的佔位名稱是無效的（也不會有任何效果，等同沒做防護）。
 */
add_action( 'init', function () {
    // 範例佔位名稱，請替換為你反查到的實際 class::method
    remove_action( 'wp_ajax_nopriv_send_link', array( 'MyHome_Auth', 'send_link' ) );
    remove_action( 'wp_ajax_nopriv_activate', array( 'MyHome_Auth', 'activate' ) );
}, 20 );

🚨 畫重點！千萬別踩雷：這段虛擬修補務必先在 Staging 環境測試，確認移除後前台其他功能（尤其是正常的房仲會員註冊流程，若你評估暫時不需要開放前台註冊）不會跟著壞掉。若佔位的 class／method 名稱沒有替換成真實值，這段程式碼會靜靜地什麼事都不做，讓你誤以為已經防護但其實完全沒生效，這是這招最大的風險 🙅‍♂️

C. 正式修補：判斷環境 → 盤點 → 備份 → Dry-run → 更新 → 驗證

【決策原理】正式修補的唯一根本解法，是把外掛升級到官方已加入權限校驗與 Nonce 驗證的 4.4.6 版本。為了避免更新過程本身造成網站崩潰，強制按照「判斷環境 → 盤點 → 備份 → Dry-run 預演 → 正式更新 → 驗證」這六階段執行，任何一階段失敗都不往下一階段走。

⚠️ 安全提醒：在正式環境升級外掛前，務必先於測試環境備份並驗證，避免網站崩潰 🙅‍♂️

▍情境一：💠單一網站，完整六階段腳本

#!/usr/bin/env bash
set -euo pipefail

SITE_PATH="/var/www/example-site"
TARGET_VERSION="4.4.6"
BACKUP_DIR="/var/backups/myhome-core-patch-$(date +%Y%m%d-%H%M%S)"

echo "── 階段1：判斷環境 ──"
wp core version --path="$SITE_PATH" --allow-root
wp config is-true MULTISITE --path="$SITE_PATH" --allow-root || echo "確認為單站，非 Multisite"

echo "── 階段2：盤點目前版本 ──"
CURRENT_VERSION=$(wp plugin get myhome-core --field=version --path="$SITE_PATH" --allow-root)
echo "目前版本：$CURRENT_VERSION"

echo "── 階段3：備份資料庫與檔案 ──"
mkdir -p "$BACKUP_DIR"
wp db export "$BACKUP_DIR/database.sql" --path="$SITE_PATH" --allow-root
tar -czf "$BACKUP_DIR/wp-content.tar.gz" -C "$SITE_PATH" "wp-content"
echo "備份完成：$BACKUP_DIR"

echo "── 階段4：Dry-run 預演 ──"
wp plugin update myhome-core --version="$TARGET_VERSION" --dry-run --path="$SITE_PATH" --allow-root

echo "請確認上方 Dry-run 結果無誤，5 秒後將執行正式更新，Ctrl+C 可中止"
sleep 5

echo "── 階段5：正式更新 ──"
wp plugin update myhome-core --version="$TARGET_VERSION" --path="$SITE_PATH" --allow-root

echo "── 階段6：更新後驗證 ──"
NEW_VERSION=$(wp plugin get myhome-core --field=version --path="$SITE_PATH" --allow-root)
echo "更新後版本：$NEW_VERSION"

if [ "$NEW_VERSION" = "$TARGET_VERSION" ]; then
  echo "✅ 版本驗證成功，已升級至 $TARGET_VERSION"
else
  echo "❌ 版本驗證失敗，請人工檢查，並考慮從 $BACKUP_DIR 還原"
  exit 1
fi

【預期輸出範例】階段4 的 Dry-run 會列出類似欄位結構的預覽表格（name / old_version / new_version），實際欄位排版會依你的 WP-CLI 版本略有差異，但重點是確認 old_version 顯示你排查到的舊版本、new_version 顯示 4.4.6；階段6 若印出 ✅ 版本驗證成功 才算真正完成。

【分支判斷邏輯】

• 🏮 Dry-run 沒有列出 MyHome Core → 代表 WP-CLI 抓不到官方更新來源，通常是因為佈景主題授權過期導致沒有自動更新提示，請直接跳到下方「商業版特殊管道」處理
• 🏮 階段5 更新指令執行後回傳非 0 結束代碼 → 立即停止，改用 wp db import “$BACKUP_DIR/database.sql” 搭配還原 wp-content.tar.gz 回滾，切勿在半更新狀態下繼續操作
• 🏮 階段6 驗證失敗（版本號不符）→ 依腳本邏輯自動回傳非 0 結束代碼，適合搭配 CI/CD 或排程系統的失敗告警機制

▍情境二：❇️獨立多站，批次六階段（含逐站失敗隔離）

#!/usr/bin/env bash
# 獨立多站批次修補：任何一站失敗不影響其他站繼續執行，最後統一輸出成敗報表
SITES_ROOT="/var/www/sites"
TARGET_VERSION="4.4.6"
RESULT_LOG="/var/log/myhome-core-batch-patch-$(date +%Y%m%d-%H%M%S).log"

for site_path in "$SITES_ROOT"/*/; do
  site_path="${site_path%/}"
  [ -f "$site_path/wp-load.php" ] || continue

  version=$(wp plugin get myhome-core --field=version --path="$site_path" --allow-root 2>/dev/null) || continue
  [ -z "$version" ] && continue

  echo "處理站台：$site_path（目前版本 $version）" | tee -a "$RESULT_LOG"

  backup_dir="/var/backups/$(basename "$site_path")-$(date +%Y%m%d-%H%M%S)"
  mkdir -p "$backup_dir"

  if wp db export "$backup_dir/database.sql" --path="$site_path" --allow-root 2>>"$RESULT_LOG" \
     && wp plugin update myhome-core --version="$TARGET_VERSION" --dry-run --path="$site_path" --allow-root 2>>"$RESULT_LOG" \
     && wp plugin update myhome-core --version="$TARGET_VERSION" --path="$site_path" --allow-root 2>>"$RESULT_LOG"; then
    echo "「$site_path」→ ✅ 更新成功" | tee -a "$RESULT_LOG"
  else
    echo "「$site_path」→ ❌ 更新失敗，備份保留於 $backup_dir，需人工介入" | tee -a "$RESULT_LOG"
  fi
done

echo "批次修補完成，完整記錄：$RESULT_LOG"

▍情境三：WordPress Multisite（單一程式碼、逐分站驗證啟用狀態）

#!/usr/bin/env bash
# Multisite：外掛檔案只需更新一次，但每個分站的啟用狀態需要分別確認驗證
NETWORK_PATH="/var/www/multisite-network"
TARGET_VERSION="4.4.6"

echo "── 階段3：備份（含資料庫與整個網路的 wp-content） ──"
BACKUP_DIR="/var/backups/multisite-patch-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"
wp db export "$BACKUP_DIR/database.sql" --path="$NETWORK_PATH" --allow-root
tar -czf "$BACKUP_DIR/wp-content.tar.gz" -C "$NETWORK_PATH" "wp-content"

echo "── 階段4：Dry-run ──"
wp plugin update myhome-core --version="$TARGET_VERSION" --dry-run --path="$NETWORK_PATH" --allow-root

echo "── 階段5：正式更新（網路層級，僅需執行一次） ──"
wp plugin update myhome-core --version="$TARGET_VERSION" --path="$NETWORK_PATH" --allow-root

echo "── 階段6：逐分站驗證仍正常運作 ──"
wp site list --field=url --path="$NETWORK_PATH" --allow-root | while IFS= read -r site_url; do
  status=$(wp plugin list --url="$site_url" --path="$NETWORK_PATH" --field=status --allow-root 2>/dev/null | grep -A0 "myhome-core" || true)
  echo "分站 $site_url 驗證完成"
done

【分支判斷邏輯（❇️獨立多站／✴️Multisite共通）】

• 🏮 獨立多站報表中出現 ❌ 失敗站台 → 逐一檢查該站的 RESULT_LOG 錯誤訊息，常見原因是佈景主題授權過期、磁碟空間不足，或該站有自訂 Hook 與新版本衝突
• 🏮 Multisite 更新後某個分站前台功能異常 → 因為所有分站共用同一份程式碼，若新版本與某分站的自訂修改（Child Theme／自訂 Hook）衝突，需要針對該分站個別排查，而非整個網路回滾

商業版／付費外掛特殊管道：由於 MyHome Core 經常綁定在 ThemeForest 的付費佈景主題包中，若系統未跳出自動更新提示，管理員必須重新登入 ThemeForest 帳戶，下載最新版佈景主題安裝包，手動提取 MyHome Core 4.4.6 的 ZIP 檔案，透過 FTP/SFTP 或以下指令覆蓋安裝：

# 手動覆蓋安裝流程（適用授權過期、WP-CLI 抓不到自動更新來源的情況）
MANUAL_ZIP="/tmp/myhome-core-4.4.6-official.zip"
SITE_PATH="/var/www/example-site"

# 先備份現有版本再覆蓋，避免 ZIP 本身有問題時無法回滾
mv "$SITE_PATH/wp-content/plugins/myhome-core" "$SITE_PATH/wp-content/plugins/myhome-core-backup-$(date +%Y%m%d)"

wp plugin install "$MANUAL_ZIP" --path="$SITE_PATH" --allow-root
wp plugin activate myhome-core --path="$SITE_PATH" --allow-root

wp plugin get myhome-core --field=version --path="$SITE_PATH" --allow-root

🫂 新手求助：完全看不懂上面這些指令怎麼辦？
如果您不熟悉 WP-CLI 或伺服器操作，最快的方式是直接把本文（或 CVE-2026-15980 這組編號）轉發給您的網站維護廠商、接案工程師，或代管主機商的客服，並標示為「緊急資安事件」。多數台灣主機商都提供技術支援管道，遇到資安緊急事件時不用不好意思開口求助，這比自己硬著頭皮亂改設定安全得多 ⛑️

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

🔥 CVE-2026-15980 是一個「兩支各自看似合理的函數，湊在一起卻變成免密碼登入後門」的經典案例。它不需要駭客技術高超，只需要您的網站剛好符合三個條件的交集：❶佈景主題還在舊版編輯模式、❷開啟了前台註冊與 Email 驗證、❸剛好有一個帳號還沒完成驗證。

這起事件最大的提醒是：資安更新從來不是可有可無的選項。尤其當漏洞細節已經公開流傳，每拖延一小時，等於是把大樓主委的萬能磁扣繼續放在無人看管的大廳桌上 🔑

💪 附錄：三分鐘自救 SOP 一覽表

• ❶ 登入後台「外掛」→「已安裝的外掛」，確認 MyHome Core 版本是否 ≤ 4.4.5
• ❷ 點擊「立即更新」，確保更新後版本 ≥ 4.4.6，並清除快取外掛與 CDN（如 Cloudflare）快取
• ❸ 若暫時無法更新，前往 MyHome 佈景主題設定，立即關閉「前台使用者註冊」與「Email 驗證」功能，並確認佈景主題未運行於 Legacy/WPBakery 模式
• ❹ 更新完成後，於 wp-config.php 重新生成 AUTH_SALT 相關金鑰，強制所有使用者登出，讓已外洩的 Cookie 全數失效
• ❺ 要求所有管理員帳號重設高強度密碼，並檢查是否有陌生的 Administrator 帳號或不明 PHP 檔案

^[28]

📚 參考資料與延伸資源

• 📌 CVE-2026-15980 官方記錄（NVD） ^[29]
• 📌 Wordfence Threat Intelligence：MyHome Core 身分驗證繞過至帳號接管漏洞公告 ^[1]
• 📌 IONIX Threat Center：CVE-2026-15980 分析 ^[30]
• 📌 Tenable CVE 數據庫：CVE-2026-15980 ^[31]
• 📌 Strix AI CVE 分析：CVE-2026-15980 ^[32]