🚪 免密碼直接刷卡當總幹事？WordPress 熱門外掛 Authorizer 爆出近乎滿分的提權漏洞

🔥 懶人包先講重點：
WordPress 上專門處理「權限管理＋SSO 單一登入」的知名外掛 Authorizer，被抓到一個嚴重到 CVSS 評到 9.8 分（滿分 10 分）的未授權權限提升漏洞（CVE-2026-81294）。可怕的地方不是駭客技術多高超，而是他們完全不需要你網站的任何帳號密碼，光靠遠端發送一個特製請求，就能讓系統誤發一張「網站最高管理員」的通行證。如果你的網站有裝這款外掛，且版本號還停在 3.15.1 以下，建議把這件事排進今天的第一順位，立刻升級到 3.15.2 以上 🚨

先問你一個問題：如果有一套大樓門禁系統，理論上只有刷過合法識別證的人才能進去，結果有人發現「其實你根本不用刷卡，只要對感應器講一句特定的暗號，門禁系統就會自動印一張總幹事等級的識別證給你」——這種漏洞你覺得嚴重嗎🤔？這正是這次 Authorizer 外掛出包的狀況，而且它偏偏又是一款專門負責「守大門」的角色，這種反差感格外諷刺。

🌐 前往 WordPress 官方外掛頁面確認版本 ^[33]

^[34]

---

🏢 第一章：把你的網站想成一棟大樓，門禁系統壞掉到底有多可怕？

在資安圈，這種手法有個專有名詞叫「未授權權限提升」（Unauthenticated Privilege Escalation）。白話翻譯就是：對方不用先偷到你的鑰匙，也不用假冒任何一個已經存在的帳號，系統就自己把最高權限雙手奉上。這跟一般「密碼被猜中」或「帳號被盜」的邏輯完全不同——你就算把所有員工的密碼都設得又長又複雜，這道防線一樣擋不住，因為問題根本不在密碼強不強，而是門禁機本身的判斷邏輯壞掉了 😥

💡 碎碎念：Authorizer 最紅的功能，其實就是這次捅出簍子的地方
Authorizer 這款外掛之所以在校園、企業內部網站圈子人氣很高，主要就是因為它支援用 Google、GitHub 或學校內部帳號直接登入 WordPress，這類技術統稱 SSO（單一登入）或 OAuth2。你可以把它想成一張「悠遊卡」——同一張卡不只能搭捷運，還能在超商買東西、租借 YouBike。方便是真的方便，但前提是驗票機必須先確認這張卡「真的屬於刷卡的這個人」；如果驗票機偷懶沒有仔細核對身分，就很容易把路人誤認成 VIP 貴賓 🎫

那 CVSS 9.8 這個分數到底代表什麼等級的嚴重程度呢？資安圈習慣用 CVSS（通用漏洞評分系統）幫漏洞打分數，滿分 10 分。拿到 9.8 分，大概就像颱風分類裡的「強烈颱風」等級——代表這個漏洞同時符合好幾個最危險的條件：攻擊者不需要在你的網站有任何帳號（免登入）、不需要騙你點擊任何連結（無須互動）、而且能直接透過網際網路遠端發動，完全不用摸到你的伺服器一根汗毛 🌀

^[35]

---

⏱️ 第二章：從被抓包到補丁上線，中間到底發生了什麼事？

這起事件的時間軸走得算是相當緊湊，我們攤開來看一下整個流程，你會發現這其實是一次「教科書等級」的漏洞通報處理範例：

從發現到補丁上線，中間只花了不到兩週，這個處理速度算是相當不錯的示範。不過真正該留意的，其實是後半段——✅ 根據 Patchstack 與多方資安情資的說法，截至目前尚未觀察到大規模的攻擊災情；但🟡合理推論是，既然漏洞細節與 CVE 編號都已經公開，針對性的自動化攻擊程式（PoC）很可能會在接下來一段時間內陸續現蹤，這種「風平浪靜」的空窗期，往往才是最適合搶先把補丁補起來的黃金時段 ⏳

^[36]

---

😨 第三章：如果我的網站真的中招，實際上會發生什麼事？

跟很多「要先騙到密碼才有事」的漏洞不同，這次的威脅模型完全跳過了帳號密碼這一關。我們照事實的確定程度，一層一層拆給你看：

🚨 畫重點！千萬別踩雷：
這裡最容易被誤解的一點是——很多人以為「駭客要先猜到我的密碼」才會出事，但這次的漏洞根本不需要密碼這一關。就算你的密碼設得再長再複雜，這道防線一樣沒有用武之地，因為壞掉的是門禁機本身的判斷邏輯，不是鎖頭 🔐

^[37]

---

🎭 第四章：先別急著慌，看看你屬於哪一種情境

看到這裡如果心裡開始發毛也很正常，先深呼吸——不同身分該做的事情差很多，我們一個一個來看你最接近哪一種 🌬️

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

如果你平常的工作是寫文章、上架商品、回客服訊息，完全不碰程式碼跟後台底層設定，那麼你要做的事情其實非常單純，跟著下面幾個步驟一步一步來就好，不需要先變成資安專家才能自救：

