你的網站門鎖被灌了「萬能複製卡」：Uix UserCenter 高危漏洞全解析（CVE-2026-16259／CVSS 9.8）

🔥 懶人包：
WordPress 會員系統外掛 Uix UserCenter 被爆出不需要登入、不需要點擊任何連結就能被遠端接管管理員帳號的超嚴重漏洞 CVE-2026-16259，CVSS 評分 9.8（近乎滿分）。問題出在外掛把「驗證身分的鑰匙」寫死在程式碼裡，而且全世界每一個安裝這套外掛的網站，用的都是同一把鑰匙；更慘的是系統拿到鑰匙後根本不檢查「你到底是誰」，攻擊者可以直接指定自己要接管的帳號 ID。最要命的是：目前官方沒有任何修補版本，這款外掛已經被下架且停止維護，唯一的解法就是立刻刪除它 ⛑️

🌐 前往 WordPress 官網查看 Uix UserCenter

🧐 這個漏洞到底在講什麼？先用一個生活化比喻搞懂

先別急著看落落長的技術名詞，我們把你的 WordPress 會員系統想像成一棟配備了「智慧電子門鎖」的高級辦公大樓，而 Uix UserCenter 這款外掛，就是負責管理整棟大樓門禁的系統商 🏢

正常情況下，每個員工（不管是基層還是老闆）都會拿到一張經過專屬加密的感應扣卡。當員工想去管理室修改自己的密碼時，系統應該要做兩件事：檢查這張卡是不是真的，並且確認「來要求改密碼的人，真的就是卡片的主人本人」。這款門鎖系統卻在這兩件事上都出了致命的差錯 😱

把這兩個瑕疵疊在一起，攻擊者完全不需要具備這棟大樓的任何通行證（無需登入帳號），就能直接從外部遠端發送一個偽造的修改指令，瞬間把網站最高權限管理員的登入信箱與密碼，全部改成攻擊者自己的資料，接著就能「合法地」走進系統，把你的網站整碗端走 🙅‍♂️

📖 事情的來龍去脈：從通報到公開只花了兩天

這起資安事件的發展速度極快，且由於漏洞的利用條件極低（不需要登入、不需要任何互動），引起了各大資安研究機構的關注。以下是這個漏洞從被發現到公開的關鍵時間軸 ⏰

💡 碎碎念：目前野生環境的攻擊機率還不算高，但別因此鬆懈
根據 EPSS 預測系統的數據，這個漏洞在野生環境的大規模自動化攻擊機率目前暫時低於 1%，資安機構也選擇暫時保留、不公開概念性驗證攻擊程式碼（PoC）。但威脅防護廠商如 IONIX、Wordfence 都已呼籲企業必須以最快速度處置，因為這類低複雜度的漏洞極容易被駭客逆向工程後拿去武器化，一旦 PoC 流出，潛伏期可能被壓縮到極短時間 🕰

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

此漏洞被評定為 🔴 嚴重（CVSS 9.8），之所以如此致命，是因為它徹底瓦解了網站的防禦第一線，而且攻擊成本極低 ⚠️

✅ 已確認事實

• 不需要任何登入帳號：攻擊者不需要是網站的註冊會員，一般匿名網路訪客即可直接觸發此漏洞
• 不需要任何互動與特定權限（Zero-Click）：網站管理者或使用者不需要點擊任何釣魚信件或惡意連結，攻擊者單方面發送網路請求即可完成攻擊
• 直接的帳號接管：攻擊者可以隨意指定資料庫中的任何一個使用者（通常會直接鎖定 ID 為 1 的最高權限管理員），利用偽造的權杖強制覆寫該使用者的電子郵件信箱與密碼

🟡 合理推論

• 機敏資料全面外洩：駭客登入後台後，能毫無阻礙匯出所有會員個資、訂單紀錄、客戶聯絡方式，對企業造成商譽受損與隱私法規（如 GDPR）裁罰風險
• 網站內容遭惡意竄改：攻擊者可利用管理員權限植入博弈或色情網站的隱藏連結（SEO Spam），導致網站搜尋排名遭嚴厲懲罰，甚至被標記為危險網站
• 自動化武器的大規模掃描：由於利用邏輯簡單且完全可被腳本自動化，預期很快會有殭屍網路將此特徵加入常規掃描清單，對全球 WordPress 網站進行無差別探測

🔴 假設情境（若伺服器底層防護不夠嚴謹）

• 駭客取得管理員權限後，可能進一步利用內建的「佈景主題編輯器」或「外掛編輯器」，直接將惡意 PHP 後門程式碼（Web Shell）寫入伺服器
• 若伺服器未設定妥善的權限隔離（例如未啟用 open_basedir 限制，或 PHP 執行身分擁有過大系統讀寫權限），駭客可能跨越 WordPress 應用層，直接取得整台伺服器的底層控制權（RCE），把主機變成 DDoS 跳板或進行勒索軟體加密

🚨 畫重點！千萬別踩雷：目前這款外掛沒有任何安全版本可以升級，也就是說「更新外掛」這個平常最好用的解法，這次完全失效。唯一能阻止災難的方法，就是直接把它從你的網站上徹底移除 🙅‍♂️

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

🙋 一般網站管理者（部落格主、小型商店）

你不需要看懂任何程式碼，只要做一件事：登入後台確認自己有沒有安裝並啟用 Uix UserCenter 這款外掛。這是決定你的網站有沒有暴露在風險中的唯一關鍵 🌠

適合行動：最高優先，立刻處理。 找到就直接停用並刪除，這個動作完全不需要程式背景，五分鐘內就能完成 👍

👨‍💻 獨立開發者／網站代管商（DevOps）

如果你手上管理多個客戶的 WordPress 網站，光靠手動點擊後台檢查效率太低。建議透過 WP-CLI 批次檢查所有站台是否安裝了此外掛，並在 WAF 層級預先部署阻擋規則，作為徹底移除前的緊急緩衝防線 🔧

適合行動：極高優先。 請直接看後段技術深潛篇的排查指令與緊急防堵措施 ⚙️

🏢 企業商業用途（電商、會員制網站）

若你的網站涉及大量會員個資或交易紀錄，這起漏洞不只是資安問題，更直接牽涉個資法與 GDPR 合規責任。一旦資料外洩被證實，企業面臨的可能不只是商譽受損，還有主管機關的裁罰 🚫

