PHP 修補兩個嚴重漏洞：未認證即可遙距執行代碼，官方籲即時更新

PHP 專輯在官方網站發出緊急公告，指 PHP 8.5.12、8.4.27、8.3.36 與 8.2.35 修補了兩個可讓未經認證的攻擊者遠距執行代碼的嚴重漏洞，強烈呼籲所有 PHP 使用者立即更新。[1]

風險範圍

官方指出，所有處理網頁請求的 PHP 安裝均受影響，包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 與 LiteSpeed；官方認爲 mod_php 的風險最高，並已示範一個未經認證的請求可以在任意惡意程式碼執行之前發動攻擊。[1]

兩個漏洞

官方列出兩個漏洞的技術成因：[1]

• CVE-2026-109618（經 OOM 損耗導致的 RCE）：記憶體不足（out-of-memory）處理可可能在 PHP 的內部請求資源只完成部分初始化時打斷它，隨後的請求清理可可能把無效資源當作有效處理
• CVE-2026-109619（經殘留全域狀態導致的 RCE）：請求擁有的內部狀態可以在其底層記憶體已釋放後繼續存在；同一工作進程處理的後續請求，可可能在正常初始化重置之前使用這些殘留狀態

兩個漏洞分別有官方安全公告（GHSA-w8hw-w9fx-j79w 與 GHSA-6wmf-4rv5-p3rp）載有完整技術細節。[1][2][3]

實際影響能攻破 WordPress 等任何網站

這兩個漏洞最大特點是「未認證即可遠端執行程式碼」，而且攻擊發生在 PHP 解析請求的階段，任何應用程式程式碼（包括 WordPress、Drupal、Joomla、Magento）都尚未執行。研究人員已在最新版 WordPress、Drupal、Joomla 容器中成功演示完整 RCE。即使網站程式本身完全沒有漏洞，只要底層 PHP 版本未修補，一樣可能被攻破。

另外，CVE-2026-109619 亦可導致記憶體洩漏，攻擊者有機會從 PHP worker 行程中讀取其他請求的密碼、API Key、Session 等敏感資料。因此，即使暫時未能立即更新，亦應考慮輪換重要憑證。

重點提醒：只更新 WordPress、主題或外掛無法修復此漏洞，必須更新 PHP 本身。

如何檢查自己是否受影響

最直接的方法是確認網站實際使用的 PHP 版本：

1. 建立一個臨時的 phpinfo.php，內容為 <?php phpinfo(); ?>，用瀏覽器開啟後查看「PHP Version」。確認後立即刪除該檔案。
2. 觀察 HTTP 回應標頭中的 X-Powered-By（若有顯示）。
3. 使用線上被動掃描工具（例如 php2shell.xyz 或 Brandefense 提供的免費檢查），無需主動發送攻擊流量即可得知版本範圍。

若版本低於 8.2.35、8.3.36、8.4.27 或 8.5.12，即屬受影響範圍。PHP 8.1 及更舊版本官方已不再提供二進位更新，需盡快升級至受支援分支，或向發行版／LTS 供應商查詢是否有回移修補。

香港本地情況

香港不少中小企業、個人網站及共享主機仍使用 PHP 7.x、8.0 或 8.1。這些版本已結束官方支援，面對 PHP2Shell 時風險特別高。本地共享主機供應商若尚未自動更新，管理員應主動查詢並要求升級。

建議本地網站管理員：

• 立即檢查所有對外公開的 PHP 網站版本
• 優先處理使用 Apache mod_php 的主機（官方認為風險最高）
• 若網站曾對外開放且未即時更新，應考慮輪換資料庫密碼、API Key 及管理帳戶密碼
• 關注 HKCERT 及主要主機商的最新公告

如何更新

官方建議：[1]

• 更新至 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35；原始碼與 Windows 版本可於官方下載頁取得
• Linux 發行版與 LTS 供應商已預先取得修補，請向供應商查詢更新套件
• PHP 8.1 及更舊版本已不再由 PHP 專輯提供更新；部分發行版與 LTS 供應商提供回移修補，請聯繫供應商或升級至受支援版本
• 由於漏洞嚴重，PHP 保安圖靈甚至為 PHP 7.4、8.0 與 8.1 提供最低程度的原始碼回移，供自行建構或無法使用 LTS 供應商的人員使用

