我受影響嗎？

這次能造成什麼

兩類後果都在 PHP 本身，不在某一套網站程式。研究團隊的說法如下；成因用詞以 PHP 官方為準，見成因概念。

• 未驗證就能執行程式。 沒有帳號的人，有機會在受影響的伺服器上執行程式。個別變體的條件不同，這句說的是已示範的影響，不是每一種部署都同一條路。
• 讀取 PHP 行程記憶體。 裡面可能有其他請求或這台伺服器的密碼、驗證 token、API 金鑰、憑證。這件事不需要先達成遠端執行程式，所以「沒有被植入程式」不等於祕密還在。
• 不限 WordPress、Drupal、Joomla。 那三個是示範時用的代表。連最簡單的 Hello World，只要跑在受影響的 PHP 上，也算。常見軟體還包括 Moodle、Nextcloud、Laravel、Symfony、MediaWiki。
• 不需要應用程式帳號。 已示範的遠端執行與記憶體外洩都沒有先登入。
• WAF、CDN、主機商規則不能取代更新。 這些是更新前的暫時層，涵蓋範圍視廠商與路徑而定。直接打到源站的請求，可能根本不經過那層規則。
  註：WAF、CDN

  WAF

  Web Application Firewall。Cloudflare 自 2026-10-21 03:02 UTC 對免費與付費客戶預設上線規則，仍必須更新 PHP。已看到有人變造請求試圖避開規則。研究團隊寫，WAF、CDN 或主機商規則不能取代更新。

  CDN

  Content Delivery Network。研究團隊寫，CDN、WAF 或主機商的規則視廠商與路徑而定，不能取代更新 PHP。Vercel、Cloudflare、Akamai 都有自己的規則，直接打到源站的請求可能不在涵蓋範圍。

研究團隊另說受影響版本可追溯到 PHP 5.4，修補前幾乎每個版本都至少中一個。這是研究團隊說法，不是官方逐版清單。對照時用版本矩陣。

先問：它會不會被網頁請求碰到？

官方把風險對象寫成「服務網頁請求的安裝」：Apache mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeed。英國 NCSC 的用詞更寬，說任何版本都可能受影響。盤點時以「會不會被網頁請求碰到」為準，命令列的 PHP 也一起更新。

別漏掉表面上沒寫 PHP 的東西：主機控制台、廠商設備、Windows 軟體內建的 php.exe、php-cgi.exe。

php -v 不一定是網站在用的那一支

php -v 印的是你在 shell 裡叫到的那支執行檔。網站用的 PHP-FPM pool 或 Apache 模組可以是另一支，版號不同並不稀奇。

php -v

接著逐一對上真正處理請求的那一支：

• PHP-FPM：看 pool 設定指向哪一支 php-fpm 執行檔，再對那一支執行 -v。
• Apache mod_php：確認 Apache 是否載入 php_module，並看該模組對應的版號，而不是只看 PATH 上的 php。
• 主機控制台：cPanel、Plesk 顯示的版本，要和上面兩支對得起來；對不上時，以真正處理請求的那支為準。

apachectl -M

控制台通常各版本裝在不同目錄。Plesk 官方文章的檢查例子是直接呼叫該版本的執行檔：

/opt/plesk/php/8.3/bin/php -v

Plesk 在 Linux 上的 8.1.34、8.0.30、7.4.33 版號沒有變，只有 2026-10-21 建置的才含修補，所以要一併看 built: 那一行的建置日期。

先分辨 PHP 從哪裡來

同一個版號，修補方式依來源而不同。先看這一支 PHP 是誰裝的，再決定照哪一頁：

apt-cache policy php8.3-fpm

dnf list --installed 'php*'

apk policy php83

驗證：怎麼證明查到的是接流量的那一支

修補後照這四步做一次，每一步都對得上才算完成。以 Debian／Ubuntu 的 PHP-FPM 8.3 為例，其他平台把名稱換掉。

1. 找出正在處理請求的行程。

ps -eo pid,lstart,args | grep -E 'php-fpm|php-cgi|lsphp|frankenphp|apache2|httpd' | grep -v grep

會看到像 php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf) 這樣的行。記下 master 的 PID 與設定檔路徑，同一台有好幾個 master 時每一個都要做。用 mod_php 時看的是 Apache 的 master。

2. 對它實際執行的那個檔案查版本。

sudo readlink /proc/PID/exe
/usr/sbin/php-fpm8.3 -v