適合行動：極高優先，且需留存證據。 除了立刻刪除外掛，建議同步啟動資安事件應變流程，全面盤查後台是否已出現不明管理員帳號，並保留稽核日誌以供後續調查與法遵佐證 ⚠️

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

⛔️ 這類「圖方便快速找了一款外掛就直接上線」而沒有留意其維護狀態的網站，反而是最容易誤判自己「應該沒事」的高風險族群，請務必優先盤點自己安裝的每一款外掛是否仍在積極維護 🙅‍♂️

🛡️ 無痛自救指南：一般管理者五步驟就能搞定

如果你不是工程師，不用緊張，以下步驟完全不需要程式背景 💪

• ㊀ 到哪裡查看：登入 WordPress 後台，滑鼠移到左側選單「外掛」，點擊「已安裝外掛」，在清單中尋找名稱為 Uix UserCenter 的外掛
• ㊁ 是否需要更新：無法更新，經過查證，開發團隊目前並未釋出任何可修復此漏洞的新版本
• ㊂ 該更新到哪一版：沒有任何安全版本可供選擇，現存 0 到 1.0.3 版本全數處於危險狀態
• ㊃ 建議怎麼處理：強烈建議立即停用並徹底刪除。先點擊該外掛下方的「停用」，網頁重新整理後，再點擊紅色的「刪除」。由於漏洞核心位於一個對外開放的更新端點，僅僅停用可能仍留下殘留腳本風險，徹底刪除檔案才是保障網站安全的唯一手段
• ㊄ 不熟悉操作怎麼辦：若你擔心刪除外掛會導致會員系統崩潰，請立即聯絡協助你架設網站的網頁設計公司、主機代管商或專業 WordPress 維護團隊，請他們針對 CVE-2026-16259 進行應急處置，並全面盤查後台是否已出現不明的管理員帳號

🫂 新手求助：不確定自己有沒有裝這款外掛怎麼辦？
如果你完全不熟悉 WordPress 後台，最快的方式是直接聯繫你的主機代管商或當初協助建站的廠商，請他們幫忙確認一次「已安裝外掛」清單。多數台灣主機商都提供技術支援管道，遇到資安緊急事件不用不好意思開口求助，這比自己硬著頭皮亂點安全得多 ⛑️

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

🧑‍🔧 DevOps 小知識：漏洞成因是兩個致命的架構性設計錯誤疊加
WordPress 核心原本提供成熟的 Cookies 與 Nonce（一次性權杖）機制來防範 CSRF 與越權操作，但 Uix UserCenter 在實作 AJAX 遠端 API 時，自行設計了一套權杖驗證機制，並引入兩個致命缺陷：其一，簽署權杖用的金鑰（Signing Secret）理應在安裝時動態隨機生成並安全儲存於環境變數或 wp_options，但開發者卻把它以字串常數的形式直接寫死在 PHP 原始碼中，任何人下載這套開源外掛都能逆向提取出這把萬能金鑰。其二，外掛暴露了一個名為 profile-update 的操作端點，後端收到更新請求時，僅檢驗「權杖的數位簽章是否正確」，簽章一過就無條件信任並對傳入的 User ID 執行覆寫，完全沒有實作 get_current_user_id() 之類的授權邊界檢查來比對「發起請求的人」與「被修改的帳號」是否為同一實體。這種不安全的直接物件參考（IDOR）疊加金鑰外洩，造就了無需任何前置條件的特權提升路徑 ⛑️

🎯 攻擊鏈路：從偽造鑰匙到接管只要幾個步驟

🟡 合理推論（Probable Escalation）：一旦攻擊者透過此漏洞進入後台，即便系統中存在其他需要高權限才能觸發的漏洞（如已驗證的 Stored XSS 或 RCE），也能輕易將其串聯，大幅擴大攻擊殺傷力 ⚠️

🔴 假設情境（Worst-Case）：若伺服器權限未適當限縮，例如 PHP-FPM 以 root 身分運行、或缺乏 SELinux／AppArmor 沙盒防護，攻擊者接管後台後可透過佈景主題編輯器寫入 Web Shell，取得作業系統層級的命令列控制權，甚至成為攻擊企業內部網路的跳板，對其他未對外公開的伺服器進行橫向移動 🚫

✅ 資安排查與自我檢查 Checklist

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

這一節依 環境判斷 → 盤點 → Log 排查 → 後門檢查 → 加固 的順序往下拆，同時涵蓋單一網站、獨立多站、Multisite 三種常見部署型態，每一步都會先講「為什麼要這樣做」，再給實際指令跟預期輸出，最後補上該怎麼往下分支判斷 🧭

🕵️ 網站到底有沒有被摸過？先把現場一層一層翻出來

先講一個容易被忽略的觀念：這款外掛從來沒有出過安全版本，所以「排查」這件事不能等同於一般漏洞常見的「先看有沒有更新」，因為根本沒有更新可看。真正該問的問題只有一個——只要 Uix UserCenter 曾經在你的網站上處於啟用狀態，這段期間有沒有人已經摸過管理員帳號？

🔥 一句話先記住：因為這個漏洞不需要登入、不需要任何互動就能觸發（Zero-Click），只要網站在受影響期間對外公開，就該假設「已經被摸過」是預設立場，而不是「應該沒事」，排查的目的是把這個假設證實或推翻，而不是找心安 🚨

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

這一步看似無聊，卻是後面所有批次指令能不能安全下手的地基，先花一分鐘搞清楚環境類型，能省下後面很多冤枉路 🌠

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

決策原理：先確認目前路徑真的能載入 WordPress，再往下查外掛狀態，比直接對一個不確定的目錄開槍安全得多 🎓

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

預期輸出：

OK: WordPress installation detected.

分支判斷：

• 🏮 顯示 OK → 可以進入盤點。
• 🟠 顯示 ERROR → 先停止，不要把錯誤目錄當成網站處理。
• 🟡 網站路徑含空格或特殊字元時，保留 “$WP_PATH” 的雙引號，不要自行拆掉。

❇️ 獨立多站：先找出每一個真正的 WordPress

決策原理：同一台伺服器有很多 WordPress，不代表是 Multisite。這時應該從各站的 wp-config.php 建立完整 Inventory，再逐一檢查 🧾

