1. 首頁
2. 知識庫
3. Sharing AI 架站平台教學
4. PHP 與 WordPress 漏洞怎麼防？站長檢查清單與架站平台的責任分工

Sharing AI 架站平台教學

PHP 與 WordPress 漏洞怎麼防？站長檢查清單與架站平台的責任分工

作者：JamXu更新日期：2026-10-22

這波 PHP 與 WordPress 漏洞發生了什麼？

2026 年 10 月下旬，網站圈接連出現兩類消息：一是 PHP 這個伺服器端程式語言本身的重大漏洞，二是 WordPress 核心與外掛的安全修補。兩者會一起被討論，是因為 WordPress 正是用 PHP 寫成的。依 WordPress 官方〈網站健康狀態〉說明文件的描述，PHP 是用來建立與維護 WordPress 的程式語言；只要 PHP 有洞，跑在上面的 WordPress 網站就一起暴露在風險裡。

先看 PHP 的部分。PHP 安全團隊在 10 月 20 日預告將發布重大安全更新，兩個漏洞的 CVSS v4.0 分數都是 9.2；但漏洞細節在預定公布前就已在網路上流傳。PHP 官方在 10 月 21 日發布的安全公告指出，8.5.12、8.4.27、8.3.36 與 8.2.35 這四個版本修補了兩個可讓未經驗證者遠端執行程式碼的漏洞，並呼籲所有使用者立即更新；公告也明列風險範圍涵蓋所有提供網頁服務的 PHP 安裝方式，包括 PHP-FPM、Apache 搭配 mod_php、php-cgi、FrankenPHP 與 LiteSpeed。

再看 WordPress。WordPress 官方在 9 月 22 日發布的 7.1.2 版修補了一個重大漏洞（CVE-2026-87902）：未登入的攻擊者可以讓頁面範本的載入流程引入主機上指定的 PHP 檔案，在特定的伺服器與佈景主題條件下可導致遠端執行程式碼。這個漏洞影響 4.7 到 7.1.1 的版本，官方把修補一路回推到 4.7 系列；美國網路安全暨基礎設施安全局（CISA）在 9 月 25 日把它列入「已知遭利用漏洞」清單，代表已經有實際的攻擊。10 月 6 日的 7.1.3 版又修補了 7 個安全問題；外掛方面，Bricksforge 外掛的檔案上傳漏洞（CVE-2026-85097）可讓未登入者上傳並執行 PHP 程式，資安公司 Patchstack 在 10 月上旬回報已遭攻擊。

PHP 漏洞公布當天，WordPress 官方也發文提醒：這次的漏洞不是 WordPress 專屬，任何執行 PHP 應用程式的伺服器都受影響，WordPress 本身不需要也不會為此推出更新，站長要做的是盡快更新 PHP。官方同時指出，PHP 8.2 以前的版本已不再有安全更新，自行管理主機又還在用舊版本的站長，應考慮在升級完成前先讓伺服器離線。下表整理近期與 WordPress 網站相關的事件：

這兩件事放在一起看，重點不在於哪一套軟體比較不安全，而是漏洞公布到被拿來攻擊的時間越來越短。PHP 這次是細節先外流、修補隨後發布；站長若習慣「等有空再更新」，中間的空窗期就是網站最危險的時候。

為什麼一個 PHP 漏洞會影響這麼多網站？網站的四層結構

很多經營者對網站的想像只有「後台」與「前台」，但一個自架的 WordPress 網站，實際上是由好幾層軟體疊起來的。每一層都可能有漏洞，也各自需要有人負責更新。把這四層分清楚，才知道這次的事件落在哪一層、該找誰處理。

這張表最重要的一欄是最後一欄：自架網站的每一層，都要能指出一個具體的負責人；如果答案是「應該是主機商吧」或「當初的外包有說會處理」，就代表這一層很可能沒有人在管。共用虛擬主機的 PHP 版本通常由主機商統一升級，但也有主機商讓客戶在控制台自行切換版本；租用雲端主機或 VPS 的話，作業系統與 PHP 幾乎都得自己更新。

外掛是另一個常被忽略的地方。WordPress 的彈性來自外掛，但每多裝一個外掛，就多一個需要追蹤更新的來源。外掛停止維護後不會自動消失，它會繼續留在網站上，直到有人把它刪掉。這也是後面的檢查清單會特別強調「移除用不到的外掛」的原因。

我的網站受影響嗎？五分鐘自我檢查

不必懂程式也能做初步判斷。下面五個問題依序回答，就能知道自己的網站落在哪一種風險等級，以及下一步該找誰：

