PHP 官方在 10 月 21 日緊急釋出 8.5.12、8.4.27、8.3.36 與 8.2.35，修補兩個可讓未登入攻擊者遠端執行程式碼的嚴重漏洞。問題出在 PHP 執行環境本身，PHP-FPM、mod_php、FrankenPHP、LiteSpeed 全都在範圍內，而且官方說得很直白：沒有完整的緩解方式，只有更新。給 Laravel、WordPress 網站負責人與委外客戶的今日待辦清單。
平常我們談網站資安，焦點多半在「你的程式」：有沒有 SQL Injection、表單有沒有驗證、外掛是不是太久沒更新。工程師可以很驕傲地說：「我們的程式碼都有 code review，權限也設計得很嚴謹。」
這次不一樣。這次破洞的是地基。
台灣時間 10 月 21 日晚上，PHP 官方發布安全公告：兩個被評為 CVSS v4.0 9.2 分的嚴重漏洞，可能讓未經驗證的攻擊者在伺服器上遠端執行程式碼（RCE）。它們被合稱為 PHP2Shell。最刺耳的是這句：問題在 PHP 執行環境本身，所以就算你的應用程式寫得無懈可擊，網站一樣暴露在風險中。
如果你的網站是 Laravel、WordPress、WooCommerce 或任何 PHP 架構，今天這篇請看完，然後去問你的工程師或主機商一個問題：「我們更新了嗎？」
發生了什麼事？
根據 PHP 官網公告，這次修補的版本是 PHP 8.5.12、8.4.27、8.3.36 與 8.2.35，修的是兩個漏洞：
- CVE-2026-109618：記憶體不足（OOM）造成的資料損毀。 PHP 在處理請求時如果記憶體不足被中斷，部分內部資料可能還沒初始化完成；接下來清理請求時，PHP 可能把這些不完整的資料當成有效資料使用。
- CVE-2026-109619：過期的全域狀態。 屬於某個請求的內部狀態，在記憶體被釋放後仍然殘留；同一個 worker 處理下一個請求時，可能在正常初始化之前就用到這些過期狀態。
Cloudflare 的技術說明用比較白話的方式解釋：PHP 正常會先配置記憶體處理請求、結束後釋放；但如果處理過程意外中斷，PHP 沒有安全地清理記憶體，之後又去使用沒設定好或已釋放的資料。攻擊者可以送出特製的 HTTP 請求觸發這些狀況，進而讓 PHP 程序當掉、外洩敏感資訊，甚至執行攻擊者提供的程式碼。
受影響範圍更是驚人。PHP 官方的說法是：所有處理網頁請求的 PHP 安裝都受影響，包括 PHP-FPM、Apache 搭配 mod_php、php-cgi、FrankenPHP 與 LiteSpeed。官方認為 mod_php 風險最高，因為已經有可運作的攻擊示範，未登入的請求就能在任何應用程式碼執行之前觸發攻擊。Cloudflare 的文章則指出，漏洞影響 PHP 5.4 以後所有版本的網頁伺服器。
為什麼這次特別緊急？
三個原因疊在一起。
第一，它提前外洩了。 PHP 原本在 10 月 20 日預告會在 21 日 14:00 UTC（台灣時間 22:00）發布安全更新。Cloudflare 表示，漏洞在正式發布日前就已外洩，而且他們觀察到針對客戶的攻擊流量，還看到攻擊者不斷變化攻擊內容，試圖繞過防護規則。
第二，官方說沒有完整的替代方案。 PHP 公告原文的意思很清楚：更新是唯一完整的解法，那些暫時性設定只能降低特定攻擊路徑的風險，不會讓系統變安全。
第三，PHP 的覆蓋面太大。 Cloudflare 提到 PHP 被將近七成的網站使用，WordPress、Magento 這類平台都建立在它之上。換句話說，這不是「某個框架的問題」，而是「整個 PHP 生態系的問題」。
Laravel 使用者：看你是用哪種部署方式
Laravel News 的 Eric L. Barnes 特別提醒，這次範圍涵蓋了大部分 Laravel 正式環境的執行方式，並整理了 Laravel 官方對自家服務的說明：
- Laravel Cloud：官方會在修補發布後自動幫應用程式更新，不需要手動操作。
- Laravel Forge：需要自己到 Forge 主機面板手動更新 PHP 版本；如果無法更新，官方建議把伺服器關機。
- Laravel Vapor：跑在 PHP 8 的應用會自動重新部署；PHP 7 不會有修補，官方要求立刻把所有應用升級到 PHP 8。
Forge 那句「無法更新就關機」值得多看兩眼。官方願意說出這麼重的話，代表他們認為這次風險真的不能等。
今天就該做的更新清單
不論你用哪家主機，以下是整理自 PHP 官方公告與 Laravel News 的步驟：
- 確認 PHP 版本：在伺服器執行
php -v，同時注意 PHP-FPM 與 CLI 可能是不同版本，以 FPM 或網頁伺服器實際使用的為準。 - 更新到修補版本：8.5.12、8.4.27、8.3.36 或 8.2.35。Linux 發行版與長期支援廠商已經事先拿到修補，優先使用發行版套件。
- 重新啟動所有 PHP worker：更新套件後要重啟 PHP-FPM 或網頁伺服器，否則舊程序還在跑舊程式碼。
- 8.1 以下的舊版本：PHP 官方已不再更新。部分發行版與 LTS 廠商會提供回移修補，要直接詢問；PHP 安全團隊也為 7.4、8.0、8.1 提供了最小化的原始碼回移修補，給自行編譯的人使用。
- 注意套件來源：Laravel News 提到，志工維護的
rpms.remirepo.net當天不會有更新，PHP 團隊建議改用發行版套件或自行編譯。 - 共享主機或代管客戶：PHP 由主機商管理的話，請直接要求主機商套用安全更新。
順帶一提，PHP 官網也提醒：PHP 8.2 將在 2026 年 12 月 31 日終止支援。如果你這次是從 8.2 更新到 8.2.35，請順便把升級到更新大版本排進明年初的行程。
暫時無法更新？只能先「降低風險」
PHP 官方列出了一些能降低特定攻擊路徑的設定，但再強調一次：它們不會讓系統安全，只是爭取時間。摘要如下：
針對 CVE-2026-109618：
- 用應用程式無法覆寫的方式設定
memory_limit=-1（例如 FPM pool 的php_admin_value），並確認沒有其他地方又設回有限值。 - 調低
post_max_size：不需要上傳的應用建議8M，需要上傳的建議32M，並讓upload_max_filesize小於它。 - 在網頁伺服器或代理層限制請求大小、欄位數、multipart 數量、標頭數量與巢狀深度。
- 用容器或 cgroup 設記憶體上限，但不要改用
RLIMIT_AS或RLIMIT_DATA，它們反而可能觸發漏洞。
針對 CVE-2026-109619：
- 在
php.ini或 FPM pool 設定session.upload_progress.enabled=0，然後重啟所有 worker。ini_set()和.user.ini生效太晚，沒用。 - PHP 8.5 設定
fatal_error_backtraces=0並重啟。 - 修掉攻擊者可能觸發的致命錯誤與執行逾時。用
@或關掉display_errors把錯誤藏起來，沒有幫助。
WAF 是安全帶，不是煞車
如果網站在 Cloudflare 後面，有個好消息：Cloudflare 表示他們從 10 月初就開始開發防護規則，並在 **10 月 21 日 03:02 UTC（台灣時間 11:02）**起，為所有使用 WAF 的客戶預設啟用，包含免費方案。為了提高準確度，他們還推出了「完整交易偵測」功能，同時分析請求與來源伺服器的回應，必要時直接攔下回應。
但 Cloudflare 自己也說得很清楚：即使有 WAF，還是要盡快更新 PHP。WAF 是多一層防護，不是修補。就像安全帶能救命，但你還是得踩煞車。
情境演練：一家工作室的晚上（假設案例）
假設某間網頁工作室維護 30 個客戶網站：12 個 Laravel 跑在 Forge 管理的 VPS、15 個 WordPress 放在不同的共享主機、3 個是多年前交付、客戶自己管主機的舊專案。
比較穩的處理順序是：先把 Forge 上的主機逐台更新並重啟 PHP-FPM，用 php -v 和一個簡單的頁面確認版本；同時發信給共享主機商確認更新時程；最後通知那 3 位自管客戶，附上本文的檢查清單。那些還跑 PHP 7 的舊專案，就是最適合趁機談「升級與維護合約」的時候。
你可能會問
Q：我的網站是 WordPress，更新外掛就好嗎？ A：不夠。Cloudflare 特別強調，這是 PHP 執行環境的問題，只更新網站程式或外掛不能修補，必須更新伺服器上的 PHP。
Q：已經有人被攻擊成功了嗎？ A：截至撰文時，官方與 Cloudflare 都沒有公布確認遭入侵的案例；但 Cloudflare 表示已觀察到攻擊流量。不要等到確認才行動。
Q：我們用 PHP-FPM 不是 mod_php，是不是比較安全？ A：風險等級可能不同，但 PHP 官方明確把 PHP-FPM 列在受影響範圍內。答案還是：更新。
Q：Laravel 框架需要升級嗎？ A：這次問題在 PHP 本身，不是 Laravel 框架。要更新的是伺服器上的 PHP；框架照你的維護節奏另外處理即可。
結語：地基也要定期檢查
這次事件給所有 PHP 網站一個提醒：資安不只是「把程式寫好」，也包括「把跑程式的環境顧好」。框架、外掛、PHP 版本、作業系統，每一層都需要有人負責、有更新節奏。
今天花一小時更新 PHP、重啟服務，成本遠低於某天發現伺服器被植入後門、客戶資料外流。如果你不確定網站由誰負責這一層，現在就是釐清的最好時機。
來源：PHP Security Releases Fix Two Critical RCE Vulnerabilities（Eric L. Barnes，Laravel News，2026/10/21）。
延伸參考：Security advisory: Critical remote code execution vulnerabilities, update now（PHP 官方網站，2026/10/21）；Cloudflare deploys protections against php2shell vulnerability（Daniele Molteni、Dan Jones、Kuber Nandwani，Cloudflare Blog，2026/10/21）。