- 逆向行駛 - https://520.be/ -

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

Posted By wHOaMi On In 網站建設 | No Comments

🚨 你的房仲網站大廳，可能正把「主委萬能磁扣」發給路人：MyHome Core 帳號接管漏洞全解析

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

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

[25]

🟦 🟦 🟦

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

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

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

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

💡 再補一個比喻：為什麼「拿到代碼」就等於「拿到鑰匙」？
一般安全的驗證系統，會把「臨時通行碼」跟「發起請求的那個人」用密碼學方式綁死，就像銀行提款機的簡訊驗證碼，一定只會傳到「戶頭本人」的手機上。但 MyHome Core 的驗證機（activate()）只檢查「這組代碼本身對不對」，卻沒有檢查「拿代碼來的人，是不是當初被系統發卡的那個人」。這就好比銀行驗證碼寄丟了，路上隨便撿到的人拿去輸入，銀行照樣把錢匯出去 🔑
🟢 🟢 🟢

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

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

時間節點 具體進展與處置動作
【❓待確認】 知名資安防護機構 Wordfence 的威脅情報研究員 Rafie Muhammad 於檢視原始碼過程中，發現 AJAX 處理常式存在身分授權空窗期（原文未載明具體通報日期）
2026-08-29 Wordfence 正式對外公開此漏洞的技術細節並發布安全公告
2026-08-30 美國國家標準與技術研究院（NVD）及 IONIX、Tenable、CIRCL 等多家全球資安機構將其收錄至國家漏洞資料庫，正式賦予 CVE-2026-15980 編號
【❓待確認】（早於公開日） 開發商 TangibleWP 在漏洞公開前已收到通報，並釋出修補版本 4.4.6

💡 碎碎念：「還沒被大規模攻擊」不代表可以放心慢慢處理
根據 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 的付費佈景主題包中，若佈景主題授權已過期，官方更新提示可能不會自動出現，這點企業採購時務必留意 ⚠️

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

💡 真實情境模擬：舊網站捨不得換頁面編輯器的隱形陷阱
一間台灣的房仲公司，幾年前用 WPBakery 頁面編輯器架設了官網，後來雖然升級了佈景主題版本，但因為捨不得重做已經排版好的物件頁面，一直沒有切換到新版編輯模式，讓佈景主題持續運行在 Legacy/WPBakery 模式下。網站主觀認為「外掛我們每年都有續約更新，應該很安全」，卻完全沒意識到，正是這個「捨不得換編輯器」的貼心決定，恰好符合了此漏洞被觸發的必要條件之一——落後的舊版程式碼路徑因此被重新啟用 🆘

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

[26]

🔴 🔴 🔴

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

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

項目 內容
外掛／開發商 MyHome Core（TangibleWP）
CVE 編號 CVE-2026-15980
CVSS v3.1 評分 9.8（Critical）
CVSS 向量 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE 分類 CWE-289（身分驗證繞過 Authentication Bypass）
受影響版本 <= 4.4.5
安全版本 >= 4.4.6

🧑‍🔧 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 則代表機密性、完整性、可用性三方面全部遭受高度衝擊 🗡

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

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

觸發條件 說明與技術意義
1. 佈景主題模式 MyHome 佈景主題必須設定在 Legacy/WPBakery 模式下運行，通常是舊網站為維持與舊版頁面編輯器相容而保留的設定，導致易受攻擊的舊版程式碼路徑被啟用
2. 功能啟用狀態 系統必須啟用「前台註冊」與「確認信件」功能，使 send_link 與 activate 的 AJAX endpoints 處於活躍可呼叫狀態
3. 目標帳號狀態 目標帳號（通常為 Administrator）的 wp_usermeta 資料表中，必須尚未包含 myhome_agent_confirmed 這個特定 Meta Key，若該帳號已確認過，攻擊鏈將無法生成新的覆寫權杖

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

