PHP2Shell 的修補程式已經推出，但對大多數需要修補的網站來說，卻沒有一個按鈕可以按。漏洞存在於 PHP 本身——這套引擎負責執行每個 WordPress、Joomla 和 Drupal 網頁，位於 CMS、外掛程式和登入畫面之下。更新 WordPress 對這些漏洞毫無作用。修補後的直譯器必須由管理伺服器的一方提供：可能是主機商、Linux 發行版的套件，或容器映像檔。在這件事發生之前，無論網站擁有者做什麼，網站都只能等待。

這正是那些高喊「立即修補」的標題略過的部分。PHP 團隊已完成自己的工作，但要把成果送到特定伺服器，得靠一條傳遞鏈，而整條鏈的速度取決於最慢的一環。首日的情況已顯示，各環節的進度相差有多大。不知道自己的 PHP 來自哪裡，網站擁有者就無從判斷自己仍暴露在多大風險之中。

為什麼更新 WordPress 無法修補漏洞

由於問題出在直譯器，PHP 的安全公告涵蓋所有提供網頁請求服務的安裝環境，包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 和 LiteSpeed。The Hacker News 指出，即使只是以易受攻擊版本執行一個簡單的「Hello World」頁面，也可能遭到攻擊。最嚴重的情況是 mod_php：沒有帳號的陌生人只需送出一個請求，就能在任何應用程式程式碼執行之前觸發攻擊，因此安全外掛程式和登入畫面都無從察覺。

WordPress 安全業者 Wordfence 向網站擁有者表示，正如 The Verge 報導，修補程式不會透過自動更新送達，他們必須查明誰負責維護自己的 PHP。Laravel Forge 也向自家客戶說明其伺服器的情況：自動安全更新不會修補 PHP，而 Ubuntu 的無人值守升級只會從 Ubuntu 自己的套件庫下載更新，不會更新 Forge 安裝 PHP 所使用的第三方套件。

這些套件來源並沒有同步更新。修補程式發布當天，網站管理服務 mySites.guru 回報，cPanel 的 EasyApache 4 在安全公告發布後幾分鐘內就推出修正版，但 Ondřej Surý（翁德熱伊·蘇里）的 PPA、Laravel Forge 自己仰賴的 Ubuntu 套件來源，以及 Remi 的套件庫，當時都還沒有修正版。InMotion Hosting 表示，其共用主機和 WordPress 伺服器仍在等待 CloudLinux 推出套件。在 mySites.guru 監測的線上網站中，截至 13:52 UTC，回報使用已修補 PHP 版本的比例僅有 0.08%。

版本號可能會誤導你

確認是否已修補，沒有單看版本號那麼簡單。Ubuntu、Debian 和 Red Hat 會回移安全修正，但不更改上游版本號，因此已修補的 Ubuntu 24.04 伺服器仍會顯示 8.3.6 套件。The Hacker News 引述 Debian 的說明，建議查看套件的變更紀錄中是否列出 CVE，而不要只相信版本字串。mySites.guru 也提醒另一個陷阱：在命令列執行 php -v 所顯示的 PHP 執行檔，往往不是實際用來提供網頁服務的那個，因此應確認網站本身回報的版本。

接著，修補程式還必須載入。PHP 的安全公告和 Forge 都特別提醒，必須重新啟動 Apache、PHP-FPM，以及所有長時間執行的工作程序。佇列工作程序和其他類似的背景程序，在重新啟動之前會繼續使用舊版直譯器，無論磁碟上的檔案是否已經修補。

哪些版本沒有官方修補程式

修正版包括 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，涵蓋 CVE-2026-109618 和 CVE-2026-109619；兩者在 CVSS v4.0 的評分均為 9.2。對於 PHP 8.1 和更舊版本，PHP 專案不會提供修補程式；只有 7.4、8.0 和 8.1 會獲得最低限度的原始碼回移修正，對象是自行編譯 PHP 的使用者。有些業者會填補這個缺口：InMotion 表示，cPanel 已將修正回移至其 7.4 至 8.1 套件，CloudLinux 也正為所有自家提供的版本修補；但 CentOS 7 完全沒有修補程式。

仍在使用舊版 PHP 的網站並不少。修補程式發布前一天，mySites.guru 監測的 Joomla 和 WordPress 線上網站中，有 22.7% 使用 PHP 8.1 或更舊版本，另有 16.6% 仍使用 PHP 7 或更早版本。該公司指出，部分原因在於 WordPress：官方建議使用 PHP 8.3，卻仍將早已停止維護的 7.4 列為相容版本。PHP 8.2 雖然獲得這次修補，但其安全支援將於 2026 年 12 月 31 日結束。

暫時設定能阻擋什麼

修補程式發布前流傳的替代做法——將 session.upload_progress.enabled=0 設為停用——確實有效，但只能解決部分問題。PHP 表示，這項設定可以阻擋已確認、透過 session 攻擊 CVE-2026-109619 的途徑，卻無法防範其他變體；而且必須在 php.ini、伺服器或程序池設定中修改，之後再重新啟動所有工作程序。在 PHP 8.5 上，設定 fatal_error_backtraces=0 還能封住另一條已確認的攻擊途徑。這兩項設定都無法處理 CVE-2026-109618；對此，PHP 建議設定不可覆寫的 memory_limit=-1、較低的 post_max_size，並在網頁伺服器或代理伺服器限制請求大小。PHP 的說法是，目前沒有完整的緩解措施。InMotion 指出，WordPress、Joomla、Drupal、Magento 和 PrestaShop 都不會使用上傳進度功能，因此停用它並不會影響這些系統。

Cloudflare 已為所有方案啟用防火牆規則，其技術長戴恩·克內希特（Dane Knecht）稱這只是權宜措施。mySites.guru 指出，只有在後端伺服器會拒絕繞過 Cloudflare、直接連到伺服器 IP 位址的流量時，這些規則才有用。

目前的攻擊情況

watchTowr 表示，其蜜罐在修補程式發布當天記錄到針對兩項漏洞的攻擊嘗試；Cloudflare 也觀察到攻擊者更改攻擊酬載，試圖繞過其規則。目前沒有任何消息來源證實有特定伺服器遭成功入侵。有些營運者選擇不冒風險：The Hacker News 報導，BambooHR 暫時關閉服務，荷蘭包括 DigiD 在內的公共服務也基於預防考量而下線。歐盟的 CERT 和英國國家網路安全中心則告知無法修補漏洞的機構，應將暴露在外的應用程式隔離，或直接下線。

這些漏洞由 Wiz Research 的 Calif（卡利夫）和 OpenAI 的 Codex Security 團隊發現。根據 PHP Foundation 的說法，記憶體漏洞的跡象在 2024 年的一次稽核中已經浮現，但修補工作停滯數月；基金會稱這是「結構性失敗」。研究人員表示，AI 模型協助他們在大約一週內，將這些已有十年歷史的漏洞轉化為可實際運作的攻擊程式。

PHP 經歷稽核、數月僵局和一次漏洞外洩，才推出這項修補程式。對使用共用主機的網站而言，最後一步就是提交支援工單。

標籤: Cloudflare, PHP, PHP2Shell, WordPress, 安全漏洞