10月21日，PHP官方一口氣釋出8.5.12、8.4.27、8.3.36、8.2.35四個安全版本，並發出一則標題寫著「update now」的嚴重等級公告。對我們這種每天在維護客戶官網、電商、政府系統的團隊來說，這種公告一出來，當週的工作排序就得重新洗牌。
這篇用比較白話的方式整理：這次到底發生什麼事、WordPress網站會不會中、以及我們實際在做的升級步驟。
一、這次修了什麼？兩個可遠端執行程式碼的漏洞
這次公告處理的是兩個RCE(Remote Code Execution，遠端執行程式碼)漏洞，CVSS v4.0評分9.2：
- CVE-2026-109618：PHP在記憶體不足(OOM)時，可能在請求資料只初始化一半的狀態下被中斷，後續清理流程把不完整的資料當成有效資料處理。
- CVE-2026-109619：某些屬於「單次請求」的內部狀態，在記憶體釋放後仍殘留，同一個worker處理下一個請求時可能誤用。
白話來說：攻擊者有機會透過特製的請求，在你的主機上執行他想執行的程式。官方特別點名Apache + mod_php風險最高，因為攻擊可以在任何網站程式碼執行之前就被觸發——也就是說，不管你的WordPress外掛寫得多乾淨，都擋不住。PHP-FPM、php-cgi、FrankenPHP、LiteSpeed也都在影響範圍內。
官方的態度也很明確：沒有完整的緩解方式，升級是唯一真正安全的做法。
二、WordPress網站會受影響嗎？
會。WordPress本身就是PHP程式，只要主機上的PHP版本低於上面那四個修補版本，就在風險範圍內。這跟WordPress核心版本、佈景主題、外掛無關，是底層執行環境的問題。
比較麻煩的是還停在PHP 8.1或更舊版本的網站。PHP 8.1已經在2025年底結束安全支援，官方這次只針對7.4、8.0、8.1提供「最小限度的原始碼修補分支」，需要自己編譯，或仰賴Linux發行版、LTS廠商的套件。對一般企業官網來說，這通常代表：該升級了，不能再拖。
三、順便看一下時間表：PHP 8.2年底也要退休
這次事件剛好碰上另一個時間點。依照PHP官方支援週期，PHP 8.2的安全支援將在2026年12月31日結束，PHP 8.3則到2027年底。換句話說，如果你這次只是從8.2.x升到8.2.35，兩個月後還是得面對下一次大版本升級。
WordPress這邊，今年5月釋出的WordPress 7.0已經把最低需求從PHP 7.2拉到7.4，新安裝建議使用PHP 8.4或8.5。我們的建議是：既然都要動，不如這次直接規劃到8.3或8.4，一次把時間拉長。
四、我們實際在做的升級步驟
以下是KYART維運客戶網站時的實際流程，供自行管理主機的朋友參考：
- 先盤點：到WordPress後台「工具 → 網站健康狀態 → 資訊 → 伺服器」確認目前PHP版本與SAPI(FPM或mod_php)。
- 先備份：資料庫與wp-content完整備份，雲端主機可以先做一份快照。
- 在測試站先跑：把網站複製到staging環境升級PHP，逐頁檢查前台、後台、表單、金流、會員登入這些容易出事的地方。外掛與佈景主題太久沒更新的，通常就是升級後報錯的那一個。
- 正式升級：依主機類型透過套件管理器、控制台或映像檔更新，升級後記得重啟所有PHP-FPM / Apache worker。
- 升級後觀察：開著錯誤日誌觀察一兩天，確認沒有deprecated或fatal error堆積。
五、真的沒辦法馬上升級怎麼辦？
官方有列出幾個暫時降低風險的設定，但也強調「不會讓系統變安全」，只能爭取時間：
- 在php.ini或FPM pool設定
session.upload_progress.enabled = 0，並重啟所有worker(官方提醒不要依賴ini_set()或.user.ini)。 - 依網站是否需要上傳檔案，調低
post_max_size，並在Web Server或反向代理層限制請求大小與欄位數量。
這些只是緩兵之計。真正的解法還是排進這一兩週的維運時程，把PHP升上去。
網站上線只是開始，能長期安全地跑下去，才是真正的完成。
每次這類公告出來，我們都會再提醒自己一次：客戶看得到的是畫面，看不到的是底下那層每年都要更新的地基。如果你的網站不確定目前跑在哪個PHP版本，或升級後擔心外掛相容問題，歡迎跟我們聊聊。
參考資料：
PHP News Archive 2026(php.net)
WordPress 7.0 Hosting Compatibility(make.wordpress.org)