階段 技術動作
❶ 偵察 攻擊者透過枚舉 WordPress REST API（如 /wp-json/wp/v2/users 端點）或解析網站的作者存檔頁面，獲取目標管理員的帳號 ID 或使用者名稱
❷ 觸發權杖生成 發送惡意 POST 請求至 /wp-admin/admin-ajax.php，Payload 中指定 action=send_link，並指向尚未確立 myhome_agent_confirmed meta 的管理員帳號，系統因而在資料庫中寫入啟動權杖
❸ 劫持認證 Cookie 緊接著再次發送 POST 請求呼叫 action=activate，附帶預測、攔截或直接由上一步回應中提取的權杖。系統驗證成功後，在 HTTP Response Header 的 Set-Cookie 中回傳該管理員的關鍵認證 Cookie
❹ 完全接管 攻擊者將攔截到的 Cookie 注入至瀏覽器，重新整理頁面後即可直接登入 /wp-admin，取得 Administrator 權限

🧑‍🔧 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

面對已公開的漏洞細節，系統管理員應假設系統可能已遭探測，必須立即執行版本比對與日誌排查 🔍

📌 版本比對

  • ✔️ 確認目前運作版本：檢查伺服器路徑 wp-content/plugins/myhome-core/readme.txt 中的 Stable tag 欄位，或透過 WP-CLI 執行 wp plugin get myhome-core
  • ✔️ 比對受影響版本：確認版本是否落在 0 至 4.4.5 的危險區間
  • ✔️ 確認是否已更新至安全版本：確認版本是否已升級至 4.4.6 或更高版本

📋 Log 日誌排查特徵

排查維度 可疑特徵說明
可疑 API Endpoint 大量針對 /wp-admin/admin-ajax.php 的請求，尤其來自非預期地理位置的 IP
可疑 Request 類型 未攜帶有效 wordpress_logged_in Cookie 的 HTTP POST 請求
可疑參數 Request Body 或 Query String 中包含 action=send_link 與 action=activate 參數的連續請求
可疑時間範圍 重點盤查 2026 年 8 月 29 日（漏洞公開日）至系統完成修補期間的日誌記錄
其他異常活動 上述 AJAX 請求獲得 HTTP 200 回應後不久（數秒至數分鐘內），同一 IP 緊接著存取 /wp-admin/plugins.php、/wp-admin/theme-editor.php 或 /wp-admin/user-new.php 等高權限頁面

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

🕵️ 後門檢查點

若懷疑網站已遭利用，請確保攻擊者未留下持續性後門：

  • ✔️ 異常新增管理員帳號：檢查 wp_users 與 wp_usermeta 資料表，確認是否出現不在編制內的 Administrator 帳號，或現有帳號的 Email 被竄改
  • ✔️ 不明 WordPress 使用者：排查近期是否有異常大量或名稱為隨機字串的註冊帳號
  • ✔️ 不明 PHP 檔案：嚴格檢查 wp-content/uploads/ 目錄，正常應僅有媒體檔，若出現任何 .php 檔案即代表已遭入侵
  • ✔️ 檔案修改異常：在 Linux 環境使用指令檢查近期被修改的核心程式碼或佈景主題檔案
  • ✔️ 資料庫異常內容：檢查 wp_options 資料表的 active_plugins 欄位是否有未知的隱藏外掛被啟用，同時檢查 wp_posts 是否被大量插入垃圾連結
  • ✔️ 可疑排程工作：檢查 WordPress Cron Job 是否有發送異常請求或定時執行惡意腳本的排程
  • ✔️ 不明外掛／佈景主題檔案：比對官方發布的原始檔案與伺服器上的目錄，檢查是否有偽裝成系統組件的後門目錄
# 快速檢查目前 MyHome Core 版本（WP-CLI）
wp plugin get myhome-core

# 檢查近 7 天內被修改過的 PHP 檔案
find /path/to/wordpress -type f -mtime -7 -name "*.php"
🟫 🟫 🟫

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

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

㊀ 短期應急：網路層與應用層防護

若因商業邏輯考量或相容性問題，導致無法立即更新外掛版本，請立即採取以下應急手段降低風險：

  • ㊀ 限制相關功能：立即進入 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）與告警機制

