🔓 你家「櫃檯人員」偷偷改了老闆的密碼？Amelia 預約外掛高危漏洞全解析（CVE-2026-77705）／CVSS 7.2

🔥 懶人包：
WordPress 熱門預約排程外掛 ameliabooking（官方全名 Booking for Appointments and Events Calendar – Amelia）在 2.4.10 之前的版本被抓到一個「授權檢查漏了一關」的問題（CVE-2026-77705，CVSS 7.2，🟠 高風險）。只要一個帳號擁有 Amelia 內部「客戶管理」或「員工管理」權限，就能把其他 WordPress 帳號（包含最高管理員）的密碼和 Email 直接改掉，等於不用偷鑰匙，用一張員工證就能開總經理辦公室的門。目前官方已釋出安全版本 2.4.10，尚未出現大規模野外攻擊，但這種「先拿到低權限、再往上翻牌」的套路，通常不會給你太久的觀望時間 🚦

🧊 冷知識：這款外掛的名字，是在跟一位傳奇飛行員致敬
Amelia 這個名字，社群普遍認為是致敬史上首位獨自飛越大西洋的女性飛行員 Amelia Earhart，開發團隊大概是想討個吉利，希望店家的預約業績能像飛機一樣「一路起飛」。只是這次的漏洞有點諷刺——如果身分驗證這顆螺絲沒栓緊，飛的不是業績，而是你網站的最高控制權，直接被別人劫走 ✈️

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

🕳️ 第一章：一個管「客人資料」的小權限，為什麼能改到老闆的密碼？

先問你一個問題：如果公司規定「只有總經理才能改任何人的識別證密碼」，但某天你發現，光是負責幫客人登記預約的櫃檯人員，居然也能悄悄把總經理的識別證密碼改掉——你會不會覺得這套門禁系統從一開始就設計錯了？這次 Amelia 外掛爆出的問題，剛好就是這齣戲 🎭

講白話一點，這個漏洞的官方分類叫 CWE-639（Authorization Bypass Through User-Controlled Key，中文常翻成「透過使用者可控鍵值繞過授權」），核心成因可以拆成三步（🟡 以下為根據 CVE 描述與 CWE 分類反推的合理推論，Amelia 官方尚未公開原始碼 diff 或 「概念驗證程式碼（PoC）」，《什麼是PoC❓你可以直接把它想成「作案教學影片」外流：原本要摸出這道漏洞的前提是你得懂技術、自己花時間摸索，現在等於有人已經把完整步驟拍成教學影片公開放上網，任何懂一點技術的人，都能照著片子依樣畫葫蘆，不用自己重新研究一次。》，實際程式邏輯可能更複雜）🏋️

• 🏮 系統先確認「你有沒有 Amelia 的客戶／員工管理權限」，這一關會過。
• 🏮 系統接著讀取你送出的那筆記錄（例如某個客戶的資料卡），並且找到它綁定的 WordPress 帳號 ID。
• 🏮 系統直接動手改這個帳號的密碼和 Email，卻沒有再問一句「你真的有資格改動這一個帳號嗎？」

就是這一個沒問的問題，讓漏洞有了可乘之機。用 WordPress 開發的黑話來說，正確做法應該是在修改帳號密碼之前，再呼叫一次 current_user_can(‘edit_user’, $target_user_id) 做「物件層級」的二次確認，但外掛在這一步顯然漏接了 🫣

🧊 碎碎念：飯店訂房比喻，一秒懂授權檢查漏在哪
你可以把這種漏洞想成一間飯店，櫃檯只檢查「你有沒有付錢」，卻沒有檢查「你付的錢對應的到底是哪一間房」。客人只要把房卡上的房號從 101 悄悄改成 999，系統照樣讓他刷卡進總統套房，因為飯店根本沒去比對「這張卡付的錢，是不是真的買了這間房」。這種「只信任使用者傳來的 ID」的設計盲點，在 WordPress 外掛世界特別常見，因為很多功能都是直接拿前端傳來的 ID 去資料庫撈資料，卻忘了先確認「這個人真的有權限碰這筆資料嗎」🔑

📅 事情怎麼被抓到的？時間軸攤開來看

把幾份資安情資交叉比對之後，目前可以拼出的輪廓大致如下（部分細節僅單一來源提及，會特別標註，跟大家說清楚哪些是多方確認、哪些還只是單一情資）🗞️

🧊 冷知識：CVE 編號已經衝上七萬多號，比十年前暴增超過十倍
CVE-2026-77705 這串數字裡的「77705」單純只是流水號，跟嚴重程度、發現順序完全無關。但這個數字本身蠻有意思的——2026 年才過九個月，全球公開的 CVE 編號就已經突破七萬七千號，對比十年前（2016 年）全年大概才六千多個，漏洞揭露的速度等於是十年間暴增超過十倍。這也代表著，網站管理員要盯的資安公告，只會越來越多，不會越來越少 📈

有一份情資來源指出通報者是資安研究員 Karthik Ramakrishnan，但這個名字目前只出現在單一來源，其餘兩份報告都沒有提及，這裡先標【❓待確認】，等後續有更多獨立來源交叉印證再視為確定事實。同樣地，「10 月 10 日公開 PoC」這個時間點也只有一份情資提到，如果你想抓緊修補視窗，不妨就把它當成一個提醒自己「最晚不能拖過這一天」的警報鐘 ⏰

🧊 冷知識：同一顆螺絲鬆掉不只一次
如果你覺得「權限檢查漏一關」聽起來很眼熟，你的直覺是對的。有情資提到 Amelia 在 2026 年稍早也曾爆出另一個性質相似的 IDOR 漏洞（CVE-2026-2931），同樣允許使用者更改他人密碼；另外還有一個更嚴重、CVSS 高達 9.8 且完全不用登入就能觸發的 CVE-2026-9055，據稱只要在 type 參數填入 manager、搭配 externalId=0，就能直接建立一個管理員等級的角色。以上兩則相關 CVE 目前僅見於部分情資、缺乏官方連結佐證，標【❓待確認】，但同一款外掛短時間內反覆出現「角色／權限判斷漏一關」的模式，本身就是一個值得留意的訊號——這類「物件層級授權檢查缺失」看來是預約類外掛的系統性痛點，而不是單一意外 🔁