• ㊀ 先去哪裡看？登入你的 WordPress 網站後台，在左側選單找到「外掛（Plugins）」，點進去之後選「已安裝的外掛（Installed Plugins）」，你會看到一整排清單。
• ㊁ 怎麼判斷有沒有中鏢？在清單裡找一個名字叫 Authorizer 的外掛。如果找不到，代表你完全不受影響，可以先鬆一口氣。如果有找到，看它名字旁邊或下方標示的版本號碼，如果數字是 3.15.1 或更舊（例如 3.15.0、3.14.x 等），就代表你目前正暴露在風險之中。
• ㊂ 要更新到哪一版才安全？如果版本偏舊，通常在外掛名稱下方會出現一行提示「有新版本可用」，直接點一下「立即更新（Update Now）」就好，等它跑完後重新整理頁面，確認版本號已經變成 3.15.2 以上即可。
• ㊃ 會不會讓網站壞掉？這次的更新主要修的是安全性邏輯，沒有大幅改動外觀或功能，通常不太會讓網站跑版或當機。不過如果你的網站規模比較大、平常也很少更新東西，建議先請懂技術的同事幫忙備份一次資料庫，會更安心一點。
• ㊄ 看不懂或不敢按怎麼辦？如果你在後台裡完全找不到上面說的選單，或是網站其實是外包給網頁設計公司代管，最快的方法就是把這篇報告的網址直接轉傳給你的 IT 負責人或接案工程師，跟他說「這個外掛有嚴重的安全性問題，麻煩幫我檢查並更新」，這真的不是你一個人要扛的事，找人幫忙很正常 🤗

🫂 新手求助：完全看不懂「外掛」「版本號」這些詞怎麼辦？
沒關係，這篇報告本來就不是要考你資安證照。如果你連「已安裝的外掛」這個選單長什麼樣子都找不到，最保險的做法就是截圖後台畫面，附上這篇文章連結，一起傳給你的網站維護團隊或主機商客服，多數台灣的主機代管業者都有提供這類技術支援管道 📚

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

如果你身兼多職，同時要顧好幾個網站，光靠手動一個一個點後台檢查太沒效率了，這種情況下用 WP-CLI 批次盤點會實際很多，後面的技術深潛篇會給你可以直接複製貼上使用的指令，建議直接跳到那一段 👇

🩵 荷包試算：修這個漏洞本身要花多少錢？
好消息是，升級外掛版本本身完全免費，只要有後台或 SSH 權限就能自己動手，不需要額外訂閱付費版功能。真正會花到錢的地方，通常是「已經中招之後」——請資安顧問做鑑識、清除後門、重建客戶信任的工時費用，這筆帳怎麼算，都比現在花十分鐘點更新划算很多 💸

🏢 我的網站有會員資料，或是牽涉到公司內部系統

如果你的網站串接了公司內部帳號系統，或是牽涉到會員個資、學校師生帳號，這件事就不只是「更新一個外掛」這麼簡單了，因為它同時牽涉到資料外洩的通報責任。一旦被證實曾經有未授權存取的紀錄，企業或機構面對的往往不只是商譽受損，還有主管機關的裁罰與客戶信任的流失。除了更新之外，建議同步啟動內部的資安事件應變流程，把稽核日誌留存下來，之後不管是要跟保險公司對帳、還是配合調查，都用得上這些紀錄 🩺

🚨 這個情境最容易被忽略：那個「裝好就沒再理過」的登入外掛

🚥 劃重點：跟前面 CVE 系列文章提過的「久沒用不等於沒風險」是一樣的道理——只要外掛還在啟用清單裡，就算你幾乎沒去動過它的設定頁，攻擊者依然找得到門路，這正是這類漏洞最容易被忽略的地方 🙅‍♂️

^[38]

---

🤿 第五章：技術深潛篇——地基到底是哪裡出問題？

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

🧑‍🔧 DevOps 小知識：把 CVSS 向量拆成白話，你會發現這幾乎是「地獄級」組合
AV:N（Attack Vector: Network）代表攻擊者只要有網路就能發動，不用碰到你的伺服器；AC:L（Attack Complexity: Low）代表不需要什麼特殊條件配合就能得手；PR:N（Privileges Required: None）代表連一個最低權限的訂閱者帳號都不用有；UI:N（User Interaction: None）代表不用騙任何人點擊連結；最後 C:H/I:H/A:H 則代表機密性、完整性、可用性全部遭受最高等級破壞。這六個條件同時成立，正是這道漏洞會被打到 9.8 分幾乎滿分的原因 ⚙️

根據外掛官方的更新紀錄與 Patchstack 釋出的通報，這個漏洞的成因出在處理外部 OAuth2（尤其是 GitHub 等身分提供者）回呼時，身分驗證與權限指派邏輯出現缺陷。在 3.15.1 以及更早的版本中，外掛在接收到 OAuth2 提供者傳回的授權回應時，並未強制驗證回傳的電子郵件屬性（例如 email_verified 這個標記）。這讓攻擊者能夠偽造一個未經驗證的電子郵件地址，並把它跟目標網站上既有的管理員帳號串在一起 😥

更關鍵的一點是，官方修補日誌特別提到：「先前版本的 Authorizer 允許所有有效的管理員登入成功，即使他們不在 Authorizer 的核准清單（Approved List）中」。把這幾條線索兜在一起，我們可以🟡合理推論，外掛程式碼在驗證身分之後，直接把 Session 的權限指派給了對應帳號，卻跳過了「這個帳號到底有沒有內部存取資格」這道二次核對——這正是典型的 CWE-266 錯誤，讓攻擊者能在完全未授權的狀態下，靠偽造的資料欺騙系統，直接拿到 Administrator 權限 🎯

