Kanorio 行銷團隊 · 發佈於 2026年10月22日
網站明明運作正常，亦沒有收到異常通知，為何突然被要求緊急更新 PHP？2026 年 10 月 21 日，日本首相高市早苗透過公開帖文呼籲網站管理員準備套用 PHP 修補程式，令原本偏向技術性的資訊安全議題受到更多關注。
如果您使用 WordPress 建立網站，這次最需要確認的是：網站實際使用的 PHP，是否已完成安全更新。只在 WordPress 後台更新插件，並不能代替主機端的 PHP 修補。
本文將整理本次漏洞、版本檢查方式與不同主機環境的處理步驟，並說明暫時無法更新、更新後出錯，以及疑似遭入侵時的應對方案。即使您不是工程師，亦能知道該聯絡誰、該確認哪些事項。
參考資料：高市早苗公開帖文、PHP 官方安全公告
這次公告涉及兩項 PHP 漏洞：CVE-2026-109618 與 CVE-2026-109619，可能讓未登入的攻擊者在受影響環境中執行程式碼。問題位於 PHP 執行環境，並非某一款 WordPress 插件的專屬漏洞。
您可以將 WordPress 理解為網站的內容管理工具，而 PHP 則是支撐其運作的一部分。即使 WordPress 本身已更新，底層 PHP 仍可能需要另外處理。官方亦提醒，風險不只存在於單一伺服器部署方式。
然而，「網站存在漏洞」、「網站暫停服務」與「網站已遭入侵」是三件不同的事。例如日本財務省公告，為了緊急檢查與套用修補，暫停部分內容及服務。這類預防性停站，不能直接解讀成網站遭駭。
對網站經營者而言，現在應優先確認自身環境，不必等待網站出現異常才處理。
參考資料：PHP 官方安全公告、日本財務省｜因應 PHP 漏洞暫停部分服務公告
進入 WordPress 後台的「工具 → 網站狀態」，切換至資訊頁籤，查看伺服器相關資訊；介面名稱可能因版本與語系略有不同。您亦可請主機商提供網站目前實際執行的 PHP 完整版本。
不要只記錄「PHP 8」，應取得完整版本號。同一個主機帳戶下的不同網站，亦可能使用不同版本，需要分別確認。
參考資料：WordPress｜網站狀態資訊
截至本文更新日期，PHP 官方發布的本次修補版本如下：
| PHP 分支 | 本次修補版本 | 處理方向 |
|---|---|---|
| PHP 8.2 | 8.2.35 | 更新至此版本，或含相同修補的後續版本 |
| PHP 8.3 | 8.3.36 | 更新至此版本，或含相同修補的後續版本 |
| PHP 8.4 | 8.4.27 | 更新至此版本，或含相同修補的後續版本 |
| PHP 8.5 | 8.5.12 | 更新至此版本，或含相同修補的後續版本 |
| PHP 8.1 及更舊分支 | 不適用上述一般更新路徑 | 向供應商確認回補修正，並安排升級 |
部分 Linux 發行版或長期支援供應商會將修正回補到既有套件，因此不能只憑畫面上的版本號判定。若主機商表示已修補，請取得對應公告、套件版本或修補紀錄，確認涵蓋上述兩項 CVE。
舊分支即使取得本次回補，亦不代表恢復完整的長期安全支援。
| 網站環境 | 優先聯絡對象 | 需要確認的事情 |
|---|---|---|
| 共享主機／虛擬主機 | 主機商客服 | 是否已修補、是否需要自行切換 PHP、網站何時生效 |
| 代管 WordPress | 代管服務商 | PHP 更新是否包含在服務內、完成時間與驗證結果 |
| 自管 VPS／雲端主機 | 工程師或系統管理員 | 所有對外服務實例是否已更新，舊程序是否已替換 |
| 委外建立網站但維護分工不明 | 網站製作公司與主機商 | 由誰執行修補、由誰測試網站、由誰回報完成 |
這張表是聯絡分工建議，實際責任仍須依您的服務合約確認。網站由別人製作，不代表後續 PHP 更新一定有人代為處理。
操作提醒與免責說明：本文依截至 2026 年 10 月 22 日的官方公告整理，供修補參考，不構成個別網站的資訊安全診斷或安全保證。不同主機、佈景主題與插件的相容性可能不同，操作前請確認備份可還原，並由主機商或維護人員確認適用方式。若疑似已遭入侵，應另行調查，不能僅以更新完成判定安全。
更新前，確認網站檔案與資料庫都有備份，亦確認由誰負責還原。只下載文章內容，通常不足以還原整個網站。
但不要因為備份或測試需要時間，就讓尚未修補的網站持續暴露。若無法立即處理，應請維護人員評估先限制外部存取，再完成備份與更新。
若已出現疑似入侵跡象，請先保留紀錄與環境快照；這份快照應標示為待調查資料，不能直接當成乾淨備份使用。
參考資料：WordPress｜更新 PHP 前的準備、WordPress｜網站遭入侵時的處理、CERT-EU｜修補與隔離建議
共享主機使用者應依主機商公告或客服指示操作；若控制台只能選擇「8.3」或「8.4」，仍要確認背後實際套用的修補版本。
自管主機則由系統管理員依作業系統、套件來源或容器部署方式更新。本文不提供一組通用指令，因為不同環境的套件名稱與服務管理方式並不相同。
本次修補的重點是 PHP 執行環境。WordPress 核心、佈景主題與插件仍應維持更新，但不能把這些更新當成 PHP 已完成修補。
參考資料：PHP 官方安全公告
請維護人員確認相關服務已依部署方式重啟或重新部署，沒有繼續使用舊的 PHP 工作程序。若網站有多台主機或多個容器，應逐一確認。
不要只依命令列上的 PHP 版本結案。命令列與網站服務可能使用不同執行環境，驗證對象應包含實際回應訪客請求的服務。
這是更新驗收的實務重點：套件已下載、控制台已切換與網站已使用修補版本，不能只看其中一項。
建議至少完成以下檢查：
這份清單用來確認修補與基本功能，不等同於完整的入侵鑑識或資訊安全稽核。
例如，一間使用共享主機的設計工作室，收到漏洞消息後，可以先整理網站網址與 PHP 版本，請主機商確認修補，再由原架站人員測試作品頁與詢價表單。完成的依據應是修補紀錄與測試結果，而非單純「首頁打得開」。這是處理流程示例，並非實際客戶事件。
不要將插件或防火牆視為完整修補。
Cloudflare 已公布針對本次漏洞的防護措施，但網站仍需更新 PHP。是否有流量經過防護、規則是否適用，以及來源主機是否還有其他可直接存取的路徑，都需要管理員確認。
若短時間內無法修補，CERT-EU 建議評估將受影響服務與公開網絡隔離，待修補並驗證後再恢復。技術上的臨時設定亦有適用限制，應交由維護人員評估，不建議一般網站經營者照抄陌生設定。
尤其要注意：開啟 WordPress 維護模式，不一定能阻止請求到達有漏洞的 PHP。部分攻擊路徑可能在網站應用程式執行前觸發，因此維護頁面不能直接視為完成隔離。
參考資料：Cloudflare｜本次 PHP 漏洞防護說明、CERT-EU｜PHP 重大漏洞處置
更新後的錯誤可能與佈景主題、插件或自訂程式的相容性有關，應請維護人員查看錯誤紀錄，再調整相關元件。
不要只為恢復畫面，就把公開網站切回尚未修補的 PHP。若必須回復環境進行排查，應先限制外部存取，再安排能正常運作且已修補的版本。
這些都是需要調查的警訊，但不能僅憑其中一項，就判定一定由本次漏洞造成。
請聯絡主機商或資訊安全維護人員，保留存取紀錄、錯誤紀錄與環境快照，依情況隔離網站、清理或重建環境，並處理可能外洩的帳戶憑證。不要急著刪光異常檔案，令後續無法追查。
更新 PHP 能處理漏洞，卻不會自動移除已植入的後門。同樣地，還原備份亦需要確認備份時間、內容是否乾淨，以及恢復後的環境是否完成修補。
參考資料：WordPress｜網站遭入侵時的處理
這次事件亦提醒小品牌，選擇架站工具時，應確認日後由誰負責安全更新與異常處理。
以 Kanorio 為例，公開網站採用 Cloudflare 邊緣網絡，提供 DDoS 緩解與 WAF 防護，並自動管理 SSL 憑證及 HTTPS 連線，減少品牌自行設定基礎防護的工作。但這些措施不代表零風險；經營者仍需保護帳戶並留意異常。本文亦不以這些功能推定平台對本次漏洞完全不受影響。
詳情請見：Kanorio 網站資訊安全保障
需要分開確認。WordPress 是網站應用程式，PHP 是底層執行環境；本次漏洞的修補重點在 PHP，請取得主機端的修補確認。
網站可正常開啟，不能證明沒有風險。應儘速確認修補狀態；無法立即更新時，與維護人員討論限制存取或暫停服務。
可能是供應商採用回補修正。請主機商提供套件或安全公告，確認涵蓋 CVE-2026-109618 與 CVE-2026-109619，不能只靠口頭表示「有防護」判定。
參考資料：PHP 官方安全公告
不能直接這樣判斷。備份可能已包含異常內容，恢復環境亦可能仍使用未修補 PHP；疑似入侵時，需另外調查與驗證。
參考資料：WordPress｜網站遭入侵時的處理
如果您現在不知道從哪裡開始，先找出主機商或維護窗口，確認三件事：網站實際使用哪個 PHP 版本、這次兩項漏洞是否已修補、由誰驗證更新後的功能。
對沒有工程人力的工作室與小品牌，往後評估架站服務，亦應把安全更新與維護分工納入考量。可從 Kanorio 資訊安全保障說明了解平台提供的基礎防護，再依網站需求安排適合的維護方式。