🚑 第二章：先別慌，照「急診檢傷」的邏輯，看看你屬於哪一級

急診室有一套「檢傷分級」制度，來的人不是先到先看，而是先評估「誰的狀況最緊急」。這次的漏洞也很適合用同一套邏輯來想：不是每個裝了 Amelia 的網站都一樣危險，關鍵在於——你網站上「有多少人」握有 Amelia 的管理權限、這些人的帳號安不安全。我們先把風險攤開，再一一對照你可能是哪一種角色 🏥

📊 風險先拆三層，看清楚哪些是查證過的、哪些是推論

• 🏮 ✅ 已確認事實：擁有 Amelia 客戶或員工管理權限的使用者，可以直接改寫其關聯 WordPress 帳號的密碼與 Email，且攻擊向量標示為「不需使用者互動」，代表對方不用騙你點連結，只要有這個內部權限就能直接動手。
• 🏮 🟡 合理推論：如果你曾經把「預約經理」這種角色開放給店長、櫃檯人員甚至外包客服，而這些帳號的密碼強度不夠、或帳密曾在其他地方外洩被重複使用，攻擊者就能拿這把鑰匙去改動管理員帳號，接著直接用新密碼從登入頁大搖大擺走進去。
• 🏮 🔴 假設情境：萬一攻擊者拿到最高管理員權限之後，順手在後台裝一個看起來人畜無害的外掛當作後門、或是把客戶多年累積下來的電話與個資整包撈走，甚至在首頁埋一個導向詐騙網站的轉址，讓網站被搜尋引擎直接列入黑名單——這些都只是「有可能發生」，不代表已經發生，但確實是這類帳號接管漏洞最壞的下場。

🧊 冷知識：管理員帳號的 ID，幾乎永遠是「1」
WordPress 預設安裝完成後，第一個建立的最高管理員帳號，資料庫裡的編號幾乎都是「1」。很多鎖定 WordPress 越權漏洞的自動化掃描器，連帳號名稱都懶得猜，直接盲打 id=1 發動攻擊。這也是為什麼資安建議一致認為：架站完成後最好新建一個隨機命名的管理員帳號，再把預設的 ID 1 停用或降權，別讓自己變成那個「最好猜」的目標 🎯

🧭 對照一下，你比較接近哪一種身分

看到這裡別急著自己嚇自己，先花兩分鐘對照下面四種情境，找到你自己的位置，才知道接下來該用什麼節奏處理 🧩

🙋 一般輕量使用者（小型店家、個人工作室）

你可能就是老闆本人兼客服，網站只有你一個人碰後台，Amelia 用來讓客人自己線上約時間。這種情況下，你的曝險面其實不大——因為多半只有你一個帳號同時擁有 Amelia 管理權限跟 WordPress 管理員身分，攻擊者就算拿到你的員工帳號，改的其實也是你自己。但這不代表可以放著不管，畢竟外掛更新這件事完全免費，不用花一毛錢，點兩下就解決，沒有理由拖 💰

👨‍💻 獨立開發者／自架玩家（同時管好幾個客戶的站）

如果你手上顧著十幾個客戶的 WordPress，一個一個點後台更新真的會做到天荒地老。這種情況建議直接祭出 WP-CLI 批次盤點（下方的技術深潛篇會給你可以直接貼上用的指令），先抓出哪些站版本落後，再逐站處理，而不是憑印象猜哪個客戶的網站可能中招 🔍

🏢 企業商業用途（多人協作、有會員或金流資料）

如果你的網站牽涉到會員個資或線上收款，這件事就不只是「更新一個外掛」這麼單純了——一旦真的被證實資料外洩，企業面對的往往不只是商譽受損，還有主管機關的裁罰與通報責任。除了更新跟重置密碼，建議同步啟動內部的資安事件應變流程，把稽核日誌留存下來，之後不管是要跟保險公司對帳、還是配合調查，都用得上。而且這類企業通常會有多位員工帳號握有 Amelia 管理權限，權限盤點這一步千萬不能省 🩺

🚨 高風險誤用場景：權限開太寬又沒人記得收回

🚨 畫重點！千萬別踩雷：
「權限膨脹」（privilege creep）在中小企業特別常見——原本只是想讓某個員工方便處理日常預約，結果一路授權下來，這個帳號手上握的權限早就超出他實際需要的範圍。定期盤點「誰現在還握有 Amelia 管理權限」，比事後追查誰動了手腳容易得多，也便宜得多 🧹

🩹 第三章：完全不會寫指令也沒關係，五分鐘自救指南跟著點就對了

不管你剛剛對照出自己是哪一種身分，這一段的步驟建議每個人都先照著跑一遍——不用懂任何程式碼，跟著畫面點滑鼠就好 🖱️

• ㊀ 先去哪裡看版本？
  登入你的 WordPress 後台，點左側選單的「外掛」，再點「已安裝外掛」。在整串清單裡找名字叫「Booking for Appointments and Events Calendar」或後面帶著「Amelia」字樣的那一項，名稱正下方會標示目前的版本號碼 🔢
• ㊁ 看到版本號要怎麼判斷安不安全？
  如果版本號開頭是 2.4.9 或更舊（例如 2.4.8、2.3.x、1.x.x），代表你正暴露在這個風險裡；如果是付費 Premium 版，版本號可能已經跳到 8.x 或 9.x，這種情況判斷標準不太一樣，直接看官方 Changelog 有沒有寫「Resolved a security vulnerability」這句話，只要看到就代表那一版有修補到安全問題。判斷不出來的話，直接把版本號截圖，這一步先做到這裡就好 🖼️
• ㊂ 需不需要馬上更新？
  需要，而且優先程度排在今天所有代辦事項的第一位。直接在同一個畫面點「立即更新」按鈕，等它跑完，重新整理頁面確認版本號已經變成 2.4.10 以上（或最新版 Premium）即可 💪
• ㊃ 按了更新按鈕卻沒反應，或根本不敢按怎麼辦？
  如果你擔心更新會讓網站版面跑掉、或是按了半天沒動靜，不需要自己硬著頭皮排除，直接把這篇報告轉傳給你的網站維護工程師、外包商，或主機代管服務商，請他們優先處理這項更新，同時請他們順便檢查有沒有已經被入侵的跡象。找人幫忙是很正常的事，真的不用不好意思開口 🙇