💡 碎碎念：SSO 圈子裡有個專有名詞叫「帳號預先劫持」
近年的資安研究常提到一種手法叫「Account Pre-hijacking（帳號預先劫持）」——當依賴方（像 WordPress）過度信任身分提供者傳來的未驗證信箱時，攻擊者可以提前在身分提供者那邊搶先註冊受害者的信箱。等真正的受害者哪天想用 SSO 登入時，系統反而會把他跟攻擊者早就準備好的憑證綁在一起。這提醒我們，越方便的整合工具，背後往往藏著越深的信任邊界問題 🕳️

^[39]

---

🎯 第六章：駭客到底怎麼一步一步偷走你的管理員權限？

為了幫助防禦工程的部署，我們需要理解攻擊者怎麼利用這個漏洞，以及成功利用後系統狀態會怎麼變化。整條攻擊鏈其實邏輯相當簡潔：

• 🏮 攻擊鏈路始於對暴露在網際網路上的 WordPress 網站進行探測，確認站點運行著存在弱點的 Authorizer 版本。
• 🏮 接著攻擊者會向 WordPress 特定端點（例如 /wp-admin/admin-ajax.php 或是與 OAuth 相關的 REST API 端點）發送精心構造的 HTTP POST 請求，裡面夾帶了偽造的 OAuth2 屬性或角色參數（例如把目標使用者 ID 指向 1，並把角色設定為 administrator）。
• 🏮 由於外掛缺乏對 email_verified 屬性的強制校驗，加上 nonce 驗證不夠嚴密，系統會直接採信這筆輸入，隨即為攻擊者核發具備管理員權限的 Session Cookie，整個過程完全不需要任何有效憑證，也不需要跟受害者有任何互動。

^[40]

---

🕵️ 第七章：資安排查 Checklist——DevOps 到底該怎麼確認自己中招沒？

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

如果你是自己管 VPS、同時顧著好幾個 WordPress，這一節最重要的不是「背一條神奇的萬用迴圈」，而是先搞清楚自己到底是哪一種 WordPress 架構——搞錯架構，後面的批次指令就算語法完全正確，也可能對錯了對象，甚至造成檔案擁有權錯亂。這一節會依序走過環境判斷 👉 盤點（版本比對）👉 Log 日誌排查 👉 後門檢查點 👉 加固檢查五個關卡，每一關都拆成「決策原理 👉 具體指令 👉 預期輸出範例 👉 分支判斷邏輯」四個段落，並且分別涵蓋單一網站、獨立多站、Multisite 三種環境。所有牽涉到檔案路徑的變數，都會統一用雙引號包覆，避免路徑裡萬一含有空格或特殊字元時指令直接斷裂 📜

🧑‍🔧 DevOps 小常識：先判斷地圖，再決定走哪條路
「一台伺服器上塞了 10 個獨立的 WordPress」跟「一個 WordPress Multisite 底下有 10 個 Site」看起來很像，實際上是完全不同的架構。前者應該逐一找到每個網站的 wp-config.php；後者才應該使用 wp site list 這類 Network 專用指令，兩者的資料範圍與權限模型完全不同 🫠

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

決策原理：獨立多站（多個各自獨立的 wp-config.php）跟 Multisite（單一 wp-config.php 透過資料庫區分多個虛擬子站）光看外觀很難分辨，判斷錯誤會讓後續盤點、Log 排查、備份、更新全部跑偏，因此必須先用官方指令確認，而不是憑印象猜 🤔

cat << 'EOF' > detect_wp_env.sh
#!/bin/bash
echo "開始進行 WordPress 架構判定..."

# 檢查當前目錄是否為 WordPress 核心安裝目錄
if wp core is-installed --allow-root 2>/dev/null; then
    # 進一步判定是否啟用了 Multisite 網路功能
    IS_MULTISITE="$(wp core is-installed --network --allow-root 2>/dev/null && echo "YES" || echo "NO")"
    if [ "$IS_MULTISITE" == "YES" ]; then
        echo "[結論] ✴️ 偵測為 Multisite 架構"
    else
        echo "[結論] 💠 偵測為單一網站架構"
    fi
else
    # 尋找伺服器下是否存在多個獨立的 wp-config.php 檔案
    SEARCH_ROOT="/var/www"
    WP_COUNT="$(find "$SEARCH_ROOT" -name "wp-config.php" 2>/dev/null | wc -l)"
    if [ "$WP_COUNT" -gt 0 ]; then
        echo "[結論] ❇️ 偵測為獨立多站架構 (共尋獲 $WP_COUNT 個獨立站點)"
    else
        echo "[結論] 未尋獲任何有效的 WordPress 安裝。"
    fi
fi
EOF
bash detect_wp_env.sh

預期輸出範例：

[結論] ❇️ 偵測為獨立多站架構 (共尋獲 3 個獨立站點)

分支判斷邏輯：輸出結果決定接下來所有排查與修補步驟該怎麼走。若顯示「💠 單一網站」，請照著 💠 標籤的指令做；若為「❇️ 獨立多站」，改用 ❇️ 標籤的迴圈腳本，並用 sudo -u “$owner” 動態切換身分，避免用 root 身分產生快取或日誌檔，導致後續網頁伺服器（如 Nginx／Apache）遭遇權限不足的 500 錯誤；若為「✴️ Multisite」，則所有指令都要附加 –network 參數 🧭

^[41]

---

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