SEARCH_ROOT="/var/www"

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

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

預期輸出：

WordPress: /var/www/site-a/public_html
WordPress: /var/www/site-b/public_html
WordPress: /var/www/site-c/public_html

分支判斷：

• 🏮 每個路徑都能通過 → 建立獨立多站 Inventory，進入下一步。
• 🟠 找到 wp-config.php 卻無法載入 → 先確認 PHP、權限或路徑是否正確，不要略過直接跳下一站。
• 🟡 同一個網站被找到多個 wp-config.php → 先人工確認哪個才是 Production，避免誤動到備份或 Staging。

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

決策原理：wp site list 是官方文件明確定義的 Multisite 專用指令，用來列出一個 Network installation 底下的所有 Site，不能拿來掃描一台伺服器上的獨立多站 📔

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://shop.example.com/
3        https://blog.example.com/

分支判斷：能列出多個 Site → 進入 Multisite 流程；只列出單一網站不代表一定是獨立多站，還要看是否存在 Network 設定 🌠

🧑‍🔧 DevOps 小知識：獨立多站像同一棟大樓裡有三家公司，各自有自己的門、帳冊與倉庫；Multisite 則比較像同一家公司底下有三個部門。外觀看起來都是「三個網站」，但外掛檔案、資料庫與更新（或這次的移除）邏輯完全不同，判斷錯環境，後面的批次指令就會下錯範圍 ⚠️

🔎 ㊁ 盤點：先回答「哪些站裝了 Uix UserCenter、目前到底是哪一版？」

公開資料把 0 至 1.0.3 全數版本列為受影響範圍，而且截至撰稿為止沒有任何安全版本；也因為外掛已從 WordPress.org 外掛庫下架，wp plugin get 查到的更新欄位通常也不會再顯示官方來源的更新資訊，這個「查不到更新來源」本身就是間接佐證它已下架的訊號之一 📜

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

決策原理：外掛盤點應以 WordPress 自己認得的 Plugin metadata 為主，而不是自己 grep PHP 檔案猜版本號 🎓

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

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

預期輸出：

name: uix-usercenter
status: active
version: 1.0.3
update: none
update_version:

分支判斷：

• 🔴 只要有找到（不論版本號是 0 到 1.0.3 之間哪一版），一律視為高風險，直接進入第 4 節的止血／移除流程，不需要比對「有沒有更新」這件事，因為官方根本沒有出過修補版 🚫
• 🟠 找不到外掛 → 先確認是否已被移除、是否曾經改過資料夾名稱，並確認沒有查錯網站路徑；如果曾經裝過但目前找不到，仍建議往下做入侵痕跡排查，因為漏洞觸發後外掛本身可以被刪除，但被竄改的管理員帳號不會自己消失 ⚠️

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

決策原理：每個獨立 WordPress 都有自己的外掛安裝狀態，必須逐一使用 –path 個別確認 📊

SEARCH_ROOT="/var/www"

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

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

    version="$(wp --path="$path" \
        plugin get "uix-usercenter" \
        --field=version 2>/dev/null || true)"

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

預期輸出：

Site: /var/www/site-a/public_html | Uix UserCenter: 1.0.2
Site: /var/www/site-c/public_html | Uix UserCenter: 1.0.3

分支判斷：這份清單就是你的第一張風險地圖，A、C 兩站直接列入第 4 節的優先處理名單；沒被列出來的站（例如 B）代表沒偵測到這款外掛，可以降低優先序，但如果 B 站過去曾經裝過又移除，仍建議照第 3 節 ㊃、㊄ 補做一次痕跡排查 🧧

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

決策原理：Multisite 共用同一套外掛檔案，不能把每個 Site 當成一個獨立外掛安裝來看待 📔

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

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

wp --path="$WP_PATH" plugin is-active "uix-usercenter" --network \
    && echo "Network Activated: yes" \
    || echo "Network Activated: no"

預期輸出：

name: uix-usercenter
status: active
version: 1.0.3
update: none
update_version: 
Network Activated: yes

分支判斷：如果是 Network Activated，代表整個 Network 底下所有 Site 都共用同一份風險，處理範圍要以 Network 為單位，而不是只挑幾個 Site 動手；如果只在個別 Site 啟用，再搭配 –url=”$url” 逐一確認狀態 🌠

🧾 ㊂ Log 排查特徵：找「端點＋方法＋異常回應」的組合，而不是某個神奇 IP

技術原理已知漏洞打的是 admin-ajax.php 上的 action=profile-update 這個自訂端點，因此真正有意義的排查目標，是這個端點在受影響期間有沒有被異常呼叫過，而不是漫無目的地翻整份 Log 🔍

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

決策原理：不同主機環境的 Access Log 路徑完全不同，不能把某一個路徑當成所有伺服器的固定答案 🎓

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

if [ -f "$LOG_FILE" ]; then
    grep -Ei \
        'action=profile-update|admin-ajax\.php.*uix|uix-usercenter' \
        "$LOG_FILE" |
    tail -n 100
else
    echo "LOG NOT FOUND: $LOG_FILE"
fi

預期輸出：如果 Log 路徑錯誤：

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

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

... "POST /wp-admin/admin-ajax.php?action=profile-update HTTP/1.1" 200 ...
... "POST /wp-login.php HTTP/1.1" 302 ...

接著針對「同一個 IP、先打 profile-update 又緊接著登入成功」這個組合再做一次交叉比對：

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

grep -Ei 'action=profile-update' "$LOG_FILE" |
awk '{print $1}' |
sort -u |
while IFS= read -r ip; do
    printf '\n===== IP: %s =====\n' "$ip"

    grep -F "$ip" "$LOG_FILE" |
    grep -Ei 'profile-update|wp-login\.php' |
    tail -n 20
done

分支判斷：

• 🟢 完全沒有命中 action=profile-update → 這一項沒有發現異常，但不能單憑這一點宣稱絕對乾淨，因為 Log 可能已輪替或遺失。
• 🟡 出現 profile-update 但沒有伴隨可疑登入 → 提高關注等級，接續往下做後門檢查點確認。
• 🔴 同一 IP 短時間內先打 profile-update、緊接著對 wp-login.php 送出 POST 並拿到 302（登入成功）→ 這是帳號已遭接管的強烈跡象，直接進入第 4 節 A 情境。

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