• ㊄ 在完全確定安全之前，有沒有什麼可以先做的？
  有，而且這一步比更新還快——先去確認一下「誰目前握有 Amelia 的客戶／員工管理權限」。方法是回到後台的「使用者」選單，逐一檢查每個帳號的角色，看看有沒有已經離職、或平常根本不需要碰預約系統的人，還掛著這個權限沒有收回。發現有就先暫時降級，這比等更新跑完更能立即降低風險 🔐

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

🩵 荷包試算：這次修補，你一毛錢都不用花
Amelia 這次的安全更新，不管是免費版還是付費 Premium 版，官方都是直接把修補內容放進正常的版本更新裡，你不需要額外付費升級方案。真正會花到錢的地方，是「如果你拖到真的被入侵之後」——請資安顧問做鑑識、清除後門的工時，或是網站被搜尋引擎列入警示名單之後重建流量的成本，這筆帳，怎麼算都是現在花五分鐘點更新划算得多 💸

🔬 第四章：技術深潛篇——這道授權檢查，到底是在哪一步漏掉的？

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

🧑‍🔧 DevOps 小知識：CVSS 向量裡的 PR:H 不代表可以放鬆戒心
CVSS 向量裡的 PR:H 代表「攻擊者需要高權限」，這通常會讓分數往下修正——這也是為什麼同款外掛另一個「完全不用登入」的漏洞（CVE-2026-9055）CVSS 直接飆到 9.8，而這次只有 7.2。但 PR:H 這裡指的高權限，是「Amelia 內部的客戶／員工管理權限」，不是「WordPress 管理員權限」——這兩者差得非常遠，前者往往被輕易授予店長、櫃檯甚至外包客服。所以從防禦者角度，還是應該把這條漏洞當成「內部帳號一旦失守，就等於全站失守」在防，不能因為向量寫著 PR:H 就掉以輕心 🔓

有一份情資來源進一步推測了更具體的技術路徑：Amelia 為了串接排程系統與 WordPress 帳號，在自己的資料表裡保存了一個對應到核心 wp_users.ID 的外部關聯 ID（推測欄位名稱類似 externalId 或 wp_user_id）。當具備 Amelia 內部管理權限的角色送出「編輯客戶／員工資料」的請求時，後端很可能只核對了操作者是否具備 Amelia 自訂的權限旗標（例如 amelia_manage_customers），一旦通過這一關，就直接拿請求裡的外部關聯 ID 去呼叫 WordPress 核心的 wp_set_password() 與 wp_update_user()，卻沒有在呼叫前補上一次 current_user_can(‘edit_user’, $target_user_id) 的物件層級比對。🟡 這段推測目前沒有官方原始碼 diff 或公開 PoC 可以佐證，實際的攻擊端點與參數名稱可能與此不同，請把它當成「理解漏洞原理的示意」，而不是可以直接照抄的攻擊教學 🙅

🧊 冷知識：IDOR 這個詞，在資安圈的「戶籍」搬過一次家
「不安全直接物件參考」（IDOR）在 2007 年的 OWASP Top 10 裡，曾經獨占 A4 這個席位。但到了 2021 年版，資安社群認為 IDOR 本質上就是授權判定機制整體崩潰的其中一種表現，於是把它併進了「A01：Broken Access Control（權限控制失效）」這個更大的分類裡。時至今日，開發者依然很容易誤以為「能存取這個介面」就等於「能修改底下所有關聯資料」，這也是為什麼 IDOR 至今仍是 Web 應用程式漏洞排行榜上的常客 📈

🎯 攻擊者要怎麼走完這條路？（概念層級說明，非教學）

• 🏮 第一步：取得內部帳號。攻擊者需要先拿到一個具備 Amelia 客戶或員工管理權限的帳號，來源可能是外包維運、離職未回收的員工帳號，或密碼強度不足被暴力破解／撞庫成功的低權限帳號。
• 🏮 第二步：鎖定目標帳號 ID。🟡 合理推論：由於 WordPress 預設第一個管理員的 ID 幾乎都是 1，攻擊者不太需要花力氣去猜，甚至可以透過網站公開的作者頁面（如 /?author=1）或某些未關閉的 REST API 端點反查出管理員身分。
• 🏮 第三步：發出竄改請求。🔴 假設情境：攻擊者在編輯客戶或員工資料的請求裡，把原本應該對應自己帳號的關聯 ID，改成目標管理員的 ID，同時夾帶自己控制的新 Email 與新密碼。
• 🏮 第四步：直接登入接管。🟡 合理推論：由於缺乏物件層級的權限比對，系統照單全收，直接把管理員帳號的憑證改寫成攻擊者設定的內容，攻擊者隨後就能拿新密碼從登入頁直接走進管理員後台。

🧑‍🔧 DevOps 小知識：免費版是 2.x，付費版卻已經跳到 9.x
有一份情資特別提醒了一個容易搞混的地方：Amelia 在 WordPress.org 上架的免費／Lite 分支版本號還停留在 2.x，但付費的 Premium 版本已經跳號到 9.x（官方 Changelog 上 9.6.2、9.6.3、9.7、9.8 都各自標註了「Resolved a security vulnerability」）。如果你看到自己的版本號是 8.x 或 9.x，代表你用的是 Premium 分支，這時候不能只對照「是不是 2.4.10 以上」，而是要直接去官方 Changelog 核對你的版號有沒有涵蓋最新的安全修補，這種「一個外掛、兩套版號」的設計，很容易讓人自己對錯了公告 🔀

🕵️ 第五章：DevOps 自我排查 Checklist——你的網站有沒有已經被摸過？

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

強制流程只有一套邏輯：判斷環境 👉 盤點 👉 Log 排查 👉 後門檢查 👉 加固檢查，每一關都拆成「決策原理 👉 具體指令 👉 預期輸出範例 👉 分支判斷邏輯」四段，並且分別涵蓋 💠 單一網站、❇️ 獨立多站、✴️ Multisite 三種架構 📜