決策原理：盤點時不應該依賴自己記憶或寫死的版本號，而是透過 WP-CLI 動態抓取現有版本與線上提供的更新版本（update_version），以此評估風險狀態。對於獨立多站環境，必須動態取得各資料夾的實際擁有者（stat -c ‘%U’），並以 sudo -u 切換身分執行，這是為了避免以 root 身分產生的快取檔或日誌檔，日後反而讓網頁伺服器帳號因為權限不足噴出 500 錯誤 ⚙️

💠 單一網站：

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

wp --path="$WP_PATH" plugin list --name=authorizer \
    --fields=name,status,version,update_version --format=table

❇️ 獨立多站：

cat << 'EOF' > inventory_plugins.sh
#!/bin/bash
echo "開始跨站點盤點 Authorizer 外掛版本..."

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

    echo "----------------------------------------"
    echo "站點路徑: $path (執行身分: $owner)"

    sudo -u "$owner" -- wp --path="$path" plugin list --name=authorizer \
        --fields=name,status,version,update_version --format=table 2>/dev/null ||
        echo "未安裝或查無此套件"
done
EOF
bash inventory_plugins.sh

✴️ Multisite：

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

wp --path="$WP_PATH" plugin list --name=authorizer --network \
    --fields=name,status,version,update_version --format=table

預期輸出範例：

+------------+--------+---------+----------------+
| name       | status | version | update_version |
+------------+--------+---------+----------------+
| authorizer | active | 3.15.0  | 3.15.2         |
+------------+--------+---------+----------------+

分支判斷邏輯：檢視輸出的 version 欄位。若版本小於或等於 3.15.1，或者無法明確辨識版本號（採保守防禦原則視為風險），就代表系統存在曝險，必須立刻推進到後面的應急處置流程；若版本已為 3.15.2 且 update_version 欄位為空，代表這個外掛目前處於安全狀態 ✅

💡 碎碎念：WP-CLI 在多站環境的隱藏地雷
很多管理員在獨立多站環境喜歡用 find 搭配 -exec 一次跑完所有站點的更新，但這種做法很容易讓伺服器短時間內冒出一大堆 PHP 行程，瞬間把記憶體吃光，直接引發 OOM（Out of Memory）當機。比較穩妥的做法是像上面這樣寫成迴圈，逐一處理並在每站之間留一點緩衝時間 🐢

^[42]

---

📊 ㊂ Log 日誌排查特徵：找「路徑＋時間＋結果」的組合，而不是等 404 才緊張

決策原理：目前官方並未全面公開實際的 PoC 攻擊載荷，因此我們依賴 CWE-266 與 OAuth 偽造漏洞的通用行為特徵來做日誌溯源。🟡合理推論攻擊者會頻繁存取 WordPress 的 API 端點（如 /wp-json/）或傳統的 Ajax 處理端點（/wp-admin/admin-ajax.php），並可能在錯誤日誌中留下與驗證失敗相關的異常紀錄 🎯

💠 單一網站：

cat << 'EOF' > analyze_logs.sh
#!/bin/bash
# 根據你的系統架構調整日誌路徑，這裡先嘗試 Nginx，找不到再退回 Apache 常見路徑
LOG_DIR="/var/log/nginx"
[ -d "$LOG_DIR" ] || LOG_DIR="/var/log/apache2"

if [ ! -d "$LOG_DIR" ]; then
    echo "LOG DIRECTORY NOT FOUND：請自行確認你主機的實際存取日誌路徑"
else
    echo "=== 掃描 Access Log：潛在的提權與 OAuth 利用特徵 ==="
    awk '($9 == "200" || $9 == "302") && $6 == "\"POST"' "$LOG_DIR"/access.log* 2>/dev/null |
        grep -iE "(/wp-admin/admin-ajax\.php|/wp-json/)" |
        grep -iE "(authorizer|role=administrator|user_id=1|email_verified)"

    echo "=== 掃描 Error Log：異常的驗證與加密錯誤 ==="
    grep -iE "(authorizer|invalid state|OpenSSL|spoofing|unauthenticated)" "$LOG_DIR"/error.log* 2>/dev/null
fi
EOF
bash analyze_logs.sh

❇️ 獨立多站：不要只查其中一站，這種漏洞如果存在於多個獨立 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 -iE "(/wp-admin/admin-ajax\.php|/wp-json/)" "$log" 2>/dev/null |
        grep -iE "(authorizer|role=administrator|user_id=1|email_verified)" || true)"

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

✴️ Multisite：Multisite 通常共用同一份 Web Server Log，因此排查時要把命中的時間點跟 wp site list –field=url 取得的 Site 清單對照，而不是只看 Plugin 有沒有啟用：

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

if [ -f "$LOG_FILE" ]; then
    grep -iE "(/wp-admin/admin-ajax\.php|/wp-json/)" "$LOG_FILE" |
        grep -iE "(authorizer|role=administrator|user_id=1|email_verified)"
fi

預期輸出範例：

=== 掃描 Access Log：潛在的提權與 OAuth 利用特徵 ===
198.51.100.45 - - [04/Sep/2026:14:32:01 +0800] "POST /wp-json/authorizer/v1/auth HTTP/1.1" 200 892 "-" "python-requests/2.25.1"
=== 掃描 Error Log：異常的驗證與加密錯誤 ===
[error] 12345#0: *6789 FastCGI sent in stderr: "PHP message: Authorizer: OAuth2 validation failed - unverified email spoofing attempt detected" while reading response header from upstream...