決策原理：不要只查其中一站；漏洞如果存在於多個獨立 WordPress，每一站都有可能是受害站台 📊

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 -Ei \
        'action=profile-update|admin-ajax\.php.*uix|uix-usercenter' \
        "$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 一項就下結論 🧧

✴️ Multisite：同一份 Web Server Log，從 URL／時間再定位 Site

決策原理：Multisite 通常共用同一個 VirtualHost，因此 Log 排查要把 Host、URL 與 Site 清單對照著看 📔

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

if [ -f "$LOG_FILE" ]; then
    grep -Ei \
        'action=profile-update|admin-ajax\.php.*uix|uix-usercenter' \
        "$LOG_FILE" |
    tail -n 100
fi

分支判斷：找到可疑時間點後，用 wp site list 取得 Network Site 清單，依 Log 中的 Host／URL 對照哪個 Site 受影響；action=profile-update 曾出現不等於「一定成功入侵」，同樣地完全沒有找到也不能保證完全沒被攻擊，Log 只是證據之一 🚨

👀 ㊃ 後門檢查點：帳號、排程、檔案，一次盤三個地方

如果攻擊者真的透過這個漏洞把管理員帳號的信箱和密碼改成自己的，光看「網站現在有沒有異常」是看不出來的，得直接去資料庫層與檔案層找痕跡 🎓

💠 單一網站

決策原理：依「陌生管理員 → 既有帳號被竄改 → 可執行的可疑檔案 → 異常排程 → 網址被劫持」的順序，把最容易被忽略的角落一次盤點完 📜

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

echo "===== 1. 管理員清單 ====="
wp --path="$WP_PATH" user list \
    --role=administrator \
    --fields=ID,user_login,user_email,display_name,user_registered \
    --format=table

echo "===== 2. wp-content/uploads 內的可疑可執行檔 ====="
find "$WP_PATH/wp-content/uploads" -type f \
    \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.php*" \) \
    -print

echo "===== 3. 近 7 天內被修改的 PHP 檔案 ====="
find "$WP_PATH" -type f -name "*.php" -mtime -7 -print

echo "===== 4. Cron 排程是否有陌生 Hook ====="
wp --path="$WP_PATH" cron event list \
    --fields=hook,next_run_gmt,recurrence \
    --format=table

echo "===== 5. siteurl／home 是否被改成釣魚網址 ====="
wp --path="$WP_PATH" option get siteurl
wp --path="$WP_PATH" option get home

預期輸出（節錄）：

===== 1. 管理員清單 =====
ID  user_login  user_email          display_name       user_registered
1   admin       admin@example.com    Site Admin         2026-01-10 08:30:00

===== 5. siteurl／home 是否被改成釣魚網址 =====
https://example.com
https://example.com

分支判斷：

• 🔴 多出不認識的 Administrator，或既有帳號的 user_email 對不上你記錄中的信箱 → 直接視為疑似中招，進入第 4 節 A 情境，不要先急著改密碼，先保留這筆紀錄。
• 🔴 siteurl 或 home 不是你的正確網址 → 立即視為高風險事件。
• 🟡 找到近 7 天內變更的 PHP 檔案，但都是你自己合法部署的更新 → 記錄原因，不要一律當成惡意檔案；無法確認來源的，先保留副本再深入比對。
• 🟢 五項檢查皆無異常 → 風險降低，但建議搭配第 3 節 ㊂ 的 Log 排查交叉確認。

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

SEARCH_ROOT="/var/www"

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

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

    printf '\n===== BACKDOOR CHECK: %s =====\n' "$path"

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

    find "$path/wp-content/uploads" -type f \
        \( -iname "*.php" -o -iname "*.phtml" \) \
        -print 2>/dev/null

    wp --path="$path" option get siteurl 2>/dev/null
done

分支判斷：某站出現未知管理員或可疑檔案 → 優先標記該站進行事件調查；不要因為同一台伺服器的其他站看起來正常，就跳過該站的後續處置 ⚠️

✴️ Multisite：先釐清 Network Administrator 與各 Site 管理員的差異

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

echo "===== Network 使用者清單 ====="
wp --path="$WP_PATH" user list \
    --fields=ID,user_login,user_email,display_name,user_registered \
    --format=table

echo "===== Network Cron ====="
wp --path="$WP_PATH" cron event list \
    --fields=hook,next_run_gmt,recurrence \
    --format=table

echo "===== Network Uploads 可疑檔案 ====="
find "$WP_PATH/wp-content/uploads" -type f \
    \( -iname "*.php" -o -iname "*.phtml" \) \
    -print

分支判斷：發現未知帳號 → 再進一步確認它具備哪個 Network／Site 層級的權限，不要看到帳號存在就直接刪除，先留存紀錄再處置 🧧

🧱 ㊄ 加固檢查：修不了漏洞，至少把第二道門鎖起來

這個漏洞最麻煩的地方就是「更新」這個選項不存在，所以加固的重點不是等修補，而是降低這個端點被觸及的機會，直到你完成第 4 節的正式移除為止 🔧

🌐 Web Server／WAF 層：先封住漏洞端點的可達性

決策原理：如果因為業務需求暫時無法立刻移除外掛（例如需要先確認替代註冊流程），可以先在 Web Server 層擋掉對 action=profile-update 的未授權請求，當作正式移除前的緩衝，但這只是臨時措施，不能取代移除 🚨

# Nginx 範例：僅示意「應攔截的請求特徵」，實際規則請依主機環境自行調整並先於 Staging 驗證
location = /wp-admin/admin-ajax.php {
    if ($args ~* "action=profile-update") {
        return 403;
    }
}

# Apache 範例：僅示意「應攔截的請求特徵」，實際規則請依主機環境自行調整並先於 Staging 驗證
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} action=profile-update [NC]
RewriteRule ^wp-admin/admin-ajax\.php$ - [F,L]
</IfModule>

分支判斷：如果網站上有其他正常功能也共用 admin-ajax.php（幾乎所有網站都會），這條規則只針對 action=profile-update 這個特定參數值，不會擋掉其他合法的 Ajax 請求；但如果你不確定自己的網站架構是否有例外情況，先在 Staging 驗證過再套到 Production ⚙️