🧑‍🔧 DevOps 小常識：先搞清楚地圖，再決定走哪條路
「一台伺服器上塞了 10 個獨立 WordPress」跟「一個 WordPress Multisite 底下有 10 個 Site」看起來很像，實際上是兩種完全不同的架構。前者要逐一找出每個網站各自的 wp-config.php；後者才適合用 Network 層級的批次操作。判斷錯誤，後面的備份跟更新很可能作用在錯誤的對象上 🗺️

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

決策原理：三種架構的 WP-CLI 參數、資料庫範圍完全不同，判斷錯誤會讓後續盤點、更新全部跑偏，例如對 Multisite 只更新了主站卻誤以為全部子站都修好了 🤔

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

# 判斷是否為 Multisite
if wp --path="$WP_PATH" core is-installed --network 2>/dev/null; then
    echo "✴️ 這是 Multisite（WordPress Network）環境"
else
    echo "不是 Multisite，繼續往下判斷是單一網站還是獨立多站"
fi

# 直接檢查 wp-config.php 是否定義 MULTISITE 常數
grep -n "MULTISITE" "$WP_PATH/wp-config.php" 2>/dev/null \
    || echo "wp-config.php 中沒有 MULTISITE 常數"

# ❇️ 獨立多站判斷：搜尋伺服器上是否還有其他獨立的 wp-config.php
find "/var/www" -maxdepth 4 -type f -name "wp-config.php" 2>/dev/null

預期輸出範例：

# Multisite：
Success: This is a multisite installation.
✴️ 這是 Multisite（WordPress Network）環境

# 非 Multisite：
Error: This is not a multisite installation.
不是 Multisite，繼續往下判斷是單一網站還是獨立多站

# 獨立多站（find 結果）：
/var/www/site-a.com/public_html/wp-config.php
/var/www/site-b.com/public_html/wp-config.php

分支判斷邏輯：

📋 ㊁ 盤點：先搞清楚哪些站裝了 Amelia、目前是哪一版

決策原理：不要把版本號寫死在腳本裡，讓 WP-CLI 動態抓取現況；獨立多站則要動態取得每個網站的檔案擁有者，避免用單一 Linux 帳號跑遍所有網站造成權限錯亂 📊

# 💠 單一網站
WP_PATH="/var/www/example.com/public_html"
wp --path="$WP_PATH" plugin get "ameliabooking" \
    --fields=name,status,version,update,update_version

# ❇️ 獨立多站：動態找出每個網站與其擁有者，逐站盤點
find "/var/www" -maxdepth 4 -type f -name "wp-config.php" -print0 2>/dev/null |
while IFS= read -r -d '' CONFIG; do
    WP_PATH="$(dirname -- "$CONFIG")"
    OWNER="$(stat -c '%U' -- "$CONFIG" 2>/dev/null || echo "unknown")"
    echo "===== 站點：$WP_PATH（擁有者：$OWNER）====="
    sudo -u "$OWNER" -- wp --path="$WP_PATH" plugin get "ameliabooking" \
        --fields=name,status,version,update,update_version 2>/dev/null \
        || echo "  → Amelia 未安裝，或無法讀取"
done

# ✴️ Multisite：外掛檔案是整個 Network 共用，用主站路徑查一次即可，
# 不需要額外的 --network 參數（版本資訊本來就反映整個 Network）
WP_PATH="/var/www/example.com/public_html"
wp --path="$WP_PATH" plugin get "ameliabooking" \
    --fields=name,status,version,update,update_version

預期輸出範例：

name: ameliabooking
status: active
version: 2.4.9
update: available
update_version: 2.4.10

分支判斷邏輯：

• 🏮 版本 < 2.4.10（免費／Lite 分支）👉 視為受影響，進入第六章備份／修補流程
• 🏮 版本 ≥ 2.4.10，或 Premium 分支已對照 Changelog 確認涵蓋安全修補 👉 已安全，但仍建議繼續往下做 Log 與後門排查
• 🏮 Amelia 未安裝 👉 不受此漏洞影響，但建議順手檢查其他外掛是否也有版本過舊的問題
• 🏮 版本無法讀取（WP-CLI 報錯）👉 先檢查檔案擁有者與權限，不要直接切換成 root 硬跑

🔦 ㊂ Log 排查：不是看到陌生 IP 就緊張，而是找「路徑＋方法＋結果」的組合

決策原理：目前公開資訊沒有揭露此漏洞確切的攻擊端點，以下特徵是🟡 依 CWE-639 通用模式做的合理推論，並非官方證實特徵，重點是找出「短時間內對 Amelia 相關功能的異常寫入請求」，而不是死盯著某一個「神奇 IP」🎯

# 💠 單一網站
LOG_FILE="/var/log/nginx/access.log"

if [ -f "$LOG_FILE" ]; then
    grep -iE "amelia|wpamelia" "$LOG_FILE" | grep -iE "POST|PUT|PATCH" | tail -n 100
else
    echo "LOG NOT FOUND: $LOG_FILE"
fi

# 排查短時間內同一 IP 對 Amelia 相關端點的大量請求
grep -i "amelia" "$LOG_FILE" 2>/dev/null | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 20

# ❇️ 獨立多站：逐一掃過所有虛擬主機的存取日誌
find "/var/log" -type f \( -name "*access*.log" -o -name "*access*.log.*" \) -print0 2>/dev/null |
while IFS= read -r -d '' LOG; do
    MATCHES="$(grep -iE "amelia|wpamelia" "$LOG" 2>/dev/null | grep -iE "POST|PUT|PATCH" || true)"
    if [ -n "$MATCHES" ]; then
        printf '\n===== %s =====\n' "$LOG"
        printf '%s\n' "$MATCHES" | tail -n 50
    fi
done

# ✴️ Multisite：通常共用同一份 Log，找到可疑時間點後再回推是哪個子站
LOG_FILE="/var/log/nginx/access.log"
grep -iE "amelia|wpamelia" "$LOG_FILE" 2>/dev/null | grep -iE "POST|PUT|PATCH" | tail -n 100

預期輸出範例：

# 找不到日誌檔（提醒你先確認實際 Log 路徑，不是失敗）：
LOG NOT FOUND: /var/log/nginx/access.log