分支判斷邏輯：若腳本完全沒有輸出，代表目前沒有觀察到明顯的探測或利用行為，可以照正常排程進行修補；若發現大量來源不明的 IP 對上述端點發出成功的 POST 請求（HTTP 200／302），就要假設網站已經遭入侵，立刻跳到後面「A. 已中招／疑似中招情境」執行損害管控 🚦

^[43]

---

🕳️ ㊃ 後門檢查點：確認過版本沒問題，不代表沒被摸過

決策原理：未授權權限提升漏洞最麻煩的地方在於，駭客一旦拿到 Administrator 權限，就會盡量留下不易察覺的後門。常見手法包含寫入 mu-plugins（必須使用外掛，無法在後台輕易停用）、新增幽靈管理員帳號，或竄改 wp_options 資料表裡的核心設定 🔍

💠 單一網站：

cat << 'EOF' > check_backdoors.sh
#!/bin/bash
WP_PATH="/var/www/html"

echo "=== 檢查異常的 Administrator 帳號 ==="
wp --path="$WP_PATH" user list --role=administrator \
    --fields=ID,user_login,user_email,user_registered --format=table

echo "=== 檢查隱蔽的 Must-Use Plugins (mu-plugins) ==="
MU_PLUGINS="$WP_PATH/wp-content/mu-plugins"
if [ -d "$MU_PLUGINS" ]; then
    find "$MU_PLUGINS" -maxdepth 1 -type f -iname "*.php" -ls
else
    echo "無 mu-plugins 目錄"
fi

echo "=== 檢查近期被修改的 PHP 檔案 (過去 7 天內) ==="
find "$WP_PATH/wp-content" -type f -name "*.php" -mtime -7 -ls

echo "=== 檢查 wp_options 是否有被植入惡意 URL ==="
wp --path="$WP_PATH" db query \
    "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');"
EOF
bash check_backdoors.sh

❇️ 獨立多站：每一站都要各自檢查，結果要帶上網站路徑，不要看到 A 站乾淨就把 B、C 站一起視為安全：

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")"
    mu_plugins="$path/wp-content/mu-plugins"

    printf '\n===== %s (擁有者: %s) =====\n' "$path" "$owner"

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

    if [ -d "$mu_plugins" ]; then
        find "$mu_plugins" -maxdepth 1 -type f -iname "*.php" -ls
    else
        echo "（此站無 mu-plugins 目錄）"
    fi

    find "$path/wp-content" -type f -name "*.php" -mtime -7 -ls
done

✴️ Multisite：Multisite 環境的管理員身分要分兩層看——Network 層級的 Super Admin，跟個別 Site 層級的 Administrator，兩者權限範圍完全不同，且 mu-plugins 是整個 Network 共用一份，只要有一個 Site 被摸過，就要把整個 Network 都納入排查範圍：

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

echo "=== 檢查 Network 層級的 Super Admin 清單 ==="
wp --path="$WP_PATH" super-admin list

echo "=== 逐一檢查各 Site 的 Administrator 名單 ==="
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_email,user_registered --format=table
done

echo "=== 檢查 Network 共用的 mu-plugins ==="
MU_PLUGINS="$WP_PATH/wp-content/mu-plugins"
if [ -d "$MU_PLUGINS" ]; then
    find "$MU_PLUGINS" -maxdepth 1 -type f -iname "*.php" -ls
else
    echo "（無 mu-plugins 目錄）"
fi

預期輸出範例：

=== 檢查異常的 Administrator 帳號 ===
+----+------------+-------------------+---------------------+
| ID | user_login | user_email        | user_registered      |
+----+------------+-------------------+---------------------+
| 1  | original   | admin@site.com    | 2023-01-15 08:00:00  |
| 99 | support_wp | hacker@evil.net   | 2026-09-02 23:14:05  |  <-- 疑似後門帳號
+----+------------+-------------------+---------------------+
=== 檢查隱蔽的 Must-Use Plugins (mu-plugins) ===
-rw-r--r-- 1 www-data www-data 1024 Sep 03 01:22 wp-system-core.php  <-- 偽裝的惡意腳本

分支判斷邏輯：如果清單裡出現非團隊成員建立的管理員帳號，或是 mu-plugins 目錄裡冒出名稱可疑（如 wp-system-core.php）的未知檔案，代表防線已經被突破，必須立刻啟動資安事件應變流程；在 Multisite 環境下，這代表整個 Network 都要視為受影響範圍，不能只處理被發現的那個 Site 就宣稱結束 🚨

^[44]

---

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

決策原理：事前加固能有效限縮漏洞被利用後的損害範圍。限制 PHP 危險函數的執行權限，可以阻止攻擊者利用管理員身分進一步執行系統指令（RCE）；嚴格管控 wp-config.php 的檔案權限，則能保護資料庫連線字串不被輕易讀取 🔒

💠 單一網站：

cat << 'EOF' > hardening_check.sh
#!/bin/bash
WP_PATH="/var/www/html"

echo "=== 檢查核心設定檔的權限 (預期應為 640 或 440) ==="
stat -c "%a %U:%G %n" -- "$WP_PATH/wp-config.php"

echo "=== 檢查 PHP 危險函數是否已停用 ==="
php -i | grep disable_functions
EOF
bash hardening_check.sh

❇️ 獨立多站：逐站確認每一份 wp-config.php 的權限設定：

SEARCH_ROOT="/var/www"

find "$SEARCH_ROOT" -type f -name "wp-config.php" -print0 |
while IFS= read -r -d '' config; do
    path="$(dirname -- "$config")"
    printf '\n===== %s =====\n' "$path"
    stat -c "%a %U:%G %n" -- "$config"