🔐 後台存取：IP 白名單先擋一層

# Apache 範例：僅允許特定辦公室／VPN IP 存取後台登入，其餘一律拒絕
<Files "wp-login.php">
    Require ip 203.0.113.10
    Require ip 198.51.100.0/24
</Files>

分支判斷：如果網站有遠端協作者或多個辦公室，記得把所有需要存取的 IP 都列進白名單，避免正式移除外掛的當下反而先把自己人擋在外面 🧯

💡 碎碎念：查了 SVN／GitHub，這次真的沒有 diff 可以比對
按照慣例，這裡原本應該延伸查證外掛在 WordPress.org SVN Repository 或 GitHub 上「修補前後」的程式碼 diff，反推防禦邏輯。但因為 Uix UserCenter 從未釋出過任何安全版本、且已從外掛庫下架，目前【❓待確認】查無任何 tag 或 commit 可供比對。如果未來開發商真的重新上架修補版，建議屆時直接比對 SVN tags 目錄裡 1.0.3 與新版本的差異，重點看兩個地方：簽署 Token 的金鑰是否已經改成安裝時動態產生（而不是寫死在原始碼裡），以及 profile-update 端點有沒有加上 current_user_can() 之類的身份比對邏輯，這兩點沒改到，就算版本號跳了也不建議重新啟用 🧐

🧑‍🔧 DevOps 小知識：Checksum 這次沒辦法拿來當第一線防禦
如果你嘗試對這款外掛執行 wp plugin verify-checksums uix-usercenter，因為它已經從 WordPress.org 下架，WP-CLI 官方文件說明這項指令依賴的是 WordPress.org 提供的官方 checksum 資料，來源沒了，這個指令大概率會回報無法取得 checksum，而不是「驗證通過」。這其實也是判斷外掛下架狀態的旁證之一，但不能拿它來確認檔案有沒有被動過手腳 ⚙️

🛟 真的出事了怎麼救？從「先止血」一路走到「確認關門」

前一節解決的是「怎麼判斷」，這一節進入真正的維運 Runbook。跟一般漏洞的 SOP 比起來，這次有一個關鍵不同：「更新」這個選項從一開始就不存在，所以整套流程要把原本的「更新」階段，直接換成「徹底移除＋替代方案部署」👇

🔥 這裡最重要的閉環：
判斷環境 → 盤點 → 備份 → Dry-run（移除影響評估） → 移除＋替代方案 → 驗證。
「移除成功」不等於整件事結束，還要回頭確認有沒有殘留的入侵痕跡 💯

🚨 ㊀ A 情境：已中招／疑似中招，先止血再處理

如果第 3 節已經找到可疑管理員、異常 profile-update 請求或其他明確入侵跡象，處理順序跟「單純移除外掛」完全不同，第一件事是先留證，再動手 🎓

💠 單一網站：先建立事件狀態

決策原理：疑似入侵時，最大的敵人不是漏洞本身，而是在沒有留下證據的情況下直接清理，導致後續無法還原事件經過 🧐

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

mkdir -p "$INCIDENT_DIR"

{
    echo "=== Incident collection ==="
    date -Is
    echo "WP_PATH=$WP_PATH"

    wp --path="$WP_PATH" core version
    wp --path="$WP_PATH" plugin get "uix-usercenter" \
        --fields=name,status,version,update,update_version
    wp --path="$WP_PATH" user list \
        --role=administrator \
        --fields=ID,user_login,user_email,display_name,user_registered \
        --format=table
    wp --path="$WP_PATH" option get siteurl
    wp --path="$WP_PATH" option get home
} > "$INCIDENT_DIR/summary.txt" 2>&1

wp --path="$WP_PATH" cron event list \
    --fields=hook,next_run_gmt,recurrence \
    --format=csv \
    > "$INCIDENT_DIR/cron-events.csv"

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

echo "Incident evidence: $INCIDENT_DIR"

預期輸出：

Incident evidence: /home/admin/uix-incident-20260904_121500

分支判斷：證據已建立 → 進入止血（第 4 節 ㊁、㊃ 開始的移除流程）；如果是企業、電商或會員制網站，同步通知內部資安或維運負責人，並保留這份證據目錄供後續稽核或法遵佐證 🚫

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

決策原理：獨立多站的最大優勢就是隔離性，某一站疑似遭入侵時，先確認受影響網站，再依主機架構做站點級隔離，不要牽連沒有證據的其他站 📜

INCIDENT_PATH="/var/www/site-a/public_html"

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

分支判斷：確認路徑正確 → 對這一站套用單一網站的止血步驟；不要把整個 /var/www 當成單一網站處理 ⚠️

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

決策原理：Multisite 共用核心、外掛與 Network 資源，某個 Site 出現入侵跡象時，不能只處理那個 Site 就宣稱完成 🧧

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

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

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

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

分支判斷：任一 Site 出現明確入侵跡象 → 把整個 Network 納入事件調查範圍，因為外掛檔案是共用的 🚨

🧯 ㊁ B 情境：尚未確認中招，先做短期應急降低暴露面

短期應急的目標是縮短攻擊面暴露時間，替你爭取時間完成備份與移除影響評估，而不是取代移除這個最終目標 💯

🚨 短期應急 ≠ 正式處置。
因為這款外掛本來就沒有修補版本可以「等」，停用只能算是拖延，真正的處置終點只有一個：徹底移除並部署替代方案 🙅‍♂️

💠 單一網站：先停用，降低暴露面

決策原理：停用之後，WordPress 就不會再載入這個外掛的程式碼，等於先把大門鎖起來，再準備正式拆除 🎓

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

wp --path="$WP_PATH" plugin deactivate "uix-usercenter"

預期輸出：

Plugin 'uix-usercenter' deactivated.
Success: Deactivated 1 of 1 plugins.

分支判斷：

• 🟢 停用成功 → 立即進入第 4 節 ㊂ 備份，再往下走移除流程，不要停在這一步太久。
• 🟠 網站核心會員功能高度依賴它、擔心停用會直接讓註冊／登入頁面壞掉 → 先套用第 3 節 ㊄ 的 Web Server 層規則擋掉 action=profile-update 當緩衝，同時盡快安排移除與替代方案的維護窗口，不要無限期拖延。