1. 網站是不是用 PHP 系統架的？WordPress、Drupal、Joomla、Magento 都是用 PHP 寫成的系統。如果網站是用代管型架站平台建立、你從來沒有接觸過主機或 PHP 設定，這一層通常由平台負責，直接跳到第 4 題。
2. PHP 目前是哪個版本？WordPress 官方建議到後台的「工具 → 網站健康狀態 → 資訊 → 伺服器」查看，PHP 版本過舊時「狀態」分頁也會提示；也可以在主機商的控制台查看，或直接寫信問主機商。
3. 主機商有沒有發布這次漏洞的處理公告？多數主機商會在官網或寄信說明已完成更新的時間。沒有公告也沒有回覆時，請主動詢問並留下書面紀錄。
4. WordPress 核心、外掛與佈景主題是不是都是最新版？後台的「控制台 → 更新」會列出所有待更新的項目。
5. 最近有沒有出現不認識的管理員帳號、陌生檔案或可疑的頁面？有的話，先跳到本文「如果懷疑已經被入侵」一節，不要只做更新。

依 PHP 官方的支援版本表，目前仍有安全更新的是 8.2、8.3、8.4 與 8.5，其中 8.2 的安全支援只到 2026 年 12 月 31 日。WordPress 官方的主機需求頁則建議使用 PHP 8.3 以上；如果你的主機還停在 8.1 以前的版本，這次的漏洞不會再有官方正式版本修補，升級 PHP 是唯一的長期解法。

更新到這些版本，就能逃過這次的漏洞了嗎？

對 PHP 這兩個漏洞來說，答案是肯定的：更新到所在分支的修補版本（並重新啟動所有 PHP 程序，讓新版本真正生效），就能修補 CVE-2026-109618 與 CVE-2026-109619。但更新 PHP 只修補 PHP 本身，不會修補 WordPress 核心、外掛或佈景主題的漏洞；前面提到的 WordPress 7.1.2、7.1.3 與外掛的安全更新，都要另外安裝。如果網站在更新前已經被入侵，更新也不會清除攻擊者留下的後門。

還有兩個常見的落差要留意。第一，使用虛擬主機或代管主機時，PHP 由主機商更新，各家完成的時間不一，請以主機商的公告或書面回覆為準，不要只憑控制台的版本選單判斷。第二，Linux 發行版的套件常以「回推修補」的方式處理，例如 Debian 的安全追蹤頁就列出以 8.2.35、8.4.27 為基礎的修補套件，而 Ubuntu 也為舊版本提供延伸支援的修補，套件的版本字串不一定和 PHP 官方版本號完全相同；自管主機要看的是發行版的安全公告是否已標示修補完成，而不是只比對版本號。

依主機類型，這次該怎麼更新

同樣是 WordPress，放在不同的主機上，更新 PHP 的人和方法也不一樣。先找出自己屬於哪一種，再照對應的做法處理：

WordPress 官方的公告也提到，主機商可能已經在更新 PHP，並先部署網站應用程式防火牆（WAF）規則來降低風險；即使如此，仍要向主機商確認 PHP 已經更新完成，防火牆規則只是過渡的保護。

升級 PHP 版本有時會讓舊外掛或舊佈景主題出錯，這是很多站長遲遲不敢升級的原因。比較穩妥的順序是：先完整備份，再請主機商或工程師在測試環境切換版本，逐頁檢查表單、購物車、會員登入等關鍵功能，確認沒問題後才套用到正式網站。

WordPress 站長現在就該做的事：一份分時程的檢查清單

如果你決定繼續使用 WordPress，這一節就是本文最實用的部分。WordPress 本身不是不安全的系統，有人持續維護的 WordPress 網站，風險可以降到相當低；真正出問題的，多半是沒有人在更新、外掛裝了就不管的網站。以下依急迫程度分成三段：

這 72 小時內：先把已知的洞補起來

• 確認 PHP 已更新：向主機商確認已更新到本次的修補版本，並請對方提供完成時間；自管主機則依作業系統的套件管理工具更新並重新啟動所有 PHP 程序。
• 更新 WordPress 核心：到「控制台 → 更新」確認核心為最新版本。依 WordPress 官方的版本公告，支援自動背景更新的網站會自動開始安裝安全版本；若自動更新曾被關閉或主機環境不支援，就要手動處理。
• 更新外掛與佈景主題：逐一更新，特別留意表單、會員、檔案上傳、頁面編輯器這類會處理訪客輸入的外掛。
• 確認有一份更新前的完整備份：包含檔案與資料庫，並存放在主機以外的地方。

這個月內：把攻擊面縮小