done

echo "=== 檢查 PHP 危險函數是否已停用（依你的 PHP-FPM Pool 設定而定，多站若各自獨立 Pool 建議逐一確認） ==="
php -i | grep disable_functions

✴️ Multisite：Multisite 的 wp-config.php 只存在於 Network 根目錄一份，因此只需要檢查一次即可，不需要逐 Site 重複：

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

stat -c "%a %U:%G %n" -- "$WP_PATH/wp-config.php"
php -i | grep disable_functions

預期輸出範例：

=== 檢查核心設定檔的權限 (預期應為 640 或 440) ===
644 www-data:www-data /var/www/html/wp-config.php
=== 檢查 PHP 危險函數是否已停用 ===
disable_functions =>

分支判斷邏輯：上面這個範例輸出代表防護明顯過於薄弱。若 disable_functions 是空的，建議編輯 php.ini 加入 exec, passthru, shell_exec, system, proc_open, popen；若設定檔權限是 644 或更寬鬆，請立即執行 chmod 640 並確認擁有者與群組設定正確 ⚙️

^[45]

---

🧯 第八章：修不了先擋着——短期應急與正式修補三部曲

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

🚑 A. 已中招／疑似中招情境：先止血，再談修補

決策原理：當排查發現未知管理員或惡意檔案時，絕不能貿然直接刪除外掛或檔案，這樣會破壞數位鑑識的證據鏈，甚至可能觸發駭客埋設的「死亡開關」。正確順序是：立即隔離網路存取 👉 保存現狀取證 👉 銷毀現有連線與憑證 👉 清理後門 👉 進行修補 🧯

WP_PATH="/var/www/html"
EVIDENCE_DIR="/root/evidence_$(date +%F)"

# 1. 緊急取證：打包日誌、可疑檔案與資料庫快照
mkdir -p "$EVIDENCE_DIR"
tar -czvf "$EVIDENCE_DIR/logs.tar.gz" /var/log/nginx/ /var/log/apache2/ 2>/dev/null
tar -czvf "$EVIDENCE_DIR/mu_plugins.tar.gz" "$WP_PATH/wp-content/mu-plugins/" 2>/dev/null
wp --path="$WP_PATH" db export "$EVIDENCE_DIR/db_snapshot.sql"

# 2. 暫時性 Hotfix：強制刷新 Salts，這會立即登出所有已登入的使用者，中斷駭客的有效 Session
wp --path="$WP_PATH" config shuffle-salts

# 3. 隔離可疑檔案與帳號：先改名讓惡意腳本失效，再刪除惡意管理員（請將下方 ID 換成實際查到的帳號）
SUSPECT_FILE="$WP_PATH/wp-content/mu-plugins/wp-system-core.php"
if [ -f "$SUSPECT_FILE" ]; then
    mv -- "$SUSPECT_FILE" "$SUSPECT_FILE.suspect"
fi
wp --path="$WP_PATH" user delete <惡意帳號ID> --reassign=<合法管理員ID>

# 4. 停用受感染的 Authorizer 外掛，阻斷後續攻擊路徑
wp --path="$WP_PATH" plugin deactivate authorizer

預期輸出範例：

Success: Shuffled the salt keys.
Success: Removed user 99 from http://example.com.

分支判斷邏輯：確保上述證據都妥善保存在系統家目錄（如 /root）後，才能進入後面「C. 正式修補」流程。若刪除帳號時出現資料庫關聯錯誤，請確認 –reassign 參數指向的是正確且安全的現有管理員 ID。

🚨 不同架構的隔離範圍不一樣：
❇️ 獨立多站環境下，請只針對確認受影響的那一站執行上述隔離動作，不要因為緊張就把整台 VPS 上所有站台一起停用；✴️ Multisite 環境下，由於 mu-plugins 與 Super Admin 都是整個 Network 共用，只要有任何一個 Site 出現明確入侵跡象，就必須把整個 Network 視為事件範圍來處理 🧭

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

決策原理：企業環境的變更管理流程，可能要求在正式環境升級前，先在 Staging 環境測試幾天。在這段空窗期，我們可以在伺服器層面（如 Nginx／Apache／WAF）套用虛擬修補，透過封鎖特定端點的存取，降低被自動化腳本盲目掃射的機率 🛡️

Nginx 範例：

cat << 'EOF' > /etc/nginx/snippets/block_authorizer_cve.conf
# 阻擋對 Authorizer REST API 潛在弱點路徑的直接存取
location ~* ^/wp-json/authorizer/v1/ {
    deny all;
    access_log /var/log/nginx/authorizer_blocked.log;
    return 403;
}
EOF
# 將此 snippet 引入你的網站虛擬主機設定檔中，然後重新載入服務
nginx -t && systemctl reload nginx

Apache 範例（若你的環境使用 Apache 而非 Nginx）：

<LocationMatch "^/wp-json/authorizer/v1/">
    Require all denied
</LocationMatch>

預期輸出範例：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

分支判斷邏輯：套用規則後，自行嘗試訪問該路徑，若成功回傳 403 Forbidden，代表短期應急措施已生效。但這只是緩衝手段，後續仍需盡快安排時間進行正式修補 ⏸️

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

① 判斷環境

回到前面「㊀ 環境判斷」重新確認一次，先弄清楚自己的架構，再往下走。

② 盤點

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

③ 備份 (Backup)