各主要 Linux 發行版更新方法

Ubuntu / Debian

# 更新套件清單
sudo apt update

# 查看目前 PHP 版本
php -v

# 安裝最新安全更新（依實際使用的 PHP 版本調整）
sudo apt install --only-upgrade php8.2 php8.2-fpm php8.2-cli   # 或 php8.3 / php8.4 等

# 重啟相關服務
sudo systemctl restart php8.2-fpm   # 或 apache2
sudo systemctl restart apache2      # 若使用 mod_php

參考 Ubuntu 安全通告：USN-8948-1: PHP vulnerabilities (2026年10月21日)

Red Hat Enterprise Linux / AlmaLinux / Rocky Linux

sudo dnf update php php-fpm php-cli

# 或指定模組版本（視系統設定）
sudo dnf module reset php
sudo dnf module enable php:8.2   # 或其他支援版本
sudo dnf update php

sudo systemctl restart php-fpm
sudo systemctl restart httpd

Oracle Linux

Oracle Linux 與 RHEL 高度相容，更新方式大致相同：

sudo dnf update php php-fpm

# 或使用 Oracle 官方 PHP 套件來源（如有啟用）
sudo dnf update --enablerepo=ol8_appstream php*

sudo systemctl restart php-fpm
sudo systemctl restart httpd

更新後務必確認

php -v
# 確認版本已達到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 或以上

未能即時更新的緩解措施

官方強調，只有更新才是完整解決方案，以下措施只可減少特定攻擊路徑的暴露，並不能令安裝變得安全。[1]

針對 OOM 損耗路徑：[1]

• 設定 memory_limit=-1，最好以無法覆蓋的方式設定（例如 FPM pool 或 Apache 設定中的 php_admin_value），並確認沒有 pool、目錄或應用程式設定重新加上有限上上限；這可移除可控的 PHP 記憶體上限失效，但底層配置失效仍可能誘發漏洞路徑
• 設定較低的 post_max_size：不需要核心上傳的應用設為 8M，需要上傳的設為 32M，並令 upload_max_filesize 低於 post_max_size
• 考慮在網頁伺服器或代理層強制限制請求大小、輸入位元數量、multipart 部分數量、標頭數量與嵌套深度；這些限制也須覆蓋沒有可用 Content-Length 的請求
• 以容器或 cgroup 限制作為可用性邊界，最好設定為只終止受影響的工作進程；不要以 RLIMIT_AS 或 RLIMIT_DATA 代替，因為它們可誘發漏洞的配置失效

針對殘留全域狀態路徑：[1]

• 設定 session.upload_progress.enabled=0 並重啟所有工作進程；須透過 php.ini、FPM pool 或伺服器設定在請求解析前生效，不可依賴 ini_set() 或 FPM 的 .user.ini。這可阻擋已確認的 session 路徑，但不能阻擋其他變體
• 在 PHP 8.5 上設定 fatal_error_backtraces=0 並重啟所有工作進程，這只阻擋已確認的 fatal backtrace 路徑
• 移除按請求用途、會在初始化前發出診斷的無效或廢棄設定；以 error_reporting、display_errors 或 @ 隱藏診斷並無助
• 修正可由攻擊者誘發的 fatal error 與執行逾時，包括回調、上傳或廢棄邏輯及清理階段的失效

官方亦指出，PHP 8.6.0 的第四個候選版本（RC4）已包含這兩個漏洞的修正，呼籲使用較早 8.6.0 建構版本的人立即更新。[1]

其他報道

媒體報道指，PHP 方面指給供應商 Chainguard 提早洩露漏洞細節；有關法律媒體報道，本文不作來源引證。[1]

參考資料

[1] PHP 官方網站 — 安全公告與下載（2026 年 10 月 21 日）

[2] PHP 官方安全公告 — CVE-2026-109618（GHSA-w8hw-w9fx-j79w）

[3] PHP 官方安全公告 — CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）