❇️ 獨立多站：逐站應急，不要一次停掉整台伺服器的所有外掛

INCIDENT_PATH="/var/www/site-a/public_html"

wp --path="$INCIDENT_PATH" plugin deactivate "uix-usercenter"

分支判斷：只影響 Site A，不應連 Site B、Site C 一起停掉，除非它們也各自被盤點確認裝了這款外掛 🧧

✴️ Multisite：先確認是否 Network Activated

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

if wp --path="$WP_PATH" plugin is-active \
    "uix-usercenter" \
    --network; then
    wp --path="$WP_PATH" plugin deactivate "uix-usercenter" --network
    echo "Deactivated at Network level."
else
    echo "Not Network Activated, checking per-site status."
fi

分支判斷：Network Activated → 用 –network 一次停用即可影響全 Network；如果只在個別 Site 啟用，改用 –url=”$url” 逐站停用，兩者不能混用 ⚙️

💾 ㊂ 備份：移除前先留下可以回家的路

💠 單一網站：資料庫＋必要網站檔案

決策原理：移除外掛主要動的是 Plugin 檔案，但如果之後要重建會員相關設定，至少要有一份移除前的資料庫快照可以查閱比對 📊

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

tar -czf \
    "$BACKUP_DIR/example-com_wp-content_pre_uix_removal_${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_uix_removal_20260904_123000.sql'.
Backup completed:
/home/admin/wp-security-backup

分支判斷：SQL 與檔案備份都存在 → 進 Dry-run（移除影響評估）；任一備份失敗 → 停止，不進入正式移除 🚫

❇️ 獨立多站：每一個 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")"

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

    version="$(wp --path="$path" \
        plugin get "uix-usercenter" \
        --field=version 2>/dev/null || true)"

    if [ -z "$version" ]; then
        continue
    fi

    site_name="$(basename -- "$path")"
    db_file="$BACKUP_ROOT/${site_name}_pre_uix_removal_${STAMP}.sql"

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

    wp --path="$path" db export "$db_file"

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

分支判斷：某一站備份失敗 → 把該站標記為未完成，不要因為其他站成功就直接進入批次移除 🧧

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

決策原理：Multisite Site 並不是 N 個獨立 WordPress 安裝，對 Network 執行一次 wp db export 就能取得該 installation 使用的資料庫內容 📔

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

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

分支判斷：Database＋必要檔案備份成功 → 進 Dry-run（移除影響評估）；不需要因為有 20 個 Site 就 dump 20 次同一個 Network Database ⚙️

🧪 ㊃ Dry-run（移除影響評估）：先確認拔掉這顆外掛會不會連坐

💡 碎碎念：這裡刻意不寫 –dry-run
WP-CLI 官方文件裡，–dry-run 這個旗標只存在於 wp plugin update，wp plugin uninstall 跟 wp plugin delete 並沒有這個參數。與其寫一個實際上打不出來的假指令，不如改用底下這組「唯讀掃描」的方式，一樣能達到「先看會不會出事，再真的動手」的效果 🎓

💠 單一網站：檢查有沒有其他地方硬依賴這款外掛

決策原理：直接刪除外掛前，先確認 Theme 或其他 Plugin 有沒有寫死呼叫它的函式或類別，以及文章內容有沒有用到它的短代碼，避免移除後前台版面直接壞掉 📜

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

echo "===== 1. Theme／其他 Plugin 是否硬依賴 uix-usercenter 的函式或類別 ====="
grep -rIl \
    -e "uix_usercenter" \
    -e "UixUserCenter" \
    -e "uix-usercenter" \
    "$WP_PATH/wp-content/themes" \
    "$WP_PATH/wp-content/plugins" \
    --exclude-dir="uix-usercenter" \
    2>/dev/null

echo "===== 2. readme.txt 是否記載短代碼／Shortcode 名稱，先確認再去內容比對 ====="
if [ -f "$WP_PATH/wp-content/plugins/uix-usercenter/readme.txt" ]; then
    grep -i "shortcode" \
        "$WP_PATH/wp-content/plugins/uix-usercenter/readme.txt"
else
    echo "readme.txt not found, mark as 【❓待確認】"
fi

echo "===== 3. 目前外掛啟用狀態 ====="
wp --path="$WP_PATH" plugin get "uix-usercenter" --field=status

預期輸出（節錄）：

===== 1. Theme／其他 Plugin 是否硬依賴 uix-usercenter 的函式或類別 =====
（無輸出，代表沒有找到硬依賴）

===== 3. 目前外掛啟用狀態 =====
active

分支判斷：

• 🟢 沒有找到任何硬依賴、也確認沒有短代碼被大量使用 → 可以直接進入正式移除。
• 🟠 找到 Theme 或其他 Plugin 裡有呼叫它的函式／類別 → 先記錄清單，移除後要回頭確認這些呼叫點是否會產生 PHP Fatal Error，必要時先修改對應程式碼再移除。
• 🟡 readme.txt 找不到或找不到 Shortcode 說明 → 標示【❓待確認】，改用瀏覽器實際檢查前台會員相關頁面是否顯示異常空白區塊，作為替代確認方式。

❇️ 獨立多站：逐站做同樣的唯讀掃描

SEARCH_ROOT="/var/www"

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

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

    status="$(wp --path="$path" \
        plugin get "uix-usercenter" \
        --field=status 2>/dev/null || true)"

    if [ -z "$status" ]; then
        continue
    fi

    printf '\n===== DEPENDENCY SCAN: %s (status=%s) =====\n' "$path" "$status"

    grep -rIl \
        -e "uix_usercenter" \
        -e "UixUserCenter" \
        "$path/wp-content/themes" \
        "$path/wp-content/plugins" \
        --exclude-dir="uix-usercenter" \
        2>/dev/null
done

分支判斷：每站獨立判斷，某站找到硬依賴不代表其他站也有相同問題，逐站記錄再各自安排移除順序 🧧

✴️ Multisite：Network 層掃一次，再抽查重點 Site 的前台頁面

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

echo "===== Theme／Plugin 硬依賴掃描（Network 共用檔案） ====="
grep -rIl \
    -e "uix_usercenter" \
    -e "UixUserCenter" \
    "$WP_PATH/wp-content/themes" \
    "$WP_PATH/wp-content/plugins" \
    --exclude-dir="uix-usercenter" \
    2>/dev/null