# 找到疑似異常請求：
203.0.113.77 - - [13/Sep/2026:03:15:22 +0800] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 1523
203.0.113.77 - - [13/Sep/2026:03:15:24 +0800] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 1523

分支判斷邏輯：

• 🏮 只有零星請求、無密集異常 👉 目前沒有直接證據顯示已被觸發，但仍建議繼續往下做後門檢查
• 🏮 發現同一 IP 短時間內大量對 Amelia 相關功能發出 POST 👉 提高警覺，比對同一時間點的帳號異動紀錄
• 🏮 完全查無 Log 檔案 👉 先找出實際 VirtualHost 的 Log 路徑，這不算「安全」，只是還沒找到證據

🚪 ㊃ 後門檢查點：光看外掛乾不乾淨還不夠

決策原理：如果攻擊者已經拿到管理員帳號，通常會順手在 mu-plugins 目錄埋一個自動載入、不需要在後台「啟用」就會執行的後門檔案，或是直接在資料庫裡動手腳，這些都不會被單純的外掛版本檢查抓到 🕵️

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

# 💠 單一網站
echo "=== mu-plugins 檔案清單 ==="
if [ -d "$MU_PLUGINS" ]; then
    find "$MU_PLUGINS" -maxdepth 2 -type f -iname "*.php" -print
else
    echo "MU-PLUGINS 目錄不存在"
fi

echo "=== 最近 14 天內被修改的 PHP 檔案 ==="
find "$WP_PATH" -type f -name "*.php" -mtime -14 -ls 2>/dev/null

echo "=== uploads 目錄下不該出現的 PHP 檔案 ==="
find "$WP_PATH/wp-content/uploads" -type f -iname "*.php" 2>/dev/null

echo "=== 目前所有管理員帳號 ==="
wp --path="$WP_PATH" user list --role=administrator \
    --fields=ID,user_login,user_email,user_registered --format=table

echo "=== 最近 14 天內新建的帳號（用 heredoc 把 SQL 寫成獨立檔案，避免特殊字元跟 Shell 引號打架）==="
QUERY_FILE="$(mktemp)"
cat > "$QUERY_FILE" <<'EOF'
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE user_registered >= DATE_SUB(NOW(), INTERVAL 14 DAY)
ORDER BY ID DESC
LIMIT 20;
EOF
wp --path="$WP_PATH" db query < "$QUERY_FILE"
rm -f -- "$QUERY_FILE"

# ❇️ 獨立多站：逐站檢查，結果要帶上路徑，不要讓 A 站乾淨就以為 B 站也沒事
find "/var/www" -maxdepth 4 -type f -name "wp-config.php" -print0 2>/dev/null |
while IFS= read -r -d '' CONFIG; do
    SITE_PATH="$(dirname -- "$CONFIG")"
    SITE_MU="$SITE_PATH/wp-content/mu-plugins"
    if [ -d "$SITE_MU" ]; then
        HITS="$(find "$SITE_MU" -maxdepth 2 -type f -iname "*.php" -print)"
        if [ -n "$HITS" ]; then
            printf '\n===== 可疑 mu-plugins：%s =====\n' "$SITE_PATH"
            printf '%s\n' "$HITS"
        fi
    fi
done

# ✴️ Multisite：mu-plugins 屬於 Network 共用，檢查一次即可；
# 帳號則要分「Network 層級」與「各 Site 層級」兩層看，不要看到帳號存在就直接刪除
WP_PATH="/var/www/example.com/public_html"
find "$WP_PATH/wp-content/mu-plugins" -maxdepth 2 -type f -iname "*.php" -print 2>/dev/null
wp --path="$WP_PATH" user list --role=administrator \
    --fields=ID,user_login,user_email,user_registered --format=table

預期輸出範例：

=== mu-plugins 檔案清單 ===
-rw-r--r-- 1 www-data www-data 1523 Sep 13 03:15 /var/www/example.com/public_html/wp-content/mu-plugins/cache-helper.php
# ⚠️ 如果檔名眼熟但你確定沒裝過，或建立時間跟你的操作對不起來，立即列為可疑

=== 目前所有管理員帳號 ===
+----+------------+---------------------+---------------------+
| ID | user_login | user_email          | user_registered     |
+----+------------+---------------------+---------------------+
|  1 | admin      | admin@example.com   | 2024-01-15 08:00:00 |
+----+------------+---------------------+---------------------+

分支判斷邏輯：

• 🏮 mu-plugins 出現不認識的檔案 👉 不要直接刪除，先隔離保留檔案時間與內容供鑑識，進入第六章「A. 已中招」流程
• 🏮 資料庫出現不認識的管理員帳號，或既有管理員的 Email 被改成陌生網域 👉 立即視為疑似入侵，優先處理
• 🏮 檢查結果都正常 👉 這一項沒有異常，但仍建議完成加固檢查後才算真正告一段落

🛡️ ㊄ 加固檢查：修好之後，再把第二道門也鎖起來

決策原理：更新外掛只解決了這一個漏洞，伺服器層與檔案權限層的加固，才能降低「下一個類似漏洞」被利用的機率 🔒

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

# 💠 單一網站：檢查危險函式與檔案權限
php -i | grep -i "disable_functions"
php -i | grep -i "open_basedir"

echo "=== 檢查目錄權限（應為 755）==="
find "$WP_PATH" -type d -not -perm 755 -ls 2>/dev/null | head -n 20

echo "=== 檢查檔案權限（應為 644，wp-config.php 除外）==="
find "$WP_PATH" -type f -not -perm 644 -not -name "wp-config.php" -ls 2>/dev/null | head -n 20

echo "=== 收緊 wp-config.php 權限 ==="
chmod 600 "$WP_PATH/wp-config.php"
ls -l "$WP_PATH/wp-config.php"

# ❇️ 獨立多站：逐站檢查 wp-config.php 權限是否過於寬鬆
find "/var/www" -maxdepth 4 -type f -name "wp-config.php" -print0 2>/dev/null |
while IFS= read -r -d '' CONFIG; do
    PERM="$(stat -c '%a' -- "$CONFIG")"
    if [ "$PERM" -gt 640 ]; then
        echo "⚠️ 權限過寬：$CONFIG（目前 $PERM）"
    fi
done

