PHP 本身出現兩個嚴重漏洞：CVE-2026-109618 及 CVE-2026-109619（又稱「PHP2Shell」），未經認證的攻擊者有機會藉此在網站伺服器上執行代碼。漏洞詳情在預定公布前外洩，PHP 項目已於 2026 年 10 月 21 日推出修補版本：PHP 8.5.12、8.4.27、8.3.36 及 8.2.35。如果你的網站、網店或內部系統以 PHP 運行（包括 WordPress），請檢查所用版本並盡快更新，或向主機供應商查詢何時更新。
發生了甚麼事
這兩個漏洞原本處於保密期（embargo），即研究人員和廠商暫不公開細節，讓修補程式有時間準備。據 BleepingComputer 報道，2026 年 10 月 20 日 Hacker News 上一則其後已刪除的帖文聲稱，兩個 PHP 嚴重遠程執行代碼漏洞將於 10 月 22 日公布。保安公司 watchTowr 隨後在 X 表示資料已經外洩，並確認漏洞屬實。
同日，PHP 保安團隊發出預告，指保安更新會在 10 月 21 日 14:00 UTC（香港時間晚上 10 時）推出，兩個漏洞的 CVSS v4.0 評分均為 9.2。香港政府電腦保安事故協調中心（GovCERT.HK）亦於 10 月 21 日發出高危保安警報（A26-10-36）。當晚 PHP 發布了正式保安通告及修補版本。
兩個漏洞是甚麼
- CVE-2026-109618「RCE via OOM corruption」（GHSA-w8hw-w9fx-j79w）：PHP 處理請求時若記憶體不足，內部請求資料可能只完成部分初始化，其後的清理程序或會把這些無效資料當作有效資料處理。
- CVE-2026-109619「RCE via stale global state」（GHSA-6wmf-4rv5-p3rp）：屬於某個請求的內部狀態，在記憶體釋放後仍可能殘留；同一 worker 處理下一個請求時，可能在正常初始化前使用到這些舊狀態。
根據 PHP 發布的 CVE 記錄，兩者均屬「嚴重」級別，CVSS v4.0 評分 9.2：可經網絡攻擊、毋須登入、毋須用戶操作，但攻擊複雜度較高。公布前有報道指評分為 10.0，官方評分則為 9.2。
哪些系統受影響
PHP 通告指出，所有處理網絡請求的 PHP 安裝都有風險，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 及 LiteSpeed。PHP 團隊認為 mod_php 風險最高，已有示範攻擊顯示，未經認證的請求可在任何應用程式代碼執行前觸發攻擊。
- PHP 8.2 至 8.5：8.2.35、8.3.36、8.4.27 及 8.5.12 之前的版本受影響，應更新至上述版本。
- PHP 8.1 或更舊：PHP 項目已不再提供更新。部分 Linux 發行版及長期支援供應商會提供移植修補（backport）；PHP 亦為 7.4、8.0 及 8.1 提供了精簡的源碼修補，供自行編譯的用戶使用。否則應升級至仍受支援的版本。
- PHP 8.2 將於 2026 年 12 月 31 日停止支援，下一次升級亦應及早安排。
是否已被利用？
Cloudflare 表示，漏洞外洩後已觀察到針對其客戶的攻擊流量；其免費及付費 WAF 方案自 10 月 21 日 03:02 UTC 起已預設啟用相關防護規則。Cloudflare 仍然要求客戶盡快修補。情況可能變化很快，任何對外開放的 PHP 系統都應視為急需處理。
現在應該做甚麼
- 列出所有 PHP 系統：包括公司網站、WordPress 或其他 CMS 網站、網店、預約或會員系統、管理後台，以及任何可從互聯網存取的內部工具。先處理對外開放的系統。
- 檢查 PHP 版本：主機控制台通常會顯示版本，亦可請開發人員在伺服器上查看，並記下 PHP 的運行方式（mod_php、PHP-FPM、LiteSpeed 等）。
- 更新：安裝 8.5.12、8.4.27、8.3.36 或 8.2.35，或所用 Linux 發行版的修補套件。例如 Ubuntu 已為受支援版本推出修補套件。更新後要重新啟動 PHP worker，確保新版本真正生效。
- 聯絡主機供應商：如使用共享或託管主機，PHP 一般由供應商管理，應查詢對方是否已修補、何時修補。
- 使用 Remi 軟件庫的用戶：PHP 指出，由義工維護的 rpms.remirepo.net 在發布當日不會有更新，建議改用發行版套件或自行編譯。
- WAF 只是權宜之計：具備託管規則的網站應用程式防火牆或 CDN 或可攔截已知攻擊模式，但 PHP 表明只有更新才能徹底解決。
- 先測試，再監察：如條件許可，先在測試環境（Staging）試行更新，再監察正式網站。外部網站監測有助及早發現停機或異常改動。
如果今天未能更新
PHP 通告列出一些臨時措施，可減低特定攻擊途徑的風險，但不能令系統變得安全。這些措施需要伺服器層面的權限，應由負責管理伺服器的人員執行：
- 針對 CVE-2026-109618：在應用程式無法覆蓋的層面設定 memory_limit=-1；把 post_max_size 設低（PHP 建議不需上載檔案時設為 8M，需要時設為 32M）；並在網站伺服器或代理層面限制請求大小及複雜程度。
- 針對 CVE-2026-109619：設定 session.upload_progress.enabled=0 並重新啟動所有 worker；PHP 8.5 亦應設定 fatal_error_backtraces=0。
詳情及應避免的設定，請參閱 PHP 完整通告。英國 NCSC 亦建議，系統未能即時修補時，機構可考慮暫時將其下線。
對中小企的意義
不少小企業並不清楚自己的網站用哪個 PHP 版本，亦不清楚誰負責更新。趁今次機會弄清楚並記錄下來：網站由誰託管、誰能更新伺服器、反應有多快。清晰的支援 SLA 可以在下一次緊急修補前把責任說清楚。technine.io 可透過網絡安全及合規服務協助檢查風險和規劃修補，並以託管支援服務保持系統更新。
常見問題
我的 WordPress 網站會受影響嗎？
WordPress 以 PHP 運行，所以關鍵在於伺服器上的 PHP 版本，而不是 WordPress 版本。如果 PHP 舊於修補版本，在更新 PHP 前網站仍有風險。
WAF 或 CDN 可以保護我嗎？
它們或可攔截已知攻擊模式，爭取時間，但不是完整的解決方法，仍然需要更新 PHP。
我們仍在用 PHP 7，應該怎樣做？
PHP 7 已不再有官方更新。請查詢所用 Linux 發行版或支援供應商是否提供移植修補，並計劃升級至受支援的 PHP 8 版本。
怎樣確認更新成功？
在伺服器或主機控制台確認新版本號，確保 PHP worker 已重新啟動，並檢查主要頁面和表格是否仍然正常運作。