echo "===== 各 Site 是否仍在使用中 ====="
wp --path="$WP_PATH" site list --field=url

分支判斷：Network 層沒有硬依賴 → 可以規劃統一時間點移除；有硬依賴 → 先確認是哪個 Site 專屬使用的功能，評估是否需要先做程式碼調整，再排入移除時程 ⚙️

🚀 ㊄ 正式處置：這次的「修補」是徹底移除，不是更新版本

⚠️ 安全提醒：在正式環境（Production）執行移除前，務必先於測試環境（Staging）驗證過一次，確認前台不會因為少了這個外掛而崩潰或顯示錯誤 🙅‍♂️

決策原理：因為這款外掛已被官方下架、信任度存疑，不建議依賴它自帶的 uninstall.php 清除流程（那段程式碼本身也來自同一個不再被維護的來源），改用 wp plugin delete 直接移除檔案更保守 🎓

💠 單一網站：先停用，再刪除檔案

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

wp --path="$WP_PATH" plugin deactivate "uix-usercenter"

wp --path="$WP_PATH" plugin delete "uix-usercenter"

預期輸出：

Plugin 'uix-usercenter' deactivated.
Success: Deactivated 1 of 1 plugins.
Plugin 'uix-usercenter' deleted.
Success: Deleted 1 of 1 plugins.

刪除完成後，務必再檢查一次資料夾是否真的消失：

PLUGIN_DIR="$WP_PATH/wp-content/plugins/uix-usercenter"

if [ -d "$PLUGIN_DIR" ]; then
    echo "WARNING: plugin directory still exists: $PLUGIN_DIR"
else
    echo "OK: plugin directory removed."
fi

分支判斷：

• 🏮 顯示 OK，資料夾已消失 → 進入 Checksum 驗證。
• 🟠 資料夾仍存在（通常是檔案權限問題）→ 先確認執行 wp 的系統使用者對該目錄有寫入權限，不要直接用 rm -rf 強制刪除，先確認備份完整再處理，且刪除前建議先把目錄改名隔離：

WP_PATH="/var/www/example.com/public_html"
PLUGIN_DIR="$WP_PATH/wp-content/plugins/uix-usercenter"
STAMP="$(date +%Y%m%d_%H%M%S)"

if [ -d "$PLUGIN_DIR" ]; then
    mv "$PLUGIN_DIR" "${PLUGIN_DIR}_quarantine_${STAMP}"
    echo "Moved to quarantine: ${PLUGIN_DIR}_quarantine_${STAMP}"
fi

先改名隔離能立即中斷任何依賴固定路徑的可疑呼叫，同時保留檔案供後續鑑識比對，確認乾淨後再視情況正式刪除 🧯

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

WP_PATH="/var/www/site-a/public_html"

wp --path="$WP_PATH" plugin deactivate "uix-usercenter"
wp --path="$WP_PATH" plugin delete "uix-usercenter"

wp --path="$WP_PATH" plugin get "uix-usercenter" \
    --field=status 2>&1 || echo "Confirmed: plugin no longer registered."

分支判斷：Site A 移除＋驗證成功後，再把同樣流程套到 Site B、Site C；不要「全部移除完最後才檢查」，一站一站確認前台正常再往下一站走 ⚙️

✴️ Multisite：外掛檔案只刪除一次，再逐 Site 驗證

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

wp --path="$WP_PATH" plugin deactivate "uix-usercenter" --network

wp --path="$WP_PATH" plugin delete "uix-usercenter"

echo "===== 逐 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 "uix-usercenter" \
        --field=status 2>&1 || echo "Confirmed: not active on this site."
done

分支判斷：外掛檔案只需要刪除一次；Site 層則逐一確認不再顯示為啟用狀態，避免某個 Site 的快取或設定殘留造成誤判 🧧

🔁 替代方案部署（三種環境皆適用）

移除完成後，如果網站本來就依賴這款外掛提供會員註冊／登入功能，記得同步安排替代方案，不要讓功能空一段時間沒人管：

• ⭐ 若只需要基礎會員註冊，可先評估 WordPress 原生的使用者註冊機制是否足夠（設定 → 一般 → 會員資格）。
• ⭐ 若需要更完整的個人資料頁、頭像上傳等功能，建議另外挑選目前仍在積極維護、更新紀錄正常的會員外掛替代，動手前先確認該外掛近期是否仍有版本釋出與安全性回應紀錄。
• ⭐ 替代方案上線前，務必在 Staging 環境完整測試註冊、登入、個人資料修改流程，確認沒有因為換了外掛而產生新的權限漏洞。

🔐 ㊅ Checksum 驗證：外掛已經不在了，改確認核心跟其他外掛沒被連坐

💠 單一網站

決策原理：外掛本體已經刪除，沒有檔案可以再驗證；這一步改成確認 WordPress 核心跟其餘仍在使用的外掛，有沒有在同一起事件中被順手動過手腳 🎓

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

echo "===== Core Checksum ====="
wp --path="$WP_PATH" core verify-checksums

echo "===== 其餘已安裝外掛 Checksum ====="
wp --path="$WP_PATH" plugin list --field=name |
while IFS= read -r plugin; do
    printf '\n--- %s ---\n' "$plugin"
    wp --path="$WP_PATH" plugin verify-checksums "$plugin" 2>&1
done

預期輸出：

Success: WordPress installation verifies against checksums.

--- akismet ---
Success: Verified 1 of 1 plugins.

分支判斷：

• 🟢 全部 Verified → 沒有偵測到其他外掛或核心檔案被竄改的跡象。
• 🔴 出現 Checksum mismatch → 不要忽略，代表有其他元件也可能被動過手腳，需要進一步比對該檔案內容是否遭植入惡意程式碼。
• 🟡 某些外掛顯示無法驗證 → 可能是該外掛不在 WordPress.org 官方目錄、或版本來源不同，不代表一定遭入侵，但建議手動檢查該外掛檔案的修改時間。

❇️ 獨立多站

SEARCH_ROOT="/var/www"

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

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

    printf '\n===== CORE CHECKSUM: %s =====\n' "$path"
    wp --path="$path" core verify-checksums
done

