PHP Security Team 已預告將於 2026 年 10 月 21 日 14:00 UTC（台灣時間 22:00）發布緊急安全更新，修補兩項 CVSS v4.0 9.2 的重大漏洞。Sansec 進一步以 PHP2Shell 稱呼這起事件，並引述外部研究指出漏洞可能造成遠端程式碼執行，追蹤編號為 CVE-2026-109618 與 CVE-2026-109619。截至本文發布時，PHP 官方尚未公開技術細節、完整受影響版本及修補版號；因此組織此刻最重要的工作不是等待攻擊樣本，而是先完成 PHP 執行環境盤點、安排緊急變更窗口，並準備在官方套件或可信供應商回補發布後立即更新、重啟與驗證。
先講結論：現在完成盤點，補丁發布後立即更新
這不是只更新 WordPress、Magento、Shopware、WooCommerce 或其他 CMS 外掛就能結案的事件。現階段公開情報將問題指向 PHP 核心執行環境；即使網站程式本身沒有變更，只要對外服務仍由受影響的 PHP Runtime 處理請求，就必須納入評估。正式修復應以更新 PHP Runtime 或採用作業系統、託管服務商明確標示已回補的套件為主。
PHP 官方公告保留提前發布的可能性，因此不要把 22:00 視為唯一開始時間。應立即通知維運、開發、資安、客服與業務負責人，凍結非必要變更，列出所有對外 PHP 服務與維護窗口，確認誰負責取得更新、誰執行部署、誰驗證服務，以及發現入侵跡象時由誰啟動事件應變。
若服務由主機商、PaaS、代管商或 SaaS 供應商維護，現在就應取得書面回覆：使用的 PHP 分支、修補來源、預計部署時間、是否需要重新部署應用，以及客戶如何確認底層 Runtime 已更新。控制台顯示的版本標籤不一定等於實際執行中的 Binary，必須要求可驗證證據。
| 工作 | 負責角色 | 完成條件 |
|---|---|---|
| 資產盤點 | 維運／平台團隊 | 列出網域、主機、容器、PHP 分支、套件來源與 Owner |
| 變更準備 | 維運／開發團隊 | 完成備份、回復方案、健康檢查與滾動更新步驟 |
| 情報確認 | 資安團隊 | 持續追蹤 PHP 官方公告、CVE 紀錄與供應商 Advisory |
| 更新驗證 | 維運／QA | 確認執行中 Worker 已換版，外部功能與監控正常 |
| 事件應變 | SOC／IR | 保存日誌、建立偵測條件並準備隔離與密鑰輪替流程 |
哪些資訊已確認？哪些仍屬提前揭露？
PHP 官方在 10 月 20 日的預告中確認：即將發布的安全更新處理兩項重大漏洞，兩者 CVSS v4.0 均為 9.2，預定於 10 月 21 日 14:00 UTC 發布；若技術細節提前公開或出現主動利用跡象，官方可能提前釋出。官方同時明確表示，完整細節、受影響版本與修補版本會在正式發布時公布。
Sansec 的研究文章將事件稱為 PHP2Shell，表示外洩的自動化利用工具畫面宣稱支援 PHP 5.4.0 之後的版本，並引述 watchTowr 將兩項問題描述為 PHP 核心遠端程式碼執行，編號為 CVE-2026-109618 與 CVE-2026-109619。Sansec 預測技術細節公開後很快會出現大量掃描；這是高風險情境判斷，不是已觀察到的固定時間表。
截至 2026 年 10 月 21 日 12:00（台灣時間），公開 CVE API 尚查無這兩筆正式紀錄，PHP 官方預告也尚未列出這兩個編號。因此本文保留編號供團隊追蹤，但不把第三方提前資訊包裝成 PHP 官方已完整確認的影響範圍。今晚發布後，應重新核對官方公告與各作業系統供應商的修補說明。
| 項目 | 目前狀態 | 採取方式 |
|---|---|---|
| 兩項重大漏洞、CVSS 9.2 | PHP 官方已確認 | 依最高優先級安排變更 |
| 10 月 21 日 14:00 UTC 發布 | PHP 官方預定時間 | 持續監看，準備提前發布 |
| 遠端程式碼執行 | Sansec／外部研究資訊 | 以最嚴重情境準備，但待官方技術細節確認 |
| PHP 5.4 以上全部受影響 | 外洩工具宣稱／尚待官方確認 | 全部納入盤點，不據此判定最終受影響範圍 |
| 15 分鐘內大規模攻擊 | Sansec 風險預測 | 縮短更新窗口，不當成已發生事實 |
| 修補版號與觸發條件 | 尚未公開 | 以 PHP 與套件供應商公告為準 |
受影響資產怎麼盤點：不要只在一台主機執行 php -v
企業環境常同時存在系統套件、第三方 Repository、手動編譯、容器映像、Kubernetes 工作負載、Serverless Runtime、CI Runner、排程 Worker 與主機商代管環境。登入 Shell 所看到的 CLI PHP，可能和 Nginx 連接的 PHP-FPM、Apache mod_php、Queue Worker 或 Cron Job 使用不同 Binary；只記錄一個 php -v 輸出會產生錯誤安全感。
盤點時要將『資產—入口—實際 Runtime—套件來源—部署方式—責任人』連成一條可操作紀錄。對每個網站確認公開網域、Origin、負載平衡後端、PHP-FPM Pool 或 Apache Module、容器 Digest、PHP 分支、作業系統、Repository、目前 Package Build、是否自動擴縮，以及是否存在已停止但仍可從網路到達的舊節點。
PHP 官方目前支援 8.2、8.3、8.4 與 8.5 分支。使用 8.1 或更舊版本的環境，不應假設 PHP 專案會提供官方修補；必須升級至受支援分支，或取得作業系統／商業供應商對舊分支的明確 Backport 證明。版本字串未改變不一定代表未修補，因為 Linux 發行版可能回補程式碼但保留上游版本號；判斷時要查看套件 Changelog 與 Advisory。
- Web：Nginx + PHP-FPM、Apache mod_php／FPM、IIS FastCGI 與反向代理後端
- 非 Web：Queue Worker、排程工作、Webhook Consumer、CLI 批次與管理工具
- 封裝：VM 套件、Docker／OCI Image、Kubernetes Pod、PaaS Buildpack 與 Serverless Runtime
- 供應鏈：Base Image、內部映像倉庫、套件鏡像、AMI／Template 與 Auto Scaling 節點
- 舊資產：備援站、測試站、暫停中的容器、舊版 Origin 與未下線管理介面
補丁發布後：依供應來源更新，不要自行猜測安全版號
補丁發布後，先閱讀 PHP 官方 Release Note 與 ChangeLog，再確認所使用的作業系統、容器 Base Image 或託管平台是否已提供對應安全更新。Debian／Ubuntu、RHEL 系列及商業 PHP Repository 可能使用自己的 Package Release 與 Backport 編號；應以供應商 Advisory 明確標示已修補該漏洞為驗收依據，而不是只比較上游版本字串大小。
裸機或 VM 應透過既有套件管理與設定管理流程更新 PHP 核心及實際載入的 Extension。PHP-FPM 必須重啟所有 Pool；使用 mod_php 時需重啟或滾動替換 Apache Worker。Nginx 本身通常不是漏洞元件，但若部署流程將 Nginx 與 PHP 包在同一映像，或設定變更需要整體重新部署，就應依服務架構執行。
容器環境不要只在運行中的容器內更新套件。應以已修補的 Base Image 重新建置不可變映像、完成掃描與簽章、更新 Deployment，等待新 Pod 通過 Readiness Probe 後再移除舊 Pod，並確認節點快取或私有 Registry 沒有讓舊 Digest 回流。
| 環境 | 正確更新方式 | 主要驗證 |
|---|---|---|
| Debian／Ubuntu | 由可信 Repository 安裝安全更新 | 套件 Changelog、FPM 重啟時間與實際 Worker Build |
| RHEL／Rocky／Alma | 依 Vendor Advisory 更新套件或 Module Stream | 套件 Release、Errata 與服務程序 |
| 自行編譯 | 使用官方修補來源重新建置並替換 Binary | Build Provenance、Extension ABI、Worker Process |
| Docker／Kubernetes | 更新 Base Image 後重新建置、簽章與滾動部署 | Image Digest、Pod 建立時間、舊 Replica 歸零 |
| PaaS／代管主機 | 由供應商更新 Runtime，必要時重新部署 App | 供應商公告、Runtime Build 與外部健康檢查 |
更新完成不等於修補完成：必須驗證正在服務流量的程序
套件管理器顯示成功，只證明檔案已安裝，不代表舊 PHP-FPM Worker 已退出。驗證要從負載平衡器後端、容器 Pod 與實際處理流量的程序逐一確認：新程序的啟動時間晚於更新時間、所有 Worker 使用已修補套件、舊 Replica 已清除、健康檢查正常，而且公開流量不會被送往遺漏節點。
功能驗證至少涵蓋首頁與關鍵 API、登入與 Session、檔案上傳、背景工作、支付或下單流程、錯誤率、延遲與 PHP-FPM Queue。若 Extension 或 Framework 與新 PHP 分支不相容，應依預先準備的回復與風險決策處理；不能因應用相容性問題，未經評估就長時間回退到存在重大漏洞的 Runtime。
在供應商採 Backport 的情況下，不要用公開網站輸出完整 phpinfo() 來證明版本，避免暴露模組、路徑與環境資訊。可由受控管理通道保存套件查詢、Advisory、程序啟動時間、映像 Digest 與部署紀錄，作為修補證據。
- 確認 Package／Image 明確包含供應商針對兩項漏洞的修補
- 確認 PHP-FPM、Apache Worker、Queue Worker 與 Cron 使用新 Binary
- 確認所有節點、所有 Availability Zone 與自動擴縮範本同步更新
- 由外部監控重跑關鍵交易與錯誤率、延遲、資源用量檢查
- 保存部署時間、版本證據、負責人與驗證結果，便於事件追蹤與稽核
無法立即更新時的暫時緩解：降低曝露，但不能取代修補
在正式技術細節公開前，任何特定 WAF 規則都可能不完整。WAF、Rate Limit、Bot 管理、Geo／IP 限制與嚴格的 Origin Access Control 可以提高攻擊成本、縮小管理介面曝露或減緩掃描，但不能被宣稱為已阻擋 PHP 核心 RCE。php.ini 的 disable_functions 同樣不是可靠修補；若攻擊者已取得 PHP 程序內的程式碼執行能力，實際影響仍取決於漏洞路徑、程序權限、容器隔離與系統控制。
短期內可將非必要站點切入維護模式或限制來源、移除直接對外的 Origin、關閉不使用的 PHP 入口與測試站、提高 WAF 記錄層級、限制 PHP 工作負載出站網路，並確認服務帳號沒有不必要的檔案、資料庫、雲端 Metadata 與控制平面權限。這些措施的目的，是縮短可攻擊面與入侵後活動範圍。
若業務無法在風險窗口內更新，必須由具權責者記錄例外：受影響資產、延後原因、暫時控制、監控方式、到期時間與修補 Owner。『有 WAF』或『網站前面有 CDN』不能作為無期限延後的理由。
| 措施 | 可降低的風險 | 不能解決的問題 |
|---|---|---|
| 限制來源／維護模式 | 減少可到達的公開入口 | 允許來源仍可能觸發漏洞 |
| WAF／Rate Limit | 阻擋已知樣式、降低大量掃描 | 未知或繞過型 Payload |
| 封鎖 Origin 旁路 | 避免繞過 CDN／WAF | 不修補 PHP Runtime |
| 限制出站網路 | 降低下載工具與外連 C2 能力 | 不阻止本機程式碼執行 |
| 最小權限／唯讀檔案系統 | 縮小成功利用後的影響 | 不能保證攻擊失敗 |
別只補洞：同步檢查公開前後是否已出現入侵跡象
PHP 官方尚未表示已觀察到主動利用，但公告保留提前發布條款，外部研究也顯示利用資訊已有外洩風險。組織應從公告前的合理時間點開始保全 Reverse Proxy、WAF、PHP-FPM、Web Server、EDR、容器 Audit、DNS 與 Cloud Control Plane 日誌，避免更新與重啟後失去關鍵證據。
偵測不應只搜尋 CVE 編號或單一 User-Agent。應關注 PHP Worker 異常建立 Shell、下載工具或系統管理程序，Web Root／Upload／Temporary Directory 出現新增或修改的可執行檔，未知排程與服務、異常外連、權限或帳號變更，以及 PHP-FPM Crash、非預期 Child Process 與高頻錯誤。特定請求特徵應等官方技術細節發布後再補充，避免以臆測規則造成大量誤報。
若發現可疑跡象，先隔離受影響節點並保全 Memory、Disk、Container Layer 與日誌，再從乾淨來源重建，不要只刪除 Webshell 後恢復服務。評估攻擊者可能讀取的資料庫密碼、API Key、Cloud Credential、Session Secret、Signing Key 與客戶資料，依證據範圍撤銷或輪替，並確認橫向移動與持久化已排除。
- PHP／Web Worker 啟動 sh、bash、curl、wget、PowerShell 或不明 Binary
- Web Root、Upload、/tmp 或容器可寫目錄出現異常檔案與時間戳
- 新的 Cron、Systemd Service、帳號、SSH Key、Container 或雲端存取金鑰
- 對未知網域／IP 的 DNS、HTTP、TLS 連線或資料外傳流量
- 補丁發布前後突增的 4xx／5xx、PHP Crash、FPM Queue 與異常請求量
給管理者的四階段決策表
這次事件最容易失敗的地方，不是團隊不會執行套件更新，而是版本盤點不完整、補丁責任落在供應商卻沒有確認、更新後舊 Worker 繼續處理流量，或只看到版本字串便誤判 Backport 狀態。決策應以每一項資產的可驗證狀態推進。
若今晚官方公告的影響範圍與目前提前情報不同，應以官方資料修正優先順序，但不應撤回已完成的資產盤點與變更準備。這些資料同樣能用於下一次 Runtime、OpenSSL、Web Server 或 Framework 緊急修補。
| 階段 | 必要輸出 | 不可放行條件 |
|---|---|---|
| 準備 | 完整資產表、Owner、變更與回復方案 | 仍有未知 PHP 服務或無人負責資產 |
| 更新 | 可信修補套件／映像與部署紀錄 | 來源不明、未證明包含修補、只改 CLI |
| 驗證 | 新 Worker、外部健康檢查與舊節點清除證據 | 仍有舊程序、舊 Pod 或舊擴縮範本 |
| 監控 | 日誌保全、偵測規則與事件 Owner | 無法追溯公告前後活動或無隔離流程 |
常見問題
問：更新 WordPress、Magento、Shopware 或 WooCommerce 就可以嗎？答：不可以把應用更新當成 PHP 核心修補。仍應依 PHP 官方與供應商公告更新實際 Runtime；應用及外掛則維持各自的安全更新。
問：CDN 或 WAF 能完全擋住嗎？答：在技術細節尚未公開前，無法合理保證。它們可作為暫時風險降低與偵測層，但不能取代 PHP Runtime 更新。
問：我們的 PHP 版本字串沒有變，是否代表供應商沒修？答：不一定。部分 Linux 發行版會 Backport 修補並保留上游版本字串，應核對 Package Release、Changelog 與 Vendor Advisory。反過來，版本字串看似較新也不能取代供應來源與部署證據。
問：PHP 8.1 或更舊版本怎麼辦？答：優先遷移到 PHP 官方支援的 8.2 以上分支；若短期無法完成，必須取得作業系統或商業供應商對該版本的明確安全回補與支援承諾，並設置有期限的遷移計畫。
問：掃描沒有發現問題，是否可以不更新？答：不可以。補丁發布前掃描器通常沒有穩定且安全的檢測方法；即使沒有發現利用跡象，也不代表 Runtime 不受影響。修補判斷應以官方版本與供應商 Advisory 為準。
