WordPress 7.0.2 安全更新：SQL Injection、REST API RCE 漏洞與網站遭入侵處理方式

網站現在看起來正常，是不是代表沒有被入侵？

不是。
有網站管理者發現，網站首頁甚至大部分功能都還能正常使用，
但檢查後才看到陌生的管理員帳號、假外掛、Web Shell，
甚至正常文章資料裡被插入隱藏的 iframe。

因此「網站打得開」只能代表前台目前還能運作，
不能拿來判斷網站是不是乾淨。

我用線上工具掃過沒有問題，是不是就安全了？

不一定。
有些線上工具只能檢查你的 WordPress 現在是否已經更新，
或漏洞入口目前是否還存在，
並不能證明網站之前沒有被攻擊成功。

「漏洞已修補」和「網站從未被入侵」是兩件不同的事。

那要怎麼知道網站曾經被入侵？

可以先從幾個比較明顯的地方檢查：

• 是否出現不認識的 WordPress 管理員帳號
• Plugin 或 MU Plugin 裡是否出現陌生檔案
• 網站目錄是否突然多出不明 PHP 或異常資料夾
• Core、Theme 或 Plugin 原本正常的檔案是否被修改
• 資料庫文章或 metadata 是否出現異常 iframe、網址或程式碼

但反過來也一樣：
沒有看到這些跡象，不代表一定沒有遭到入侵。
如果攻擊者把後門藏在正常 PHP 檔案裡，單靠後台人工檢查很可能看不出來。

只檢查 WordPress 後台帳號和外掛就夠了嗎？

如果只是一般網站異常，可以先從 WordPress 本身檢查。
但如果攻擊者已經取得 Remote Code Execution（RCE），
檢查範圍就不能只停留在 WordPress。

實際案例中，有攻擊者進一步修改 Linux 使用者環境，
例如加入 SSH Key、修改.profile 或 .bashrc、
建立隱藏背景程式，甚至把惡意檔案設成不可修改。

因此 VPS 或獨立主機如果發生 RCE，
要把它視為主機層級的資安事件處理，
而不是只清 WordPress。

把 MySQL 的 FILE 權限關掉，就能避免這種攻擊嗎？

移除 WordPress 資料庫帳號不必要的 FILE 權限是合理的安全強化措施，
可以降低某些透過資料庫直接寫檔的攻擊方式。

但它不是萬靈丹。
社群中也有網站是在資料庫帳號沒有 FILE 權限的情況下，
WordPress 核心檔案依然遭到修改。

原因是只要攻擊者已經取得 RCE，
他就可能直接透過 PHP 或系統指令寫入檔案，
不一定需要透過 MySQL。

已經確定中毒，到底應該清理，還是直接重建？

這也是討論中最有共識的一點。

如果只是少量、明確而且可以確認範圍的異常，
可以進行檔案、帳號、資料庫與 Log 的完整清查。

但如果已經確認存在 Web Shell、陌生管理員、核心檔案遭修改，
甚至主機層級的後門，
就很難證明「所有惡意修改都已經找到」。

這種情況下，如果手上有攻擊發生前、確認乾淨的備份，
重新建立乾淨環境，再從可信任的備份恢復， 通常會比在原本已遭入侵的環境裡逐一刪除惡意檔案更可靠。