決策原理：任何外掛升級都伴隨著讓網站崩潰的風險。不同架構需要不同的備份策略，特別是 Multisite，執行 wp db export 匯出的是整個網路共用的資料庫結構，而不是單一子站的資料 💾

💠 單一網站：

WP_PATH="/var/www/html"

wp --path="$WP_PATH" db export "backup_single_$(date +%F).sql"

❇️ 獨立多站：

SEARCH_ROOT="/var/www"
STAMP="$(date +%F)"

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

    printf '正在備份站點：%s (擁有者：%s)\n' "$path" "$owner"
    sudo -u "$owner" -- wp --path="$path" db export "$path/backup_${STAMP}.sql"
done

✴️ Multisite：針對 Network 執行匯出，這涵蓋了所有子站點的資料表（如 wp_2_options、wp_3_options 等）：

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

wp --path="$WP_PATH" db export "backup_network_$(date +%F).sql" --network

預期輸出範例：

Success: Exported to 'backup_network_2026-09-04.sql'.

分支判斷邏輯：備份完成後，務必用 ls -lh 檢查 .sql 檔案大小，若檔案是 0 Bytes，代表資料庫連線異常或磁碟空間已滿，嚴禁在這種狀態下繼續執行更新 🛑

④ 演練 (Dry-run)

決策原理：正式覆蓋檔案前，透過 WP-CLI 的 –dry-run 參數演練，可以確認伺服器能正常連線到 WordPress.org 的 API，並確認更新包相容性，且不會對現有檔案造成任何實質變更 🧪

WP_PATH="/var/www/html"

wp --path="$WP_PATH" plugin update authorizer --dry-run

預期輸出範例：

Success: Plugin 'authorizer' would be updated to version 3.15.2.

分支判斷邏輯：若輸出為 would be updated，代表演練成功，可以繼續正式更新；若輸出為 No plugins updated，代表目前已是最新版，或伺服器對外連線被防火牆擋住，需要先排除網路障礙。獨立多站環境建議先挑一個站點路徑測試即可，不用每站都跑一次 🔮

⑤ 更新 (Update)

決策原理：正式更新階段要嚴格遵守「停用 👉 更新 👉 啟用」的安全流程。❇️ 獨立多站切記不要用類似 find / -name wp-config.php -exec wp plugin update –all \; 這種一次全開的危險做法，這會讓伺服器瞬間產生大量併發行程，引發 CPU 與記憶體崩潰；正確做法是逐一進入站點處理，並在每站之間加入緩衝時間。✴️ Multisite 則因為 Plugin 檔案在伺服器上只有一份，不論網路內有幾個子站，只需要執行一次更新，所有子站就會共用這個安全版本 🎛️

💠 單一網站：

WP_PATH="/var/www/html"

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

❇️ 獨立多站（安全批次更新腳本）：

cat << 'EOF' > safe_update.sh
#!/bin/bash
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")"

    echo "正在處理站點: $path ..."
    sudo -u "$owner" -- wp --path="$path" plugin deactivate authorizer
    sudo -u "$owner" -- wp --path="$path" plugin update authorizer
    sudo -u "$owner" -- wp --path="$path" plugin activate authorizer
    sleep 2  # 緩衝伺服器 I/O 壓力，避免 OOM
done
EOF
bash safe_update.sh

✴️ Multisite：

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

wp --path="$WP_PATH" plugin update authorizer --network

預期輸出範例：

Success: Updated 1 of 1 plugins.
Plugin 'authorizer' activated.

分支判斷邏輯：若更新過程中出現 Download failed. Unauthorized，請確認伺服器硬碟空間是否足夠，或外掛目錄 wp-content/plugins/ 的擁有權是否被誤設成 root。獨立多站環境建議第一批只先處理一到兩站，確認沒有相容性問題後再繼續往下推進 🚶

⑥ 驗證 (Validation)

決策原理：更新完成後，必須做三層次的深度驗證，確保漏洞已修補、系統沒有殘存威脅。特別要強調 Checksum 驗證的侷限性：WP-CLI 的 verify-checksums 只能證明「官方版本清單裡有登記的檔案沒有被竄改」，但如果駭客建立了一個清單外的全新檔案（例如 wp-content/plugins/authorizer/evil-shell.php），Checksum 機制會直接忽略它，無法證明整站沒有後門，因此功能測試與惡意程式掃描依然不可省略 🔍

💠 單一網站：

cat << 'EOF' > validate_all.sh
#!/bin/bash
WP_PATH="/var/www/html"

echo "=== 第一層：確認版本號是否達標 ==="
wp --path="$WP_PATH" plugin get authorizer --field=version

echo "=== 第二層：核心與外掛檔案完整性 (Checksum) 校驗 ==="
wp --path="$WP_PATH" core verify-checksums
wp --path="$WP_PATH" plugin verify-checksums --all
EOF
bash validate_all.sh

❇️ 獨立多站：逐站驗證，結果保留路徑方便比對，任何一站出現 mismatch 就先暫停該站的自動化排程，避免可疑檔案被排程覆寫掉，干擾後續鑑識：

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

    printf '\n===== %s =====\n' "$path"
    sudo -u "$owner" -- wp --path="$path" plugin get authorizer --field=version
    sudo -u "$owner" -- wp --path="$path" plugin verify-checksums authorizer
done

✴️ Multisite：Plugin 檔案與 Core 檔案屬於同一個 WordPress installation，只需要驗證一次：

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

wp --path="$WP_PATH" plugin get authorizer --field=version
wp --path="$WP_PATH" core verify-checksums
wp --path="$WP_PATH" plugin verify-checksums authorizer