• 移除用不到的外掛與佈景主題：停用不等於移除，停用的外掛檔案仍在主機上。只保留一個預設佈景主題當備援即可。
• 淘汰停止維護的外掛：在外掛頁面查看最後更新時間；長期沒有更新、或已從官方外掛目錄下架的外掛，找替代方案。
• 整理管理員帳號：刪除離職同事與已結案外包的帳號，日常編輯改用權限較低的角色，管理員帳號全部改用高強度密碼並開啟兩步驟驗證。
• 加上網站應用程式防火牆（WAF）：可以用主機商提供的方案、雲端服務或安全外掛。WAF 能在修補完成前擋下部分已知的攻擊手法，但不能取代更新。
• 測試一次還原：從備份實際還原到測試環境，確認備份真的能用。沒有測試過的備份，出事時常常才發現不完整。

長期：讓維護變成固定流程

• 指定負責人與頻率：每週檢查一次待更新項目，每月檢查一次帳號與外掛清單，寫進行事曆而不是靠記憶。
• 訂閱安全通知：關注 PHP 官方公告、WordPress 官方部落格的版本發布消息，以及主機商的安全公告。
• 開啟 Search Console 並留意安全性問題：Google 發現網站遭入侵時會在報表中通知，這常是站長最早得知問題的管道。
• 記錄每次變更：誰在什麼時間更新了什麼，出問題時才能快速回推。

這份清單的代價是時間與人力。對有工程師或長期合作維護廠商的公司來說，這些工作可以排進固定流程；但如果網站是幾年前外包做好、之後就沒有人碰過，清單上的每一項都可能沒有人做。架設公司網站要花多少錢一文把自架網站的成本拆成主機、授權與維護人力，可以用來估算這部分的預算。

如果懷疑已經被入侵：處理順序

常見的入侵徵兆包括：後台出現不認識的管理員帳號、首頁被改、訪客被導向陌生網站、Google 搜尋結果出現大量不屬於你的網址，或瀏覽器在開啟網站時跳出警告。這時候只更新外掛或 PHP 並不夠，因為攻擊者可能已經留下後門。建議依下列順序處理：

1. 保存現況：先截圖、記下發現的時間與異常內容，並請主機商保留存取紀錄，方便之後判斷入侵途徑。
2. 限制損害：必要時暫時把網站切換成維護模式，避免訪客持續被導向惡意網站或下載惡意程式。
3. 更換所有密碼：WordPress 管理員、主機控制台、FTP／SFTP、資料庫、網域註冊商與 DNS 代管的帳號都要換，並開啟兩步驟驗證。
4. 從乾淨的備份還原或請專業人員清理：選擇入侵發生前的備份；無法確定時間點，就請熟悉 WordPress 的資安人員協助清除後門。
5. 補上漏洞再上線：更新 PHP、核心、外掛與佈景主題，移除可疑與不再使用的外掛，確認沒有陌生帳號與檔案。
6. 處理搜尋結果：到 Search Console 查看安全性問題報告，修正後提出審查要求。

依 Search Console 說明中心的〈安全性問題報告〉，Google 判定網站遭到入侵時，報告會列出問題類別與受影響網頁示例，受影響的網頁在搜尋結果中可能顯示警告標籤。說明文件特別提醒，必須修正網站上所有網頁的問題，再於報告中要求審查。至於駭客建立的大量垃圾網址，Google 搜尋結果怎麼移除說明了用移除工具處理被駭網址的做法與限制。

如果網站有會員或訂單資料，還要評估個人資料是否外洩，並確認是否需要通知當事人或主管機關；這部分涉及法律責任，建議諮詢專業人士，不要自行判斷。

自架網站的資安維護，實際要花多少心力？

把前面的清單換算成工作量，就能看出自架網站的「隱形成本」。下表列出常見的維護工作，不同網站的頻率會有差異，但項目大致相同：

對很多中小企業來說，網站是行銷工具而不是核心系統，公司裡也沒有專職的工程人員。結果就是：網站剛上線時一切正常，兩三年後外掛版本一路落後，直到某天被入侵才發現沒人在管。自架的彈性與維護責任是綁在一起的，享受前者，就要為後者編列人力或預算。

網站系統、佈景主題或外掛已經停止更新，也是判斷網站是否該改版的訊號之一，網站什麼時候該改版整理了包含這個訊號在內的完整判斷方式。

代管型架站平台的取捨：平台管什麼、你還要管什麼

另一種做法，是把伺服器、執行環境與系統更新交給平台。代管型架站平台（也就是 SaaS 架站平台）由平台方統一維護主機與程式，使用者只在後台管理內容。這樣做的好處是不必追蹤 PHP 版本或外掛更新，代價則是彈性較低：不能隨意安裝第三方外掛，也不能自行修改伺服器設定。

以 Sharing AI 架站平台為例，依官方價格頁（服務方案版本 20260607）與Sharing AI 架站平台教學整理的說明，平台方負責的項目包括：