✴️ Multisite

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

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

Multisite 共用同一套 WordPress Core，因此同樣只需對 Network installation 驗證一次即可 📔

🧪 ㊆ 功能回歸測試：拔掉外掛後，該有的功能還活著嗎？

💠 單一網站

決策原理：移除成功不代表業務功能沒有一起壞掉，特別是原本掛在這個外掛上的註冊、登入、個人資料頁面 📜

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

wp --path="$WP_PATH" core is-installed

wp --path="$WP_PATH" plugin get "uix-usercenter" \
    --field=status 2>&1 || echo "Confirmed: uix-usercenter no longer installed."

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

預期結果：

• 🏮 WordPress 可正常載入
• 🏮 外掛確認已不存在
• 🏮 管理員清單沒有出現陌生帳號
• 🏮 前台首頁與會員相關頁面正常，沒有因為缺少外掛而顯示空白區塊或 PHP 錯誤
• 🏮 替代註冊／登入機制運作正常
• 🏮 PHP Error Log 沒有突然大量增加 Fatal Error

❇️ 獨立多站

採「一站一驗證」，Site A 完成確認後再處理 Site B、Site C：

WP_PATH="/var/www/site-a/public_html"

wp --path="$WP_PATH" core is-installed
wp --path="$WP_PATH" plugin get "uix-usercenter" \
    --field=status 2>&1 || echo "Confirmed: removed on $WP_PATH."

echo "Verification target: $WP_PATH"

✴️ Multisite

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

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

    wp --path="$WP_PATH" \
        --url="$url" \
        core is-installed

    wp --path="$WP_PATH" \
        --url="$url" \
        plugin get "uix-usercenter" \
        --field=status 2>&1 || echo "Confirmed: not active on this site."
done

分支判斷：任一 Site 出現錯誤 → 暫停批次流程，先處理該 Site，不要繼續擴大變更範圍 ⚠️

🔍 ㊇ 最後一輪 Log＋檔案複查：確認處置後沒有新的異常

💠 單一網站

LOG_FILE="/var/log/apache2/access.log"
UPLOADS="/var/www/example.com/public_html/wp-content/uploads"

if [ -f "$LOG_FILE" ]; then
    grep -Ei \
        'action=profile-update|uix-usercenter' \
        "$LOG_FILE" |
    tail -n 50
fi

find "$UPLOADS" -type f \
    \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.php*" \) \
    -print

分支判斷：移除後仍持續出現對 action=profile-update 的請求或新的可疑檔案 → 不要把它當成「已經處理好所以沒事」，應回到第 4 節 A 情境重新啟動事件調查 🚫

❇️ 獨立多站

逐站執行同樣檢查，結果一定要保留網站路徑：

SEARCH_ROOT="/var/www"

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

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

    printf '\n===== POST-REMOVAL CHECK: %s =====\n' "$path"

    find "$uploads" -type f \
        \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.php*" \) \
        -print 2>/dev/null
done

✴️ Multisite

WP_PATH="/var/www/network/public_html"
UPLOADS="$WP_PATH/wp-content/uploads"

find "$UPLOADS" -type f \
    \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.php*" \) \
    -print

分支判斷：任何處置後新增的可疑檔案，都應回到「事件應變」而不是單純認定已經處理完成 🚨

🧾 ㊈ 最終驗收：這 6 格全部打勾，才算真正收工

✅ 完成標準：不是「檔案刪除成功」就算結束，而是備份可用、核心 Checksum 正常、沒有新的可疑檔案／帳號／Log，替代方案已經上線，前台與後台功能也都正常運作 👍

🔥 最後一句話：這起事件真正值得留下來的 DevOps 經驗，是當某個外掛連「更新」這個選項都不存在時，你的 SOP 要能立刻切換成「移除＋替代方案」這條路徑，而不是卡在原地等一個可能永遠不會出現的修補版本。判斷環境 → 盤點 → 備份 → 移除影響評估 → 移除＋替代方案 → 驗證，這套方法即使下一次遇到別的完全沒有修補版的外掛，一樣可以直接照搬使用 🎓

🫂 新手求助：完全看不懂上面這些指令怎麼辦？
如果你不熟悉 WP-CLI 或伺服器操作，最快的方式是直接聯繫你的主機代管商或網站維護廠商，請他們協助確認外掛是否存在並執行刪除。多數台灣主機商都提供技術支援管道，遇到資安緊急事件不用不好意思開口求助 ⛑️

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

🔥 CVE-2026-16259 是一個非常極端的案例：它不像大多數漏洞那樣可以靠「更新版本」解決，因為官方根本沒有給出任何解藥。這起事件最大的提醒是：選用第三方外掛時，「這款外掛還有沒有人在維護」跟「這款外掛功能好不好用」同樣重要，甚至更重要 🔑

如果你的網站剛好裝了 Uix UserCenter，請不要猶豫，這不是一個值得等待官方修補的漏洞，因為官方修補可能永遠不會來 ⛑️

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

• ❶ 登入後台「外掛」→「已安裝的外掛」，確認是否存在 Uix UserCenter
• ❷ 若存在，先點擊「停用」，網頁重新整理後再點擊紅色的「刪除」，確保檔案徹底移除
• ❸ 使用原生 WordPress 註冊機制或其他仍在積極維護的第三方外掛，替代原本的會員功能
• ❹ 全面盤查 wp_users 資料表，確認沒有多出不明的 Administrator 帳號
• ❺ 為所有管理員帳號啟用雙重驗證（2FA），並強制重設密碼，建立第二道防線

📚 參考資料與延伸資源

• 📌 CVE.org 官方紀錄：CVE-2026-16259
• 📌 OpenCVE：CVE-2026-16259 漏洞詳情
• 📌 IONIX Threat Center：CVE-2026-16259 身分驗證繞過／管理員帳號接管
• 📌 WPScan 漏洞資料庫：Uix UserCenter <= 1.0.3 未經授權特權提升
• 📌 Strix AI CVE 資料庫：CVE-2026-16259 權限提升
• 📌 WordPress.org 外掛目錄：Uix UserCenter（已封存資料）
• 📌 Feedly 威脅情資：CVE-2026-16259 公告
• 📌 Freshy Security Bulletins：Uix UserCenter WordPress 外掛漏洞公告