PHP 兩個嚴重漏洞 CVE-2026-109618 及 CVE-2026-109619 的 CVSS v4.0 評分同為 9.2 分（滿分 10 分）。消息外洩後，PHP 團隊把安全更新提前 1 日，定於 10 月 21 日香港時間晚上 10 時（14:00 UTC）推出；若漏洞細節公開或發現實際攻擊，會再提早。多間保安機構指漏洞可導致遠端執行程式碼（RCE），按評分更可能無需認證便能發動，但官方尚未公布受影響版本。IT 團隊要先找出使用 PHP 的系統並排好修補次序，不能等版本表公布才開始準備。
今晚修補，受影響版本仍未公布
截至發稿時，漏洞技術細節及官方受影響版本表仍未公開。CERT-EU 估計漏洞可能影響 PHP 5 起的版本；Sansec 則根據外洩攻擊工具的截圖，指範圍可能由 PHP 5.4 起。兩者均非官方確認，實際範圍要待更新公布。
外洩的 php2shell 攻擊示範影片，曾展示攻擊使用 WordPress、Drupal 及 Magento 的測試環境，並在伺服器上執行指令。據 GIGAZINE 轉述，保安公司 watchTowr 已重現 CVE-2026-109618 的攻擊，但未發現實際攻擊個案；Huntress 亦表示，執筆時不知道有公開攻擊程式碼。換言之，CVE-2026-109618 已在測試中證實可利用，但未見有人用於實際攻擊。
盤點不只網頁伺服器，裝置亦藏 PHP
找出受影響資產不能只查公司網站。Huntress 建議由網頁伺服器開始，再檢查附帶 php.exe 或 php-cgi.exe 的供應商裝置及 Windows 軟件。cPanel、Plesk 等控制台，以及運行 WordPress、Drupal、Joomla 或 Magento 的系統，也要納入清單，避免遺漏沒有標明底層使用 PHP 的產品。
CERT-EU 建議先找出以 PHP 開發的應用程式，準備在修補版本推出後立即更新。盤點時可同時記下 PHP 版本、是否對外開放及負責人，方便晚上對照官方版本表，也能分清哪些系統由內部處理、哪些要交供應商更新。
先修對外系統，舊版 PHP 要另訂計劃
Huntress 建議預留更新推出時的修補時段，優先處理對外開放的系統。內部系統可之後按網絡接觸範圍及業務重要性分批處理。Sansec 指今次漏洞須在基建層面更新 PHP，修改網站程式碼不能解決問題。不自行管理伺服器的企業，應先通知寄存供應商待命，要求更新推出後盡快套用。
舊版 PHP 可能需要另一條處理路線。Sansec 按支援政策指出，官方只支援 PHP 8.2 或以後版本，因此預期 PHP 8.1 或更舊版本不會獲官方修補，惟實際修補範圍仍要待更新確認。使用舊版的企業應向供應商查詢能否移植修補（backport），或安排升級至仍獲支援的版本。
Sansec 預計更新推出後 15 分鐘內便會出現大規模攻擊。IT 團隊應預先安排好修補時段的人手及供應商支援，避免更新公布後才開始協調。
未能即時修補，先把對外應用隔離
CERT-EU 建議無法即時修補的機構，考慮把對外開放的應用程式與公共網絡隔離。這可能涉及暫停外部服務，營運主管與 IT 團隊要先決定哪些應用可接受短暫隔離，以及恢復服務前須完成哪些修補確認。
Sansec 亦提出在 php.ini 加入臨時設定 session.upload_progress.enabled = 0 及 session.use_strict_mode = 1，但明言不保證有效。該公司建議 PHP-FPM 用戶在各 pool 設定檔以 php_admin_flag 加入相應設定，重新載入後，透過實際由 PHP-FPM 處理的請求確認設定生效，不能只檢查命令列環境。Sansec 又指，session 存於 Redis 或資料庫的網站，其 session handler 不會執行 strict mode 所需的 ID 檢查，strict mode 設定因而不起作用。
Sansec 指目前所知的攻擊針對 PHP 本身，在網站程式碼及其 Shield 防護產品運行前便已發生。因此企業不應假設 WAF 或應用層規則足以取代 PHP 修補，也不應把上述臨時設定視為完成修復。
監察方面，Huntress 引述保安研究員 Florian Roth 的判斷，指漏洞利用多數會表現為 PHP 衍生可疑子程序。IT 團隊可留意 php-fpm、php-cgi、httpd 或 apache2 啟動 sh、bash、cmd.exe、powershell.exe、curl 或 wget 等行為，並結合正常工作負載判斷。Huntress 提醒，缺乏端點偵測的對外 Linux 網頁伺服器及共用寄存環境，被入侵後可能不被察覺。
IT 團隊今晚前要定好分工
IT Manager 與資訊保安主管可把 PHP 清單分成即時修補、交供應商處理、暫時隔離 3 類，每項列明負責人及完成確認方式。可自行更新的對外系統先排入修補時段；依賴供應商的系統要取得處理時間；沒有可確認修補路徑的系統，則先決定是否隔離，避免清單上只有「等待回覆」而沒有後備安排。
修補後應核對實際運行的 PHP 版本，並檢查相關程序紀錄。沒有端點偵測的對外伺服器，也應列入監察補強清單。恢復外部存取要以修補及驗證結果為依據，不能只憑臨時設定已套用。
