記錄時間與來源
用同一時區記下發現時間、相關帳戶、IP、裝置、頁面與事件編號。
WooCommerce 更新後：管理員、檔案與日誌要看哪些安全訊號
WooCommerce、外掛或主題更新完成，店主通常先測結帳與訂單。但更新也會改檔案、清快取、重啟服務，甚至令舊日誌中斷。若此時見到陌生管理員、檔案時間不同或一排警告，先不要未經記錄便刪除、重裝或全面封鎖；先保存可行證據。若已是可信的主動入侵跡象，例如未解釋的特權帳戶同時配合非預期檔案變更、異常成功登入或資料外洩跡象，獲授權人員應立即限制存取或隔離受影響範圍，同時盡量保存證據，毋須等身份完全確認。
本文是一份更新後的安全訊號核對清單，不是入侵判定，也不是 CVE 合集。功能層面的驗收，請先讀 更新後回歸測試；若問題是舊價或舊版面，請看 三層快取排查。
先看邊界
更新後的安全檢查，目標是保存與解釋訊號，不是未審先判。 未知管理員可能是同事、客戶或代理商；乾淨的掃描結果也不等於整站安全。若有可信的持續入侵跡象，不要為等待完整身份確認而延後控制：先保存可行證據，同步由獲授權人員限制存取或隔離受影響範圍，再核對「誰、何時、改了甚麼」。
第一步：保存證據，同步控制風險
在刪除帳戶、覆寫檔案、清空日誌或還原備份之前，先留下一份可核對的紀錄。這是實務建議，不是平台保證：
匯出而不只截圖
能匯出 JSON／CSV 的日誌先匯出；不能匯出的，截圖要連同網址、時間與篩選條件。
保留原始檔案副本
對可疑檔案記錄路徑、修改時間、大小與 SHA-256；不要把唯一副本直接刪除。
分清變更來源
對照更新時間、部署紀錄、主機維護通知與代理商工作紀錄，先排除已知操作。
由獲授權人員處理
停用帳戶、改密碼、撤銷 session 或還原網站，應由店主或指定負責人授權的人員處理；可信主動入侵跡象可先限制存取或隔離，毋須等完整身份確認，並同步通知客服與出貨同事。
管理員：先核對名單與角色，不要先定罪
WordPress 以角色控制使用者可做的事，管理員是具高度權限的角色之一 [4]。更新後應核對：
- 完整名單。所有管理員、超級管理員與商店經理名單。
- 身份線索。帳戶的建立時間、電郵域名，以及是否與已知同事、客戶或代理商相符。「最後活動」、角色變更及登入歷史通常要另有審計外掛或主機紀錄；標準 WordPress 使用者列表未必提供這些欄位，Cloudflare 只可補充請求層面的線索。
- 權限變動。近期是否有角色提升、密碼重設、電郵更改，或舊同事與測試帳戶仍存在。
未知管理員不自動等於攻擊者。 可能是客戶的 IT 同事、接手網站的自由工作者、主機或外掛服務建立的帳戶，也可能是舊資料匯入。先向店主與已知聯絡人核實，保留帳號與可取得的活動紀錄，不要公開電郵、IP 或登入連結。但不要為了等身份完全確認而延後控制：若同時有可信的主動入侵跡象，獲授權人員應立即限制該帳戶及相關 session 的存取，或隔離受影響範圍；在可行範圍內先記錄角色與時間線，再重設憑證及檢查其他特權帳戶。未知身份本身不是攻擊證據，也不是延後隔離的理由。
檔案：更新會改檔案，時間戳不是判決
外掛更新本來就會替換檔案，所以「修改時間是今天」不能單獨證明有問題。應把檔案變更與部署版本、更新時間及主機檔案完整性紀錄對照，而不是只看時間戳。
官方 checksum 工具可以核對 WordPress 核心檔案與 WordPress.org 提供的校驗資料 [2][3]。但它的覆蓋範圍有清楚限制：
- 核心要配對版本與 locale。版本或語言不符，可能出現看似異常的差異 [2]。
- 外掛校驗是另一個步驟。它只覆蓋有 WordPress.org 校驗資料的檔案 [3]；資料庫、上傳檔案、自訂主題、自行開發程式與私有外掛不自動納入。
- 通過不等於安全。它只表示「比對範圍內的檔案符合預期」，不表示帳戶、訂單或資料庫沒有問題。
乾淨掃描也不是安全證明。掃描可能有覆蓋範圍、簽章更新與權限限制；若沒有保留掃描版本、時間與範圍，日後也難以重現。看到核心或外掛檔案的意外差異時，先保存該檔案與比對報告，再由有權限的人員判斷是否需要隔離或還原。
日誌：有紀錄可查，不等於過去一定有紀錄
更新後常見的誤區，是把「找不到日誌」當成「沒有發生過」。實際上，不同日誌的開啟方式與保留期不同：
| 來源 | 可以看到甚麼 | 更新後要留意 |
|---|---|---|
| WooCommerce | WooCommerce > Status > Logs 可看 PHP fatal errors 等紀錄；預設保留期為 30 日 [6] | fatal-errors 不代表一定是入侵，亦不包含所有 web server timeout [6] |
| WordPress debug log | 只有 WP_DEBUG=true 且啟用 WP_DEBUG_LOG 時，錯誤、通知與警告才會寫入記錄；預設為 wp-content/debug.log，亦可設定自訂路徑 [5] | 官方建議在本地／staging 除錯，不要在正式站開啟；避免公開顯示錯誤或把日誌放在可公開讀取位置 [5]。若之前未啟用，過去事件不會補回 |
| Cloudflare Security Events | 顯示 Cloudflare 安全產品已攔截或標記的請求；歷史資料最多保留 31 日，實際方案與設定而異 [8] | 它是事件，不是所有 HTTP 請求；可能使用抽樣，未必顯示全部事件，沒有看到不是沒有請求 [8]；payload 記錄亦要在啟用後才開始 [10] |
| Cloudflare Audit Logs | 帳戶層級的用戶及系統操作，保留 18 個月，介面查詢最近 90 日 [9] | 可查誰改過設定，但不能證明 origin 的 WordPress 檔案乾淨 |
| 主機／伺服器日誌 | 視主機方案、設定與保留政策而定 | 可能只有短暫保留，或需由主機支援人員匯出 |
因此，日誌要看的是相關性：同一時間段內，是否有異常登入、權限提升、檔案修改、WAF 攔截或設定變更互相吻合。單一警告、404 或登入失敗通常不足以判定入侵；沒有日誌也不能證明安全。Cloudflare 的 Security Events 關於請求被怎樣處理，Audit Logs 關於帳戶和設定被誰改動 [8][9]；兩者都要看，但都不能取代 WordPress 內的帳戶與檔案核對。WooCommerce 的安全 FAQ 亦只提供一般背景，不能代替本站檢查 [7]。
WordPress debug 日誌要特別小心：WP_DEBUG_LOG 不是獨立開關，沒有 WP_DEBUG=true 就不會按預設方式寫入；官方文件亦建議在本地或 staging 環境除錯，而不是在正式站開啟。部分主機或管理式 WordPress 會由平台控制 PHP 錯誤日誌，實際路徑、保留期與存取方式要向主機確認。若在非正式環境除錯，亦應把 WP_DEBUG_DISPLAY 設為 false，避免把 PHP 錯誤公開顯示給訪客；任何環境都要確保 debug.log 與 wc-logs 不能被公網直接讀取。
備份與復原點：先確認可還原，才談清理
更新前應有可用備份，並知道資料庫與 wp-content 是否同一時間點。懷疑有問題時，不要立即用最新備份覆蓋舊備份；最新備份可能已包含異常內容。保留更新前後復原點，在隔離環境測試還原，再決定回到哪個時間點。WordPress 官方把備份列為安全實務 [1]，但「有備份檔案」不等於「一定可還原」；店主應定期演練並記錄誰能取得備份、還原需要哪些人工步驟。
還原不是按一下便結束：回到較早時間點可能失去更新後的新訂單、付款、庫存與客戶通知，舊備份也可能已含入侵。重開網站前，應先對帳訂單、付款 gateway、退款與 webhook，處理造成事件的根因，並重設相關憑證；否則可能只是把舊問題帶回來，或製造新的交易落差。
若事件仍在調查，應先在隔離環境重現與驗證，不要在正式站邊查邊改；隔離環境的設定可參考 上線前 staging 檢查。
更新後五步核對（手機版）
- 01 · 保存與控制匯出日誌，記錄時間、帳戶、事件編號與檔案雜湊。
可信的主動入侵跡象要先限制存取或隔離，同時保存可行證據；毋須等身份完全確認。
- 02 · 管理員核對角色、建立時間與身份。
最後活動與登入歷史需預先有審計或主機紀錄；未知管理員不自動等於攻擊者。
- 03 · 檔案對照部署版本、locale 與官方 checksum。
通過只覆蓋比對範圍，不是整站安全證明。
- 04 · 日誌把 WooCommerce、WordPress、Cloudflare 與主機時間線對齊。
沒有紀錄可能只是未開啟或已輪替。
- 05 · 備份確認更新前復原點可以還原，再決定是否清理。
還原可能失去新訂單與付款更新，也可能重帶舊問題；重開前先對帳及處理根因。
何時控制及升級？若出現可信的主動入侵跡象，例如未解釋的特權帳戶配合非預期檔案變更或異常成功登入，應立即由獲授權人員限制存取或隔離受影響範圍。
同時保存可行證據，毋須等身份完全確認；再由店主指定負責人或主機支援人員完成調查與補救。
五個訊號怎樣讀：先分類，再升級
| 訊號 | 可以先排除的正常原因 | 較穩妥的下一步 |
|---|---|---|
| 多了一個管理員 | 同事、客戶、代理商或舊匯入 | 核實身份並保留帳號紀錄；若同時有可信的主動入侵跡象，先限制存取或隔離，毋須等完全確認 |
| 核心或外掛檔案有差異 | 更新本身、版本／locale 不符，或部署紀錄未對齊 | 用正確版本／locale 重做 checksum 對照；保存差異檔；快取一般不會改動原始程式檔 |
| WooCommerce 出現 fatal errors | 外掛衝突、PHP 相容性或更新後的程式錯誤 | 先看時間與相關外掛；不要只因有錯誤就當成入侵 |
| WAF 攔截突然增加 | 掃描、爬蟲、誤判或真實攻擊 | 按時間、路徑、IP 與 User-Agent 關聯；不要未經核對就全面封鎖 |
| 找不到相關日誌 | 未開啟、已輪替、保留期短或主機未提供 | 記錄「未知」，立即規劃日誌與備份，不要寫成「無事發生」 |
若多個訊號在同一時間出現，而且涉及未知管理員、非預期檔案變更與異常登入，應暫停非必要變更，交由店主指定的負責人或主機支援人員處理。若跡象可信且指向正在發生的入侵，負責人應先限制存取或隔離受影響範圍，同時保存可行證據；未知身份本身不應成為延後控制的理由。不要自行在正式站執行來歷不明的修復腳本，也不要把完整日誌貼到公開論壇。
不破壞證據的核對次序
- 區分核實與控制。先暫停非必要變更；若只是未解釋帳號，先核實。若已有可信的主動入侵跡象，獲授權人員應立即限制存取或隔離受影響範圍，同時在可行範圍保存證據，毋須等身份完全確認。
- 匯出證據。保存 WooCommerce、WordPress、Cloudflare 與主機日誌的相關時段。
- 核對管理員名單。記錄角色、建立時間與核實結果；最後活動、角色變更及登入歷史若沒有預先審計或主機紀錄，可能根本查不到。
- 對照檔案。使用部署紀錄、主機完整性工具或官方 checksum，並記下版本與 locale [2][3]。
- 讀日誌的範圍。分清「沒有紀錄」、「紀錄未開啟」與「紀錄顯示異常」 [5][6][8]。
- 確認備份。找出更新前復原點並在隔離環境測試；還原可能失去新訂單與付款更新，亦可能重帶舊問題，重開前要先對帳及處理根因。
- 再決定補救。由獲授權人員重設憑證、停用帳戶、隔離主機或還原；每一步都留下時間與原因。
這份次序不是鑑識標準，也不能取代專業調查；它的作用是避免在資料不足時做出不可逆的清理。
常見問題
WooCommerce 更新後出現未知管理員，應立即刪除嗎？
不要只因陌生便未經記錄刪除。先核實身份並保存帳號、角色、時間線及可取得的活動紀錄；若同時出現可信的主動入侵跡象，獲授權人員應立即限制存取或隔離受影響範圍，毋須等身份完全確認。未知不等於攻擊者。
掃描結果顯示乾淨，還要看日誌嗎？
要。掃描有覆蓋範圍與時間限制；日誌可補充登入、權限、設定變更與請求層面的線索。兩者都不是單獨的「安全證明」。
結語：把「不知道」保留下來
更新後的安全核對，不是把所有異常都當成攻擊，也不是用一次掃描換取安心。對香港網店營運人員而言，最實際的做法是：保存可行證據、同步控制可信風險、再核對與判斷；知道哪些日誌可能根本沒有、哪些 checksum 根本未覆蓋、哪些帳戶仍待核實。這樣即使最後需要主機或專業人員介入，也仍有足夠證據說明發生過甚麼。
若你需要按實際主機、WooCommerce 設定與團隊權限整理更新後檢查流程，可聯絡 Managed-WP.™ PRO。
資料來源
更新後，先保存訊號，再決定下一步
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正處理 WooCommerce 更新後的管理員、檔案或日誌異常，先整理時間線、相關帳戶與已保存的報告，再按實際環境與團隊權限確認支援範圍。
聯絡 Managed-WP.™ PRO編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理。標示為實務建議的內容不是 WordPress、WooCommerce、Cloudflare 或主機商的保證；版本、介面、日誌保留期與功能可能變更，請以實際環境及最新官方文件為準。本文不構成入侵鑑識、法律或合規意見。