# ✴️ Multisite：檢查是否已在 Web 伺服器層阻擋 uploads 目錄執行 PHP
grep -rn "location.*uploads" "/etc/nginx/sites-enabled/" 2>/dev/null \
    || echo "⚠️ 尚未針對 uploads 目錄設定 PHP 執行阻擋規則，建議補上"

分支判斷邏輯：

• 🏮 disable_functions 是空的 👉 建議在 php.ini 加入停用 exec、passthru、shell_exec、system、proc_open、popen 等高風險函式
• 🏮 檔案／目錄權限不是 644／755 👉 用 chmod 修正，但要注意檔案擁有者，千萬不要圖方便直接 chmod 777
• 🏮 Amelia 管理權限被授予非管理員角色，而且不是業務必需 👉 評估後收回，這是縮小攻擊面最直接的一步

🧰 第六章：修不了就先擋——短期應急與正式修補三部曲

🚨 安全提醒：正式環境升級外掛前，務必先於測試環境備份並驗證，避免網站崩潰。多站環境建議先挑一站驗證後再批次推送，不要一次對所有網站下手 🧪

🆘 A. 已經觀察到異常，或高度懷疑已經中招

決策原理：優先順序是「先止血、再存證、最後才清理」，最大的敵人往往不是漏洞本身，而是在沒留下證據的情況下直接動手清理，反而把最有價值的線索一起刪掉 🧯

步驟❶：立即隔離，阻斷攻擊鏈

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

# 步驟 1：立即隔離，阻斷攻擊鏈
wp --path="$WP_PATH" plugin deactivate "ameliabooking"

# 若 WP-CLI 已經無法正常使用，改用資料夾改名的方式強制停用
mv "$WP_PATH/wp-content/plugins/ameliabooking" \
   "$WP_PATH/wp-content/plugins/ameliabooking.disabled.$(date +%Y%m%d-%H%M%S)"

步驟❷：先留證據，再動手清理

# 步驟 2：先留證據，再動手清理
EVIDENCE_DIR="$HOME/amelia-incident-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$EVIDENCE_DIR"

cp -r "/var/log/nginx" "$EVIDENCE_DIR/nginx-logs" 2>/dev/null || true
cp -r "$WP_PATH/wp-content/mu-plugins" "$EVIDENCE_DIR/mu-plugins" 2>/dev/null || true

wp --path="$WP_PATH" db export "$EVIDENCE_DIR/database-snapshot.sql"
cp "$WP_PATH/wp-config.php" "$EVIDENCE_DIR/wp-config.php.bak"

echo "取證完成，證據存放於：$EVIDENCE_DIR"

步驟❸ ：暫時性 Hotfix——先備份再刷新鹽值，銷毀所有現有登入狀態

# 步驟 3：暫時性 Hotfix——先備份再刷新鹽值，銷毀所有現有登入狀態
cp "$WP_PATH/wp-config.php" "$WP_PATH/wp-config.php.bak.$(date +%Y%m%d-%H%M%S)"
wp --path="$WP_PATH" config shuffle-salts

# 重設「所有」管理員帳號的密碼，不要只鎖定 ID=1
# ──因為攻擊者改的不一定是預設帳號，也可能是別的管理員
wp --path="$WP_PATH" user list --role=administrator --field=ID |
while IFS= read -r ADMIN_ID; do
    NEW_PASS="$(openssl rand -base64 24)"
    wp --path="$WP_PATH" user update "$ADMIN_ID" --user_pass="$NEW_PASS"
    echo "管理員 ID $ADMIN_ID 密碼已重設，請透過安全管道另行通知本人"
done

# 銷毀所有使用者現有的登入 Session（session_tokens）
wp --path="$WP_PATH" db query "DELETE FROM wp_usermeta WHERE meta_key = 'session_tokens';"

步驟❹：把可疑的 mu-plugins 檔案隔離，不要直接刪除

# 步驟 4：把可疑的 mu-plugins 檔案隔離，不要直接刪除
QUARANTINE_DIR="$HOME/amelia-quarantine-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$QUARANTINE_DIR"

find "$WP_PATH/wp-content/mu-plugins" -type f -iname "*.php" -mtime -30 -print0 2>/dev/null |
while IFS= read -r -d '' SUSPECT_FILE; do
    echo "隔離候選檔案：$SUSPECT_FILE"
    chmod 000 -- "$SUSPECT_FILE"
    mv -- "$SUSPECT_FILE" "$QUARANTINE_DIR/"
done

🧑‍🔧 DevOps 小知識：WordPress 的鹽值，是登入系統的「總開關」
在 2008 年 WordPress 2.6 發布之前，登入 Cookie 只靠一個很脆弱的單向 MD5 雜湊，駭客只要攔到一次 Cookie，就能永久假冒身分登入。後來核心引進 8 組隨機密鑰與鹽值（Salts），從此以後，wp config shuffle-salts 就成了資安應變裡最推崇的一招——它能在幾乎瞬間強制撤銷所有已登入的連線，把入侵者直接踢出後台。但要注意的是，刷新鹽值不會改變任何人的密碼，它只讓現有的登入狀態失效，如果攻擊者已經知道你的密碼，刷新鹽值後對方一樣可以重新登入——這也是為什麼上面的步驟一定要「刷新鹽值」跟「重設密碼」兩件事一起做，缺一不可 🔑

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

⏳ B. 短期應急（尚未確認中招，但暫時無法立刻更新）

🚨 短期應急不等於正式修補：停用外掛、伺服器層規則都只是縮短暴露時間的緩衝手段，真正解決問題還是得升級到安全版本 🧱

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

# 方案一：如果目前用不到預約功能，暫時停用外掛能百分之百截斷這條攻擊鏈
wp --path="$WP_PATH" plugin deactivate "ameliabooking"

# 方案二：若業務必須保持啟用，先盤點哪些角色握有 Amelia 管理相關的能力
wp --path="$WP_PATH" cap list "editor" 2>/dev/null | grep -i "amelia"
# 若發現非必要角色擁有這類權限，建議透過後台角色管理或 User Role Editor 收回

伺服器層防護規則，因為官方尚未公開確切的攻擊端點，以下僅提供概念性範例，實際套用前務必先比對自己站的 Log 確認端點名稱，並在 Staging 環境驗證過再上線：

