PHP 終止維護究竟指的是什麼？
所謂 PHP 終止維護（End of Life），是指該版本已不會再收到官方推出的安全更新。 到 2026 年 11 月，7.4、8.0 與 8.1 皆已結束，8.2 也將於 2026 年 12 月 31 日截止。網站若仍停在這些版本，往後被發現的安全問題就不會再有官方補丁。
PHP 可比作大樓的承重骨架，頁面與功能都建在其上。維護結束類似營造廠表示不再派員檢查或修繕：建物仍可入住，但之後的結構瑕疵必須自己想辦法。
與業主溝通時，經常出現「網站沒故障，為何要升級？」的疑問。多數時候聽起來合理，直到漏洞真正曝光的那一天。
從 2026 年 10 月的 PHP2Shell 能學到什麼
2026 年 10 月 21 日，PHP 官方緊急處理兩個合稱 PHP2Shell 的漏洞（CVE-2026-109618、CVE-2026-109619），嚴重分數均為 CVSS 9.2。缺陷位於解析連線請求的階段，網站程式尚未執行就可能遭到利用。對方不必取得帳號，站內既有的登入與表單驗證也起不了阻擋作用。
這次事件有三點適合企業記住：
- 正式修補只發給 8.2 及以上：包含 8.2.35、8.3.36、8.4.27、8.5.12。7.4、8.0、8.1 僅有原始碼層級修正，還須等待主機商或作業系統廠商重新封裝，有些反應遲緩，有些則完全不處理。
- 入侵嘗試早於公開說明：國外雲端服務在公告前 4 天已看到攻擊行為，公告後數日內自動化掃描迅速增加。掃描對象涵蓋整個網路，不會挑公司大小。
- 主機商更換 PHP，不等於網站已脫險：許多網站留在舊版，是因為程式一換新版就會出錯，主機商因此不願更動。
直接說，終止維護的風險平時不易看見，要等下一個像 PHP2Shell 這樣的漏洞，損失才會集中出現。
目前各版本還能維護多久
現行 PHP 版本通常先有約兩年的一般維護，同時修錯誤與安全問題，其後再約兩年只處理安全更新，合計大約四年。下表是各版本目前的情形：
| 版本 | 安全支援截止日 | 2026 年 11 月現況 | 建議方向 |
|---|---|---|---|
| 7.4 | 2022-11-28 | ✗ 終止已滿四年 | 應盡快升級，通常要連框架一起處理 |
| 8.0 | 2023-11-26 | ✗ 維護已結束 | 宜盡早安排升級 |
| 8.1 | 2025-12-31 | ✗ 維護已結束 | 建議盡速升版 |
| 8.2 | 2026-12-31 | ! 剩餘不到兩個月 | 年底前排入時程 |
| 8.3 | 2027-12-31 | ✓ 只剩安全更新 | 尚可使用，明年再規劃 |
| 8.4 | 2028-12-31 | ✓ 仍在維護期 | 新專案與升級的優先版本 |
| 8.5 | 2029-12-31 | ✓ 仍在維護期 | 新專案與升級的優先版本 |
較穩妥的做法是一次升到 8.4 或 8.5。若只停在 8.3，明年底多半還要再測一輪，等於同一套驗證付兩次錢。
如何查出網站實際的 PHP 版本
現場常見的狀況是，負責人並不知道網站跑哪一版，當初的廠商也已經聯絡不到。確認方式大致有三種：
- 向維護廠商或主機商詢問：請對方提供網站「真正在執行」的 PHP 版本。同一台主機可能同時安裝數個版本，控制台看到的不一定是網站正在用的。
- 進入主機管理後台：cPanel、Plesk 這類介面多半有「PHP 版本」或「PHP 設定」頁面。
- 查看回應標頭：有些網站會在回應裡帶出版本號，但多數主機為了安全會隱藏，查不到屬於正常情況。
一併確認網站使用的內容管理系統或程式框架，以及該框架自身的版本。框架也有獨立的維護期限，舊框架常常無法搭配新版 PHP，所以兩者往往要一起升級。
維持舊版、購買延長維護，或升級到新版
一旦確認網站使用的是已終止維護的版本，實際上可以走三條路：
| 對照項目 | 繼續沿用舊版 | 付費延長安全維護 | 升到 8.4 或更新 |
|---|---|---|---|
| 能否收到安全修補 | ✗ 收不到 | ! 取決於廠商，常常延後 | ✓ 有官方正式修補 |
| 短期支出 | ✓ 當下不用付錢 | ! 每年都要付費 | ! 一次付清的升級費用 |
| 長期支出 | ✗ 出事後的復原成本難以估計 | ✗ 年年付費，問題依舊 | ✓ 之後只需例行的小版本更新 |
| 新外掛與新功能是否可用 | ✗ 愈來愈多新套件不支援舊版 | ✗ 同樣無法使用 | ✓ 可以使用 |
| 主機商是否繼續提供該版本 | ✗ 不少主機商會強制撤下舊版 | ! 要先確認主機商是否配合 | ✓ 會繼續提供 |
| 適合什麼情況 | 網站即將下線或準備整站改版 | 三到六個月內要改版，需要過渡 | 網站還要再使用兩年以上 |
判斷可以很直接：網站若還要再用兩年以上，就安排升級；若半年內要整站改版，就把預算留給改版，過渡期間請主機商先套上暫時的防護。最不建議「先擱著，等出事再談」。網站被入侵後的清除與復原，花費和停機時間通常都比升級更高。
動手升級時，哪些環節必須一起改
不少人以為升級 PHP 只是主機商按一個按鈕。按鈕確實有，但舊網站按下之後，常見結果是白畫面、後台無法登入，或結帳時發生錯誤。原因是下面幾個部分要一起調整：
- 網站程式本身：新版 PHP 移除了部分舊語法，寫得越早的網站要改的地方越多。從 7.4 跨到 8.4 經過好幾個版本，工作量與從 8.2 升到 8.4 相差很大。
- 外掛與套件：網站使用的外掛和程式套件都要換成支援新版的版本，已經停更的外掛則需尋找替代。
- 金流與電子發票串接：金流與電子發票廠商的套件通常要一併更新，而且要在測試環境實際完成一筆付款、開立一張發票，確認付款狀態與通知信都正常。
- 資料庫寫法：少數舊式查詢在新的資料庫連線方式下會失敗。
工期視網站規模而定。有會員、購物車、金流或多語系的網站，要驗證的項目較多，時間也較長。仍使用 8.2 的網站，建議現在就請廠商評估時程，才有機會在年底前完成。
施工前後建議逐項確認的問題
委託廠商升級時，可以直接用下表提問。回答具體，代表對方做過規劃；回答含糊，代表風險仍留在自己這邊：
| 要提出的問題 | 值得放心的回答 | 需要留意的回答 |
|---|---|---|
| 施工前會不會備份？ | 程式與資料庫都會完整備份，出問題可以還原 | 「主機商應該有備份」 |
| 升級在哪裡進行？ | 先在測試站做完，驗收通過才切換正式站 | 「直接在正式站修改，比較快」 |
| 會驗證哪些功能？ | 依網站實際功能列出清單，包含表單、會員、購物車與各種付款 | 「首頁打得開就可以」 |
| 金流要如何確認？ | 每種付款方式各下一筆測試訂單，核對付款狀態與通知信 | 完全沒有提到金流 |
| 升級後若出問題怎麼處理？ | 有明確的保固期間與回覆時限 | 「以後再商量」 |
| 框架和外掛會不會一起升？ | 會，並說明哪些外掛需要替換 | 「只更換 PHP 版本」 |
升級完成後的第一週，要特別看錯誤紀錄、表單通知信是否正常寄出，以及訂單與付款狀態。建議把 PHP 版本納入每年的網站維護項目，在支援截止前一年就排好下一次升級，不要每次都等漏洞公告才動作。維護預算可以依客製網站每年需要照顧的範圍來估算。
結語：別等到下一個漏洞才處理升級
很少人覺得 PHP 升級有趣，但它是網站資安裡少數做了就會降低風險的工作。可以記住下面三點：
- 先查版本，再決定要不要支出：只有知道網站與主機實際使用的 PHP 和框架版本，才判斷得出風險。
- 還要再用兩年以上就升級，而且直接升到 8.4 以上：避免明年把同一套測試再做一次。
- 升級必須先在測試站完成：先備份、逐項驗收，再切換上線，正式網站在施工期間仍可正常營運。
若還不清楚網站現況，可先依資安防護要點做一次盤點，或請目前的維護人員協助查看版本，以及需要調整的範圍。