第一行印出執行檔路徑，第二行對那個路徑查版本。版本要達到版本矩陣的修補版；發行版套件則對照該發行版公告的套件版本（用第 1 步看 changelog 的方式確認）。

3. 確認它是在更新之後才啟動的。

sudo grep -c '(deleted)' /proc/PID/maps

印出 0，代表行程用的是更新後的檔案。大於 0 就是還沒重啟乾淨。第 1 步的 lstart 欄也應該晚於套件更新時間。

4. 從網頁那一側再確認一次。

在文件根目錄暫時放一個只有你知道檔名的檢查檔，用瀏覽器打開：

<?php echo PHP_VERSION, ' ', PHP_SAPI;

預期看到 8.3.36 fpm-fcgi 這類輸出：版本是修補版，SAPI 是你以為的那一種（mod_php 是 apache2handler）。發行版套件可能顯示發行版自己的版號，以第 2 步的套件版本為準。看完立刻刪掉，不要把 phpinfo() 長時間留在公開網址。

WordPress、Drupal 等網站：要修的是 PHP

這次不是 WordPress、Drupal 本身的漏洞。WordPress.org 寫明：No WordPress update is required or planned for these issues. 核心、外掛、佈景主題、Drupal 模組的更新都不是這次的修補；要更新的是底下的 PHP，照你的作業系統、控制台或 Docker 頁做。代管平台（Acquia、Pantheon、WordPress 代管）由平台更新，請對方回覆更新後的 PHP 版本，並確認已經重啟。

從網站後台看網頁請求那一側實際用的 PHP，比命令列可靠：

• WordPress：工具 → 網站健康狀態 → 資訊 → 伺服器（Tools > Site Health > Info > Server）。
• Drupal：報告 → 狀態報告，列有 PHP 版本。

wp cli info、drush 這類命令列工具回報的是命令列 PHP，可能和網站的 PHP-FPM 或 mod_php 不同；對不上時以後台為準。多個環境（正式、測試、預覽）每一個都要看。

composer.json 的 PHP 版本需求（含 config.platform）只影響相依套件怎麼解析，不會改變伺服器實際跑的 PHP。同一分支內套修補版不用動它；趁這次換到新分支時，先確認專案與相依套件支援新分支。

發行版的版號怎麼讀

發行版通常不升級大版本，而是把安全修補回移植到自己的套件。版號會是發行版自己的編號，比 php.net 的修補版號「小」也可能已經修好。官方查詢日 2026-10-22 讀到的例子：

規則：以該發行版的安全公告或追蹤頁為準，看已安裝的套件版本是否等於或新於公告上的修補版，不要只拿版號跟 php.net 比大小。

容器映像要分開看

主機上 apt upgrade 不會換掉映像裡的 PHP。要進到正在接流量的容器裡確認版本，不要只看建置機或舊的本機映像。詳見 Docker／Kubernetes。

對照官方版本矩陣

完整修補版號在版本矩陣。隱藏版本號的網站（沒送 X-Powered-By 標頭）不會出現在外部掃描的統計裡。你的主機就算沒露出版本，該修還是要修。

OpenAI 的 php2shell-checker

2026-10-21 00:29:12 UTC（台灣時間 08:29），OpenAI 的 GitHub 儲存庫 php2shell-checker 建立，授權 Apache-2.0。2026-10-21 16:35:11 UTC（台灣時間 2026-10-22 00:35），OpenAI 官方 X 帳號請不確定網站是否受影響的人，把 Codex 指向這個儲存庫。

它比對看得到的 PHP 版號和工具內建的門檻，結果是 OK、VULNERABLE 或 UNKNOWN。只有網址時，讀回應標頭裡的 Server 與 X-Powered-By。有這台主機的權限時，改看 php -v，並核對是不是正在處理網頁請求的那一支。不要跑會觸發漏洞的測試，只能檢查自己有權限的系統。

README 寫的限制：

• 只評估標頭或 php -v 露出的版本。看不到版本就是 UNKNOWN。UNKNOWN 不代表已經修補。
• OK 是「該分支的穩定版號高於內建門檻」，並假設其後的穩定版含有修補。它沒有另行驗證修補真的在那支執行檔裡。仍以 PHP 官方安全公告，以及本頁前面的「真正處理請求的那一支」為準。
• 發行版回移植可能不改上游版號。只拿版號跟門檻比，會把已經回移植的套件看成還沒修。
• 不跟隨重新導向，也不看回應本文。標頭可以隱藏或改寫。

這個工具不代替 PHP 官方修補。