# Nginx 概念範例：限制對 admin-ajax.php 的存取只允許辦公室固定 IP
# 實際 action 名稱尚未經官方公開驗證，套用前請先比對自家日誌
location = /wp-admin/admin-ajax.php {
    # allow 203.0.113.10;
    # deny all;
}

✅ 為什麼停用就能擋住？
這條攻擊鏈完全仰賴 Amelia 內部的編輯功能才能觸發，停用外掛能百分之百截斷這條路，是目前最乾淨、風險最低的短期緩解手段——只是它不能取代正式升級，別因為暫時停用就把這件事拋在腦後 ⛓️‍💥

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

🩵 荷包試算：這幾道防線要花多少錢？
外掛更新跟伺服器層設定本質上都是免費操作，只要有後台或 SSH 權限就能自己動手。真正花錢的地方，往往是「已經中招之後」——請資安顧問做鑑識、清除後門的工時，或是網站被列入安全警示名單之後重建流量的成本，這筆帳，怎麼算都是現在花時間走完這套流程比較划算 💸

㊀ 備份（永遠不要跳過這一步）

備份請遵循 3-2-1 原則：至少 3 份副本、2 種不同儲存媒介、1 份異地備份 💾

# 💠 單一網站
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/site_pre_amelia_update_${STAMP}.sql"

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

cp "$WP_PATH/wp-config.php" "$BACKUP_DIR/site_wp-config_pre_amelia_update_${STAMP}.php.bak"

echo "單一網站備份完成：$BACKUP_DIR"

# ❇️ 獨立多站：逐站備份，檔名帶上站名避免互相覆蓋
find "/var/www" -maxdepth 4 -type f -name "wp-config.php" -print0 2>/dev/null |
while IFS= read -r -d '' CONFIG; do
    SITE_PATH="$(dirname -- "$CONFIG")"
    SITE_OWNER="$(stat -c '%U' -- "$CONFIG")"
    SITE_NAME="$(basename -- "$SITE_PATH")"

    echo "正在備份：$SITE_NAME（$SITE_PATH）"
    sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" db export \
        "$BACKUP_DIR/${SITE_NAME}_pre_amelia_update_${STAMP}.sql"
    tar -czf "$BACKUP_DIR/${SITE_NAME}_wp-content_pre_amelia_update_${STAMP}.tar.gz" \
        -C "$SITE_PATH" "wp-content"
    cp "$CONFIG" "$BACKUP_DIR/${SITE_NAME}_wp-config_pre_amelia_update_${STAMP}.php.bak"
done

# ✴️ Multisite：Network 只需匯出一次，整個 Network 共用同一個資料庫，
# 不要在每個子站 URL 上都重複跑一次 db export
WP_PATH="/var/www/example.com/public_html"
wp --path="$WP_PATH" db export "$BACKUP_DIR/multisite_network_pre_amelia_update_${STAMP}.sql"
tar -czf "$BACKUP_DIR/multisite_wp-content_pre_amelia_update_${STAMP}.tar.gz" \
    -C "$WP_PATH" "wp-content"

預期檔案結構範例：

~/wp-security-backup/
├── site_pre_amelia_update_20260913-143022.sql
├── site_wp-content_pre_amelia_update_20260913-143022.tar.gz
├── site_wp-config_pre_amelia_update_20260913-143022.php.bak
└── site-a.com_pre_amelia_update_20260913-143530.sql

㊁ Dry-run（正式更新前先預覽）

WP_PATH="/var/www/example.com/public_html"
wp --path="$WP_PATH" plugin update "ameliabooking" --dry-run

預期輸出範例：

# 有更新可用：
Plugin ameliabooking 2.4.9 would be updated to 2.4.10.

# 已是最新版本：
Success: Plugin 'ameliabooking' is already at the latest version.

分支判斷邏輯：顯示會有更新 👉 進入正式更新；顯示已是最新版 👉 不需要更新，但仍要完成第五章的 Log 排查與後門檢查再收工 ✔️

㊂ 更新：停用 👉 更新 👉 啟用

# 💠 單一網站
WP_PATH="/var/www/example.com/public_html"
wp --path="$WP_PATH" plugin deactivate "ameliabooking"
wp --path="$WP_PATH" plugin update "ameliabooking"
wp --path="$WP_PATH" plugin activate "ameliabooking"
wp --path="$WP_PATH" plugin get "ameliabooking" --field=version

# ❇️ 獨立多站（正確做法：逐站完成備份→更新→驗證後，再進行下一站）
find "/var/www" -maxdepth 4 -type f -name "wp-config.php" -print0 2>/dev/null |
while IFS= read -r -d '' CONFIG; do
    SITE_PATH="$(dirname -- "$CONFIG")"
    SITE_OWNER="$(stat -c '%U' -- "$CONFIG")"
    echo "===== 正在處理：$SITE_PATH ====="

    sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin deactivate "ameliabooking" 2>/dev/null
    sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin update "ameliabooking" 2>/dev/null
    sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin activate "ameliabooking" 2>/dev/null

    NEW_VERSION="$(sudo -u "$SITE_OWNER" -- wp --path="$SITE_PATH" plugin get "ameliabooking" --field=version 2>/dev/null)"
    echo "  → 更新後版本：$NEW_VERSION"
    echo "  → 等待 3 秒後處理下一站，避免資料庫連線與伺服器資源同時被榨乾"
    sleep 3
done

# ❌ 危險做法（不要這樣做）：一個巨大迴圈同時對所有站下手，不驗證也不緩衝
# for site in site-a site-b site-c; do
#     wp --path="/var/www/$site/public_html" plugin update ameliabooking &
# done
# 這樣做的風險：某站更新失敗你不會知道是哪一個，而且同時併發多個資料庫寫入
# 可能造成伺服器資源耗盡，甚至讓部分站點在寫入中途卡死。

# ✴️ Multisite：外掛檔案共用，只需在 Network 層級更新一次
WP_PATH="/var/www/example.com/public_html"
wp --path="$WP_PATH" plugin deactivate "ameliabooking" --network
wp --path="$WP_PATH" plugin update "ameliabooking"
wp --path="$WP_PATH" plugin activate "ameliabooking" --network
wp --path="$WP_PATH" plugin get "ameliabooking" --field=version