• 主機與流量：費用已包含雲端伺服器空間與流量，不需另外購置或維護主機；網站總頁數超過 500 頁或有高流量需求時，需另外評估。
• 系統升級：後台功能採用全用戶統一版本，系統由平台不定時自動升級，使用者不需要自己安裝更新。
• HTTPS 與安全標頭：提供全站 SSL 安全憑證，並支援 Header Security 等網站安全防護設定；自有網域綁定完成後，後台會顯示「已通過，含 SSL」。
• 表單防護：在「設定 → 基本 → 安全性」可設定表單送出驗證，使用 Cloudflare Turnstile 擋下自動程式。
• 變更紀錄：後台的「異動記錄」可查看誰在什麼時間修改了哪筆資料。

換句話說，在代管平台上，「伺服器與作業系統」「執行環境」「網站系統」這三層由平台負責，使用者擴充網站的方式是平台提供的區塊與設定，以及自己貼入的程式碼。但這不代表網站從此不會出問題，也不代表你沒有任何資安責任。任何平台都可能有漏洞，差別在於修補由平台統一處理，而不是每個站長各自追蹤。

用了代管平台，你仍然要負責的事

表中的「自行貼上的程式碼」值得特別說明。Sharing AI 的行銷代碼欄位與自由設計區塊可以放入第三方程式碼，這提供了彈性，也代表貼進去的程式碼來源要由你把關：只使用官方提供的追蹤代碼，離職同事或已結案廠商留下的程式要定期檢視是否仍需要。網域帳號的管理，自有網域怎麼綁定網站的網域設定表裡有「帳號與負責人」一欄，可以照著填寫。

備份也是要事先問清楚的項目。各平台的備份範圍、保存期間與還原方式不同，使用前先向平台確認；重要的文字與圖片，建議自己也保留一份原始檔，改版或搬家時才有完整素材。

自架 WordPress 還是代管平台？用五個問題判斷

兩種做法沒有絕對的好壞，關鍵是你的網站需要什麼、公司有沒有人力維護。下面五個問題可以幫助你判斷：

如果五題中多數落在右欄，代管平台通常更適合；多數落在左欄，自架 WordPress 能提供你需要的彈性，但請把前面的檢查清單排進固定流程。介於中間的情況，可以先比較兩種做法的完整成本與限制，無程式碼架站是什麼整理了各種架站方式的適用情境與評估重點。

還有一種常見情況是：網站目前跑在 WordPress 上，但已經多年沒有人維護，PHP 版本落後、外掛無法更新。這時候硬著頭皮升級，可能要先修好一連串相容性問題；若網站功能單純，換到代管平台重建，有時比修舊站更省事。兩條路都值得估價比較。

從 WordPress 換到 Sharing AI，要注意什麼？

決定搬家之前，先把三件事準備好，才不會換了平台卻丟了搜尋流量：

• 盤點現有網址：列出所有頁面與文章的網址，標記哪些有搜尋流量或外部連結，決定新網站對應到哪一頁。
• 設定 301 轉址：舊網址要轉到內容相近的新網址。Sharing AI 後台有「重新導向網址」功能，修改頁面自訂連結時平台也會自動建立 301。
• 確認外掛功能的替代方案：原本靠外掛完成的功能，例如表單、社群嵌入、追蹤代碼，先確認新平台有對應的區塊或設定。

完整的搬家流程，包括內容盤點表、網址對照與上線後的 Search Console 監看，都整理在網站搬家怎麼做；網域與 DNS 的切換則在自有網域綁定教學中有逐步說明。搬家當天要注意的是，舊主機上的 WordPress 在 DNS 切換後不要馬上刪除，先保留一段時間當作比對與備援，但記得同樣更新或關閉，避免舊站變成無人管理的入口。

重點整理與檢查清單

把整篇濃縮成一份清單，不論你選擇哪一種架站方式，都可以照著檢查：

• 已確認網站使用的 PHP 版本，並已更新到 8.5.12、8.4.27、8.3.36 或 8.2.35 以上
• PHP 8.2 以前的網站已排定升級時程
• WordPress 核心、外掛與佈景主題都已更新到最新版本
• 已刪除停用與停止維護的外掛及佈景主題
• 管理員帳號已盤點，全部使用高強度密碼並開啟兩步驟驗證
• 有存放在主機以外的備份，且最近一次還原測試成功
• 已開啟 Search Console，並知道安全性問題報告的位置
• 每一層（主機、PHP、網站系統、外掛）都有明確的負責人
• 使用代管平台時，已確認平台負責的範圍，以及自己仍要負責的帳號、網域與程式碼

資安沒有一勞永逸的做法，只有「誰負責、多久檢查一次」的分工。如果你的網站沒有人能固定維護，又只需要形象官網、服務頁、文章與表單這類功能，可以先看看Sharing AI 架站平台介紹，了解平台方案與 30 天免費試用；後台各項功能的操作方式，則整理在Sharing AI 架站平台教學。如果需要協助評估現有網站該修還是該換，也歡迎與我們聯絡討論。