㊁ 緊急修復與暫時性緩解：標準事件響應流程

    • ❶ 備份：完整備份資料庫（SQL Dump）與網站檔案目錄結構（含所有外掛與使用者上傳檔案）
    • ❷ Staging 驗證：將備份還原至隔離的測試環境
    • ❸ 正式修補版本：在測試環境透過 WP-CLI 執行 wp plugin update myhome-core 或透過後台介面更新至 4.4.6
    • ❹ 尚無修補版本 → 暫時性緩解：如前所述，修改佈景主題的註冊與驗證設定
    • ❺ 商業版／付費外掛特殊管道：由於 MyHome Core 經常綁定在 ThemeForest 的付費佈景主題包中，若系統未跳出自動更新提示，管理員必須重新登入 ThemeForest 帳戶，下載最新版佈景主題安裝包，手動提取 MyHome Core 4.4.6 的 ZIP 檔案透過 FTP/SFTP 覆蓋安裝
    • ❻ Production 部署：確認 Staging 環境的核心功能（房地產列表、地圖 API、會員登入等）未因升級而崩潰後，再應用於正式環境
    • ❼ 功能驗證：在正式環境執行完整的回歸測試
    • ❽ Log／安全事件檢查：更新完成後，為防範攻擊者已取得有效 Session，管理員必須在後台強迫所有使用者登出，並在 wp-config.php 中重新生成（Rotate）所有 AUTH_SALT 與安全金鑰，使現有被偽造的 Cookie 徹底失效，最後要求所有管理員全面重設高強度密碼
    💡 白話文教室：為什麼更新完還要「重新生成 AUTH_SALT」？
    這就像大樓發現主委的萬能磁扣被複製流出，光是換掉發卡機的軟體漏洞還不夠——已經被複製出去的那批舊磁扣依然有效！這時候唯一根治的辦法，就是直接把整棟大樓的門鎖系統重新編碼，讓所有舊磁扣（不管是誰複製的）全部瞬間失效，所有住戶都得重新辦一張新卡。AUTH_SALT 就是那組「門鎖編碼」，重新生成後，所有已經核發出去、可能被攻擊者攔截到的登入 Cookie 會全部作廢 🙅

    ㊂ 正式修補：標準更新流程

    正式修補的唯一根本解法，是更新存在漏洞的程式碼，確保 send_link() 與 activate() 加入適當的權限校驗與 Nonce 驗證。

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

    • ❶ 登入 WordPress 控制台，確保擁有 Administrator 權限
    • ❷ 導覽至左側選單的「控制台」>「更新」
    • ❸ 尋找 MyHome Core 外掛，勾選後點擊「更新外掛」
    • ❹ 驗證外掛版本是否成功顯示為 4.4.6 或以上
    • ❺ 清除網站的伺服器快取（如 Redis/Memcached）與 CDN 快取，並檢查前端網站功能運作是否正常

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

    🏁 🏁 🏁

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

    評估維度 分數 一句話評語
    漏洞嚴重程度（分數越高代表風險越大） 9.8 近乎滿分的 CVSS 評分，且不需任何前置條件即可遠端觸發，屬於最高危等級
    官方應變速度 【❓待確認】 原文未載明開發商從通報到釋出修補版的確切耗時，僅能確認修補版早於公開日釋出
    一般站長自救可行性 8 更新版本＋確認佈景主題模式即可解決，操作門檻不高
    DevOps 技術文件完整度 8.5 官方提供完整攻擊鏈、CVSS 向量與觸發條件，方便進行事後鑑識
    台灣房仲業曝險影響評估（在地化） 7 不少台灣房仲網站承接自 ThemeForest 佈景主題模板、長年未切換頁面編輯器版本，屬於高曝險族群，需特別留意
    🏆 加權綜合建議 立即行動 最終建議：【24 小時內完成版本確認與更新】

    🔥 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 檔案

    [27]

    📎 📎 📎

    📚 參考資料與延伸資源

    列印本文 [32] 👨‍👩‍👧‍👦 18 次瀏覽