㊃ 驗證（三層以上，更新成功不等於工作完成）

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

echo "=== 第一層：版本驗證 ==="
CURRENT_VERSION="$(wp --path="$WP_PATH" plugin get "ameliabooking" --field=version)"
echo "Amelia 目前版本：$CURRENT_VERSION"

echo ""
echo "=== 第二層：檔案完整性驗證（Checksum）==="
wp --path="$WP_PATH" plugin verify-checksums "ameliabooking" 2>/dev/null \
    || echo "此外掛可能未在 wordpress.org 上架 Checksum 資料庫（尤其 Premium 版），需改用官方下載頁人工比對版本標籤"
wp --path="$WP_PATH" core verify-checksums 2>/dev/null

echo ""
echo "=== 第三層：前後台功能驗證 ==="
echo "1. 前台：開啟預約頁面，測試送出一筆測試預約"
echo "2. 後台：進入 Amelia 選單，確認客戶列表、員工編輯功能可正常儲存"
echo "3. 後台：再次核對管理員帳號清單，確認沒有出現陌生帳號或被改掉的 Email"
echo "4. PHP error log 沒有突然出現大量 Fatal Error"

🧑‍🔧 DevOps 小知識：Checksum 驗證有它的防偽盲區
wp plugin verify-checksums 是拿 WordPress.org 官方公布的雜湊值來比對，它能證明「官方清單上的檔案沒被改過」，但完全看不到「目錄裡有沒有被多塞了一個後門檔案」。如果攻擊者在外掛資料夾裡新增一個叫 cache-api.php 的檔案，Checksum 驗證照樣顯示成功，因為它根本沒被要求去比對「這個檔案」。所以 Checksum 只能當三層驗證裡的其中一層，不能單獨拿來當作「網站已經安全」的證明 🔍

分支判斷邏輯：更新後仍持續出現可疑請求，或 mu-plugins 冒出新的可疑檔案 👉 不要把它當成「已經修好」，應回到本章「A. 已中招」流程重新處理，而不是單純再更新一次就結案 🔁

🗂️ 三種架構速查表

💯 第七章：舉一反三——這類「授權檢查漏一關」的通用防禦招式

本次漏洞屬於 CWE-639（透過使用者可控鍵值繞過授權），也就是俗稱的「物件層級授權檢查缺失」。以下是這類漏洞的通用防禦知識，並非本 CVE 的官方修補要求，而是給開發者跟維運人員的舉一反三 🧩

• 🏮 每個資料寫入點都要做物件層級的二次確認：不要只在「使用者能不能看到這個選單」時檢查權限，而是在真正修改資料庫的每一個 AJAX handler、REST endpoint 裡，再針對「即將被修改的那一筆特定物件」重新確認一次權限。編輯客戶記錄時，除了檢查「有沒有 amelia_manage_customers 這個能力」，還要檢查「這個使用者是否真的有資格改動這筆記錄綁定的那個 WordPress 帳號」。
• 🏮 永遠不要信任前端傳來的 ID：不管是 record_id、user_id 還是 externalId，這些從前端傳來的參數都應該被當成「不可信輸入」，在資料庫寫入前先驗證這個 ID 對應的物件是否真的屬於當前使用者可以碰的範圍。
• 🏮 非ce 驗證＋能力檢查＋物件所有權檢查，三層缺一不可：WordPress 內建的 wp_verify_nonce() 和 current_user_can() 只有在正確組合使用時才有效，開發者不應該只依賴其中一層，同時應該把外掛的內部管理權限限制在最小必要的角色上，避免「權限膨脹」一路擴散。

🔥 一句話總結：這次的漏洞，其實不是什麼複雜的密碼學攻擊，而是一個「檢查漏問一句話」的老問題——外掛問了「你有沒有權限」，卻忘了追問「你有沒有權限碰這一個」。這種模式在 WordPress 外掛生態裡反覆出現，也是為什麼定期盤點「誰握有什麼權限」，往往比事後追查誰動了手腳來得便宜、也來得踏實 🛟

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

🔥 這起事件給所有網站主的提醒其實很簡單：不是每個漏洞都要靠複雜的攻擊技巧，很多時候問題就出在「一個原本方便員工做事的小權限」，被悄悄用在了它不該做的地方。與其等哪天真的被摸過才後悔，不如現在就花幾分鐘，打開後台看一眼版本號碼，順便問自己一句：「現在到底有誰，握著我網站的鑰匙」🔑

💪 附錄：安全使用守則（請務必遵守）

• ⭐ 立即檢查 Amelia 版本，免費／Lite 分支請更新至 2.4.10 以上，Premium 分支請對照官方 Changelog 確認涵蓋最新安全修補
• ⭐ 更新前務必先備份資料庫與 wp-content 資料夾，遵循 3-2-1 備份原則
• ⭐ 定期盤點「誰目前握有 Amelia 客戶／員工管理權限」，離職或不需要的帳號立即收回
• ⭐ 疑似中招時，優先「刷新鹽值＋重設所有管理員密碼」，兩件事要一起做，缺一不可
• ⭐ 隔離可疑檔案時先搬移到隔離區，不要直接刪除，保留鑑識線索
• ⭐ Checksum 驗證只能證明「官方檔案沒被改」，仍需額外檢查 mu-plugins、uploads、資料庫留言與帳號紀錄

📚 參考資料與延伸資源

• 📌 NVD｜CVE-2026-77705 官方詳情頁
• 📌 WPScan 漏洞資料庫｜Amelia < 2.4.10 帳號接管紀錄
• 📌 VulDB｜CVE-2026-77705 漏洞紀錄
• 📌 CVE.org｜CVE-2026-77705 官方紀錄
• 📌 OpenCVE｜CVE-2026-77705
• 📌 securityvulnerability.io｜CVE-2026-77705 情資頁
• 📌 FixTheCVE｜CVE-2026-77705 修復指南
• 📌 CVETodo｜CVE-2026-77705 技術分析
• 📌 Amelia 官方 Changelog
• 📌 WordPress.org 官方外掛頁面
• 📌 CWE-639 官方定義