2025 年，WordPress 生態系新增了 11,334 個漏洞，比 2024 年多出 42%，而且其中九成一都出在外掛，佈景主題占了 9%，核心程式全年只查到 6 個、還都屬於低風險。更棘手的是，Patchstack 最新一份資安白皮書指出，這些漏洞裡有 46% 在公開揭露的當下根本還沒有修補程式可用——如果照攻擊強度加權計算，從漏洞曝光到第一次真的被鎖定攻擊，中位數只要 5 個小時。
漏洞一年比一年多，留給你反應的時間卻一年比一年短。網站被駭往往不是運氣不好，而是時間到了沒補上那個洞。可是大多數人一發現網站不對勁，直覺反應是慌亂地東刪西改：砍掉幾個看起來可疑的檔案、隨便換一個密碼，畫面看起來正常了就鬆一口氣，結果病灶根本沒清乾淨，過沒多久又被駭一次。正確的順序應該反過來：先隔離，讓災情不再擴大；再清除，把病灶挖乾淨；最後補強，讓同一個漏洞不會再被拿來利用一次。這篇就照這三個階段，把 WordPress 被駭之後完整的處理流程走一遍。
網站被駭有哪些跡象？
打開網站發現內容亂跳，或朋友傳訊息說「你的網站好像怪怪的」，先別急著認定就是被駭。版本相容性出問題、外掛互相衝突，一樣可能讓後台登不進去、前台跑版，跟真的被入侵是兩回事。真正該當一回事的跡象通常有個共同點，那就是內容或流量的變化不是你自己造成的，而且是悄悄發生，你原本不會主動注意到。
最常見的是前台被自動轉址到陌生網站，或無緣無故跳出情色、博弈這類廣告彈窗。比較隱蔽的手法，是刻意讓訪客看到的版本跟你登入後看到的不一樣。拿無痕視窗（或換一台沒登入過的裝置）打開網站首頁，跟自己登入後台看到的畫面比對，如果訪客那一版被偷偷塞了廣告或轉址，登入後卻一切正常，這正是駭客常用的手法，專門要騙過網站主人自己的檢查。
後台也要看一輪。打開「使用者」列表，確認每一個管理員帳號都認得，沒有一個是自己或團隊建立的陌生帳號，這是駭客留後門最常見的方式，只要留著一個管理員帳號，就算換掉密碼、清掉可疑檔案，對方還是能重新登進來。文章與留言內容也可能被偷塞隱藏連結（顏色設成跟背景一樣、或用樣式藏起來，肉眼幾乎看不出來），用來衝其他網站的搜尋排名。除了這些看得到的異狀，網站速度無故變慢也是一個線索，背景可能正在跑外洩出去的惡意程式，不斷發送垃圾郵件或攻擊別的網站，把主機資源吃掉一大半。
如果上面這些都沒察覺，還有兩個外部訊號值得留意。主機商寄來警告信，說帳號有異常流量或被回報濫用；還有 Google Search Console 的「安全性問題」報告，這是 Google 巡邏機制發現網站有被駭跡象時，直接寫進 Search Console 帳號的警示，列出問題類型（常見的有遭駭的惡意軟體、程式碼植入、不實內容）與受影響的網頁。一旦這份報告出現內容，就代表 Google 已經認定網站有問題，搜尋結果旁很可能已經標上警告，連瀏覽器都會在使用者點進來之前先跳出插頁警示，把原本要進站的訪客嚇跑。
網站為什麼會被駭？
確認網站真的出狀況之後，下一個問題是，這個破口當初是怎麼被打開的。WordPress 核心程式本身其實一年查不到幾個漏洞，真正的破口幾乎都出在外掛與佈景主題。Patchstack 資安團隊統計，2025 年整個 WordPress 生態系新增的漏洞裡，91% 出在外掛、9% 出在佈景主題，核心程式全年只有 6 個，而且都屬於低風險。換句話說，「WordPress 不安全」這個講法本身就搞錯了對象，真正該提防的是你裝了多少支外掛、每一支有沒有跟著更新。
這些漏洞裡，又以跨網站指令碼攻擊（Cross-Site Scripting，簡稱 XSS）最常見。Wordfence 針對 2024 年整年新揭露的漏洞做統計，單是 XSS 型態就占了 46%，如果把相關的變體型態一起算進去，比例還會逼近一半。XSS 的原理是把惡意的程式碼片段偷塞進網頁裡，趁訪客或管理員瀏覽時在瀏覽器裡執行，輕則跳出廣告轉址，重則整個偷走登入階段的 Cookie，直接冒充成管理員登入後台。外掛只要有一個輸入欄位沒把使用者送進來的內容過濾乾淨，就可能留下這種破口。
第二個大宗成因是密碼太弱或到處共用。後台管理員密碼、FTP 帳號、資料庫使用者這幾組如果隨便設，或是好幾個網站共用同一組密碼，只要其中一個地方外洩，駭客就能一路用同一組帳密試遍所有入口。
第三種常被忽略的破口，是安裝來路不明的破解版（nulled）外掛或佈景主題。這類檔案通常是把要付費的商業外掛破解成免費版本再流出，問題是破解的人往往會順手在程式碼裡埋一段後門，裝上去看起來功能都正常，實際上等於主動幫駭客開了一道專屬入口。
最後一種容易被忽略的成因，不在網站本身，而在管理者自己的電腦。如果平常用來登入後台、上傳檔案的那台電腦已經中了木馬或鍵盤側錄程式，不管網站端的密碼設得多複雜，都會在輸入的當下被整組側錄走，換再多次密碼也沒用。
被駭之後，為什麼分秒必爭？
前面提到，漏洞從曝光到第一次真的被鎖定攻擊，以攻擊強度加權計算，中位數只要 5 個小時。這代表被駭這件事很少會給你「有空再處理」的餘裕，拖得越久，後續要收拾的規模通常越大。
最直接的代價是被 Google 列入警示名單。只要 Search Console 的安全性問題報告跳出通知，搜尋結果旁很可能已經掛上警告標籤，瀏覽器打開網站前也會先跳出全頁式的警示畫面。多數訪客一看到這種畫面就會直接關掉分頁，不會冒著風險繼續往下點，流量掉的速度往往比想像中快很多。而且這個警示不會自己消失，得等清乾淨、主動申請審查通過才會拿掉，拖越久等於讓這面警告多掛越久。
如果網站放在共用主機上，病灶還可能連累同一台主機的其他網站。惡意程式常常會利用主機層級的漏洞橫向感染，一個網站的資料夾被入侵，隔壁的網站也可能遭殃，這也是為什麼多數主機商一旦偵測到異常流量，會直接寄警告信甚至暫時停用帳號。另外，如果網站被利用來散布惡意軟體或架設釣魚頁面，經營者本身也可能因為疏於管理而要承擔相關責任，不是只有駭客要負責。
這也是為什麼處理被駭要照順序走，而不是想到哪裡就做到哪裡。心急想著快點恢復正常，反而容易漏掉關鍵步驟，清完表面又被同一個漏洞駭一次；先把順序抓對，再談速度，才不會白忙一場。
第一階段：先隔離，避免災情擴大
確認網站真的被駭之後，第一步不是急著把每個可疑檔案都刪光，而是先讓傷害停在目前這個程度，不再繼續擴大。這個階段動作要快，但不能亂砍檔案，隨手刪掉看起來奇怪的檔案，很可能連同駭客留下的線索一起刪掉，之後根本查不出病灶藏在哪裡，甚至可能刪到網站正常運作需要的檔案，讓網站直接掛掉、變成比被駭更嚴重的狀況。動手之前，先把目前這個「中毒版本」完整備份一份留存，這份備份純粹用來事後比對、分析病灶怎麼進來的，不能拿來當成乾淨版本還原，兩者的用途完全不同，別搞混。
網站要先切成維護模式，擋住訪客與搜尋引擎
第一件事是把網站切成維護模式，對外先「靜音」。這麼做有兩個理由：一是擋住訪客，不讓他們在網站被清乾淨之前，繼續被轉址到可疑頁面或跳出惡意廣告；二是擋住搜尋引擎的爬蟲，不讓 Google 在這段期間爬到有問題的版本，把被入侵的內容收錄進索引。
維護模式跟直接把網站關掉是兩回事。做得正確的維護模式，伺服器回應的是 503（服務暫時無法使用）這個狀態碼，等於明確告訴搜尋引擎這只是暫時的、請晚點再回來看，不會被誤判成網站已經消失；如果只是把網域指向空白頁或直接關站，反而可能被搜尋引擎當成網站不存在，連帶影響後續的排名。多數安全外掛或後台佈景主題設定裡都有現成的維護模式開關，如果連後台都已經進不去，可以先聯絡主機商，請對方在伺服器層級暫時擋住對外連線。
所有相關密碼都要換掉，順序怎麼排？
接下來假設所有密碼都已經外洩，一次全部換過一輪，而且要照順序換，免得漏掉某個入口，駭客又從那裡繞回來。建議的順序是：
- 主機控制台的登入密碼
- FTP 帳號密碼
- 資料庫使用者密碼
- WordPress 後台管理員密碼
- 綁定的電子郵件帳號（多數系統的忘記密碼功能都靠這組信箱重設）
換密碼這件事，建議用另一台平常沒拿來管理這個網站的裝置操作。如果原本用來管理網站的那台電腦本身已經中毒或被植入側錄程式，就算把每一組密碼都換得再複雜，新密碼一樣會在輸入的當下被整組錄走，等於白換一次。
外掛與非預設佈景主題要先停用，阻斷病灶
如果還能登入後台，下一步是先把所有外掛停用，佈景主題也切回 WordPress 內建的預設佈景主題，把可能藏著病灶的地方先隔開來。這時候不用急著判斷是哪一支外掛出的問題，等第二階段清查完再一支一支重新啟用，順便觀察問題是不是跟著某一支外掛一起消失，這樣也能幫忙鎖定當初的破口出在哪裡。
第二階段：找出並清除惡意程式
隔離做完，下一步才是真正的硬仗，把病灶從檔案到資料庫一次挖乾淨。這是整個處理流程裡最容易被馬虎帶過的一關，清完沒多久又被駭一次，幾乎都是栽在這裡。很多人以為刪掉幾個可疑檔案就算清乾淨，實際上惡意程式常常同時藏在檔案跟資料庫兩邊，只清一邊，另一邊留著的後門遲早會把整個網站再打開一次。
掃描工具怎麼挑，特徵比對和異常偵測有什麼差異？
市面上的惡意程式掃描工具，原理大致分兩種。傳統做法是拿一份已知的惡意程式特徵碼資料庫去比對網站上的檔案，只要程式碼片段跟資料庫裡的樣本相符就標記出來，這種方式對常見的舊型態惡意程式很有效，但遇到全新型態、或是駭客刻意變形過的程式碼，就容易直接漏掉，因為它根本不在特徵碼資料庫裡。
這幾年不少資安工具開始加入以行為模式或異常流量為基礎的偵測方式，不看程式碼長什麼樣子，而是看網站的行為對不對勁，像是突然大量對外發送請求、出現不該存在的排程工作，用這種方式補上特徵比對抓不到的缺口。實務上建議至少搭配兩種不同角度的掃描工具交叉確認，不要只相信單一工具跑出來的結果就直接判定乾淨，兩種工具各自的死角不一樣，合起來才比較看得全。
核心檔案要拿乾淨版比對，揪出被動過手腳的檔案
確認網站目前使用的 WordPress 版本號之後，從官方網站下載同版本的乾淨安裝檔，拿它跟現有網站的檔案逐一比對差異，找出哪些檔案的內容被動過手腳、或是多出了原本不存在的檔案。
核心程式的部分，像是 wp-admin、wp-includes 這幾個資料夾，可以直接整批用剛下載的乾淨版本覆蓋過去，因為這些檔案內容本來就該跟官方版本一致，沒有理由被個別修改。但 wp-content 這個資料夾（裡面放外掛、佈景主題、上傳的媒體檔案）跟 wp-config.php 這支設定檔，不能整批覆蓋，因為裡面有自己客製化的設定跟真實資料，得逐一打開檢查，確認每一支檔案的程式碼看起來合理，沒有被塞進看不懂的可疑片段。
資料庫要清哪裡？使用者、選項與文章內容
檔案清乾淨之後，資料庫也不能跳過。先看 wp_users 這張表，確認裡面每一個管理員層級的帳號都是自己或團隊建立的，沒有一個是憑空冒出來的陌生帳號。接著檢查 wp_options 這張表，裡面存著網站網址、目前啟用的外掛清單這類核心設定，駭客有時候會偷改網站網址讓部分連結被導去別的網域，或是偷偷在啟用外掛清單裡塞一支看起來人畜無害、實際上是後門的假外掛。最後是文章與留言的內容本身，逐篇檢查有沒有被偷塞看不見的隱藏連結，或是夾帶著看起來像亂碼的可疑程式碼片段，這些通常是駭客用來衝其他網站排名，或是留著隨時可以重新執行的後門。
有沒有乾淨備份，決定接下來怎麼做
到這一步，有沒有一份明確早於中毒時間點的乾淨備份，會決定接下來怎麼走。如果有，直接拿這份備份還原檔案跟資料庫是最快的做法，省下前面逐一比對檔案、逐項檢查資料庫的功夫。如果沒有明確乾淨的備份，或是不確定手上這份備份本身是不是已經中毒，就只能照上面手動清查的方式一步一步來，沒有捷徑。
不管走哪一條路，都要提醒自己一件事，清乾淨或還原乾淨版本，都只是把病灶處理掉，並不代表當初被入侵的那個破口已經補起來。接下來第三階段的補強一樣要走完，不然漏洞還在原地，等於留著同一道門沒鎖，不用多久又會被同一招駭一次，前面花的功夫就白費了。
第三階段：補漏洞、換密碼，防止立刻又被駭
病灶清乾淨，不代表這件事就結束了。如果沒有把當初讓駭客闖進來的那個破口補起來，網站很可能在短時間內，被同一個漏洞用同一招再駭一次。這個階段要顧好四件事：把系統更新到最新版、換掉安全金鑰、調整檔案權限，再加上回頭確認一次使用者清單，一項都不能少。
WordPress 核心、外掛、佈景主題全部更新到最新版
前面提過，新揭露的 WordPress 漏洞裡有 91% 出在外掛，這一步因此是防止再被駭最關鍵的動作：把核心程式、外掛、佈景主題全部更新到目前的最新版本，不要漏掉任何一支。更新的同時，也趁機盤點一下裝了多久沒用的外掛跟佈景主題，用不到的乾脆整支刪掉，而不是只是停用，因為停用的檔案還是留在伺服器上，一樣可能藏著沒補的漏洞，刪掉才能真正減少之後要顧的範圍。
wp-config.php 的安全金鑰要重新產生，強制踢掉所有登入
wp-config.php 這支設定檔裡有一組安全金鑰，英文叫 Authentication Unique Keys and Salts，作用是加密使用者的登入階段跟瀏覽器裡的 Cookie。把這組金鑰整批換掉，會讓所有現有的登入階段立刻失效，包含駭客手上可能還留著的那個登入階段，等於強制把所有人，不管是自己還是入侵者，都踢出去重新登入一次。
換金鑰的做法很簡單，到 WordPress 官方提供的安全金鑰產生工具網頁，就會直接產生一整組隨機字串，複製貼上取代 wp-config.php 裡原本那幾行設定即可。這一步很多人會漏做，因為就算前面已經清完檔案、換完密碼，只要駭客手上還留著一個有效的登入階段，換密碼這件事對他來說幾乎沒有影響，直到金鑰被換掉，那個登入階段才會真正失效。
檔案權限要調整，關掉後台檔案編輯功能
接下來把目錄跟檔案的權限收緊到一般建議的安全值，資料夾通常設定成 755，檔案設定成 644，避免權限開得太寬，讓原本不該有寫入權限的角色也能修改檔案內容。同時在 wp-config.php 裡加上一行設定，把後台的佈景主題編輯器跟外掛編輯器關掉。這兩個編輯器原本是方便管理者直接在後台修改程式碼用的，但萬一哪個帳號之後又被入侵，關掉它就能避免對方直接在後台編輯器裡竄改程式碼，省去一道原本不需要存在的風險。
這幾件事都做完之後，回頭再看一次使用者清單，確認第二階段抓到的陌生帳號已經徹底刪除，現有的每一個帳號權限也都設在合理範圍內，不要有明明只需要看文章統計，卻被設成管理員權限的帳號。這一關沒有再三確認，前面三件事做得再徹底，都可能因為留著一個權限過高的帳號，讓漏洞用另一種方式重新打開。
網站清乾淨之後，還要向 Google 申請審查嗎？
解除維護模式之前，先花一點時間做最後一輪檢查：前台每個頁面顯示正常、登入功能正常運作、資料庫跟檔案裡沒有殘留的可疑內容，確認過一輪之後，才正式讓網站重新上線。
如果先前 Google Search Console 曾經跳出安全性問題的警告，清乾淨之後不會自動恢復正常，得主動在報告裡提出審查申請，說明已經修正哪些問題，否則警示會一直掛著，搜尋結果旁的警告標籤跟瀏覽器的插頁警示都不會自己消失。根據 Google 官方的說明，多數審查作業需要幾天到幾週的時間，少數案例可能更久，審查期間 Google 會透過電子郵件通知進度。這段等待的時間也不是完全沒事做，可以趁機持續監控網站有沒有再出現異常，像是又冒出陌生帳號、流量忽然出現怪異的高峰，確保問題真的已經清乾淨，不是等審查通過才發現又復發一次。
反覆清不乾淨，該找誰求助？
照著上面的流程走一遍，大多數狀況都能處理完。但有幾種情況，代表該找專業協助，而不是繼續自己摸索：
- 清過一輪之後問題還是反覆出現，代表後門根本沒找乾淨，某個角落還留著能重新開門的破口
- 網站牽涉會員資料或線上交易，一旦處理不完整導致資料外洩，後續要負的責任遠比單純的網站當機嚴重
- 完全找不到問題出在哪一支檔案，清查了老半天毫無頭緒
- 自己沒有把握處理資料庫層級的清查，擔心一個不小心把正常的資料也清掉
國內的企業或組織如果遇到資安事件，可以透過 TWCERT/CC（台灣電腦網路危機處理暨協調中心）這個正式的通報協處窗口尋求協助，這個機構專門處理資安事件通報、漏洞通報，也提供資安情資交流，不是只能自己硬扛，也不必病急亂投醫、隨便找一個聲稱能處理的人。一般個人網站或中小型網站，則可以洽詢有實際資安鑑識能力的服務商，處理之前先問清楚幾件事：對方怎麼確認網站已經清乾淨，清完之後的保固期多久，萬一保固期內又復發，是不是還會繼續協助處理。
處理完一次網站被駭，真正傷本的往往不是清理花掉的那幾個小時，而是清完就當作沒發生過，沒有把先隔離、再清除、後補強這套順序留下來，變成下一次的標準作業流程。下次不管是自己動手，還是找專業協助，照著同一套順序走，都能少走很多冤枉路，也不會在慌亂之中漏掉關鍵的一步。
比起事後補救，更值得投入心力的是回頭把基本功顧好：核心程式、外掛、佈景主題有沒有定期更新，密碼有沒有夠複雜且不共用，備份機制是不是真的定期在跑、而且備份本身也要確認乾淨。把這幾件事顧好，才是讓被駭後的處理流程這篇文章，派不上用場的最好方法。