預期輸出範例：

=== 第一層：確認版本號是否達標 ===
3.15.2
=== 第二層：核心與外掛檔案完整性 (Checksum) 校驗 ===
Success: WordPress installation verifies against checksums.
Success: Verified 12 of 12 plugins.

第三層：前後台功能驗證（人工介入）

• ⭐ 開啟瀏覽器的「無痕視窗」
• ⭐ 嘗試訪問網站首頁，確保沒有出現 PHP Fatal Error 或版面跑版
• ⭐ 嘗試用正常的 SSO 或一般帳號登入後台，確認 Authorizer 的攔截與驗證機制依然正常運作

分支判斷邏輯：如果 Checksum 校驗出現 Warning: File doesn’t verify against checksum，強烈暗示核心檔案已被竄改，請不要忽視。這種情況下必須捨棄現有檔案，直接從 WordPress 官方下載乾淨的核心安裝包覆蓋，並啟動全面性的惡意程式掃描 🔬

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

^[46]

---

📚 第九章：舉一反三——這類漏洞背後的通用防禦心法

這次的 CVE-2026-81294 本質上屬於 CWE-266（錯誤的權限分配），且高度牽涉到 SSO 與 OAuth2 的信任邊界問題。以下是防禦這類身分驗證繞過漏洞的通用心法，就算下次換一個外掛、換一個 CVE，這套邏輯依然用得上：

• ⭐ 零信任的屬性映射：處理 SSO 或 OAuth2 回傳的資料時，系統絕不能輕易相信身分提供者傳來的標記。如果 IdP 回傳 email_verified=false 或根本沒有這個欄位，就應該強制阻斷登入，而不是直接放行並綁定本地帳號。
• ⭐ 實施最小權限原則：任何透過自動化流程（SSO、API 註冊）建立或登入的帳號，預設都應該只給最低權限（例如訂閱者），高權限角色的賦予應該嚴格限制由系統管理員在後台「人工手動」綁定審核，切斷程式碼邏輯出錯導致自動提權的可能。
• ⭐ 敏感路徑加一層獨立驗證：即便啟用了方便的 SSO 登入，對於試圖存取後台的行為，還是建議在 WAF 或獨立的安全性外掛上，疊加一層跟 SSO 脫鉤的多因素驗證，這樣就算權限分配邏輯被攻破，攻擊者也還有一道實體驗證要過。

💡 碎碎念：仲介式 SSO 也有自己的盲區
根據近年的資安研究，當網站透過「仲介服務」來整合 SSO 時，有相當高的機率面臨重新導向鏈遭惡意利用的風險。攻擊者常利用這類中介伺服器的驗證缺陷，發起未授權的資料存取或帳號接管——這提醒我們，越便利的整合工具，往往藏著越深層的信任邊界危機 🕳️

🤔 常見焦慮 QA 大解密

• 🏮 Q：按了更新，網站前台會不會突然跑版？
  A：Authorizer 這次的更新主要針對驗證邏輯做修補，沒有大幅改動前台外觀或版面結構，跑版的機率非常低。保險起見，動手前先備份一下資料庫，這永遠是不變的真理 💾
• 🏮 Q：外包廠商說「我們又沒在用 SSO 登入，不用管它」，能信嗎？
  A：建議不要照單全收，只要外掛還處於「啟用」狀態，攻擊者一樣能透過它取得管理員權限，跟你有沒有實際在用 SSO 功能沒有直接關係 🙅‍♂️

^[47]

---

🏆 第十章：事件綜合評分（10 分制，數字越高代表越正向）

🔥 這起事件其實給了所有網站經營者一個提醒：越是負責「守門」的角色，一旦它自己出了漏洞，殺傷力反而越大。與其等哪天真的出事才臨時抱佛腳，不如現在就花五分鐘，打開後台看一眼你的 Authorizer 版本號碼，這五分鐘可能就是你網站命運的分水嶺 🔢

---

🛠️ 附錄：安全使用守則速記

• ⭐ 立刻確認 Authorizer 版本，≤ 3.15.1 一律視為曝險
• ⭐ 升級到 3.15.2 或更新版本，且升級前務必先備份資料庫
• ⭐ 不論有沒有實際在用 SSO 登入功能，只要外掛還啟用著就有風險，該更新一樣要更新
• ⭐ 疑似中招時，先取證、刷新 Salt、隔離帳號與檔案，最後才是修補，順序不要顛倒
• ⭐ 敏感後台路徑建議疊加一層跟 SSO 脫鉤的獨立 MFA 驗證，降低單點失效的風險

^[48]

---

📚 參考資料與延伸資源

• 📌 Patchstack｜Authorizer 漏洞資料庫紀錄 ^[49]
• 📌 NVD｜CVE-2026-81294 官方詳情頁 ^[50]
• 📌 IONIX Threat Center｜CVE-2026-81294 漏洞分析 ^[51]
• 📌 WordPress.org｜Authorizer 外掛官方頁面與更新日誌 ^[33]
• 📌 BugsToday｜資安媒體報導 ^[52]
• 📌 CVE.org｜CVE-2026-81294 官方紀錄 ^[53]
• 📌 Delicious Brains｜WP-CLI 外掛管理教學 ^[54]
• 📌 Anchor Host｜WP-CLI verify-checksums 延伸應用 ^[55]
• 📌 Kinsta｜WP-CLI 搭配 WordPress Multisite 使用教學 ^[56]