在 2026 年 10 月下旬的這幾天，全球的開發及資安人員都因為PHP2Shell忙翻了 – 在PHP上的兩項高危險遠端程式碼執行（RCE）漏洞——CVE-2026-109618 與 CVE-2026-109619，嚴重性資安界被形容為「不亞於當年 Log4Shell / Log4J 的災難」，因為PHP作為網站及Web App的底層核心語言，此次CVSS分數高達9.2的極高危漏洞估計最少影響全球70%的網站！
最令人措手不及的是，這兩個原本被安排好在10月22日與安全更新同步發佈的CVE，竟然提早了兩天在10月20日在Hacker News論壇被爆料放出，令PHP官方團隊亦提早一天將Patch釋出，Dark Web上的幾個地下網站也暫時宣佈關閉或限制存取，這兩個漏洞的嚴重性可見一斑。
PHP2Shell 是甚麼？為何危險？
PHP2Shell 是研究人員對CVE-2026-109618和CVE-2026-109619 兩個PHP的遠端執行漏洞的統稱，攻擊者只要向受影響的 PHP 服務器發出特定請求，便可能在無需身份驗證的情況下，觸發 PHP 內部錯誤並執行惡意程式碼，繼而成功取得伺服器控制權。
- CVE-2026-109618（記憶體損壞 / Out-of-memory corruption）：當 PHP 在請求處理過程中遭遇記憶體不足（Fatal OOM）時，內部請求資料可能只設定了一半就被強制中斷。隨後的清理機制若將這些殘缺、破損的資料誤認為合法有效，便會造成記憶體損壞，進而遭到攻擊者利用執行惡意代碼。
- CVE-2026-109619（狀態殘留 / Stale global state）：與前者類似，與請求緊密綁定的內部全域狀態在記憶體被釋放後，可能意外「長壽」過期而不自知。當下一個請求分配到同一個工作進程（Worker）時，便會重複讀取並使用這些未被重置的殘留狀態。
根據 PHP 官方與資安機構的分析，在某些高風險部署環境（例如搭配 mod_php 的 Apache 伺服器，或是 PHP-FPM、LiteSpeed 環境）中，攻擊者甚至可以在任何應用程式業務代碼執行之前，透過精心構造的請求在直譯器（Interpreter）層級直接觸發漏洞並取得 Shell。這意味著，即便你的應用程式寫得再安全、框架再最新，只要底層的 PHP 直譯器有破口，防線就會瞬間崩潰。
PHP2Shell 的最大危險之一，是攻擊者不一定需要有效帳戶、管理員權限或應用程式登入狀態。若受影響 PHP 服務直接暴露於互聯網，攻擊者可能透過網絡請求直接觸發漏洞。只要伺服器正在處理網絡請求，便可能成為攻擊入口。同時由於PHP 不只是用於單一網站，而是被大量企業網站及服務包括 WordPress、Drupal、Magento、Laravel 及無數內部自建系統等應用，因為其影響非常廣泛，甚至會產生深遠的連鎖效應。
即時的修補措施
- Patch！升級至官方修補版本：
- PHP官方已釋出CVE-2026-109618及CVE-2026-109619的安全更新，將受影響的PHP版本級至安全版本(8.5.12, 8.4.27, 8.3.36, 及 8.2.35) 是最徹底的解決方案
- 更新完成後，務必重啟 PHP FastCGI Process Manager (PHP-FPM) 或網頁伺服器，確保新版本生效。
- 如果不清楚網站的PHP版本，可使用如PHP2Shell Checker等免費網上工具
- 進行資產盤點
- 找出所有運行 PHP 的環境，包括對外網站、內部管理系統、Docker 容器、第三方商用軟件及控制面板（如 cPanel、Plesk），特別標記無法獲得官方修補的 EOL（如 PHP 7.4、8.0、8.1）舊版本。
- 可透過外部攻擊面掃瞄 (如SOCRadar或Shodan等)、或Tenable Nessus等漏洞掃瞄方案等進行更清晰的清點，找出漏網之魚。
- 從互聯網隔離與減低曝露面
- 針對暫時無法完成修補或已EOL的對外系統，應立刻和互聯網隔離，或移至WAF、 VPN、零信任接入或受限制的網絡區段
- PHP 官方亦列出了一些針對特定攻擊路徑的降低風險措施，例如在php.ini設定
session.upload_progress.enabled=0，以及對部分記憶體耗盡路徑調整 “memory_limit=-1″、post_max_size及 Web Server 請求限制。不過，這些措施只屬臨時防禦，不能取代更新，亦不應在未經測試下直接套用到生產環境。
- 強化異常行為監控與攔截
- 監察被入侵後可能出現的可疑行為，在 EDR / SIEM 系統中建立即時警報：嚴密監控網頁服務進程（如 php-fpm、apache2、httpd），一旦發現其衍生出互動式 Shell（如 /bin/sh、cmd.exe）或呼叫外部工具（如 curl、wget），視為最高等級的入侵警報並自動攔截。
長遠的網路安全部署：在 AI 攻擊時代重塑企業防禦韌性
PHP2Shell 的爆發再次證實了資安專家與廠商一再強調的嚴峻現實：在 AI代理與自動化攻擊工具普及的今天，攻擊者不僅能更快找出未知漏洞，更能在漏洞曝光後的短短數小時、甚至數分鐘內，利用 AI 迅速開發出攻擊工具並發動大規模利用（Exploitation），這種攻擊速度下，傳統「等廠商公告漏洞後再排程修補」的被動防禦思維已經徹底失效。
為了因應未來的常態化威脅，企業在長遠的資安架構部署上，應考慮落實以下四大關鍵策略：
引入持續性的外部風險監控 (CTEM, Continuous Threat Exposure Management)
- 企業內部的漏洞掃描往往只看得到「內部視角」，但黑客卻是從「外部網際網路」尋找破口。企業應導入類似 SOCRadar 的外部攻擊面管理（EASM）與威脅情報平台，持續掃描並掌握所有暴露在互聯網上的數碼資產、伺服器及其他應用的版本及潛在風險。透過即時追蹤Dark Web與地下社群中流出的帳號與漏洞討論，企業才能在攻擊者動手之前，先一步掌握防禦先機。
- 傳統年度滲透測試或一次性弱點掃描，只能反映某一個時間點的狀況。但企業內部及曝露於互聯網資產每天都可能改變，因此持續監控才是保障風險可視性的長遠策略
為 Web Application 部署精準的 WAF 防護
雖然WAF（Web Application Firewall） 並不能修補 PHP 本身的安全漏洞，亦不能取代 PHP 更新，但在系統可以進行完整安全更新或升級前，它可以作為空窗期的重要補償性防禦。絕大多數的遠端攻擊流量仍必須透過 HTTP/HTTPS 傳遞。部署具備虛擬修補（Virtual Patching）能力的新一代 WAF，能夠在惡意請求抵達伺服器底層前攔截異常請求，為企業爭取寶貴的修補時間。
縮短修補週期 並引入主動驗證與補償性防禦
早前證監會亦曾就AI輔助攻擊建議企業應重新檢視網絡安全框架以壓縮修補週期，並在漏洞實際修補前建立補償性監控及防禦措施。傳統的漏洞監控方案雖然可以找出環境內的可能被利用漏洞，但並不能驗證「攻擊者實際能否實際接觸及利用」，令IT管理員難以在數千個漏洞中找出真正最需要修補的漏洞。
企業可考慮使用 watchTowr 持續外部攻擊面檢測及驗證平台，在新漏洞出現後迅速確認:
- 哪些資產可以被攻擊者從互聯網接觸
- 漏洞是否在企業現有配置中可被利用
- 哪些外部資產實際運行受影響服務
- 修補或防護措施是否真正有效
- 是否有被遺忘或未列入資產清單的系統
在確認漏洞真正能被攻擊者利用為企業帶來影響時，其Rapid Reaction更會立即規合WAF進行偵測及攔截。讓企業在完成修補前、系統不能停機或需要等待供應商確認期間，持續外部驗證、WAF 虛擬修補、網絡存取限制及異常行為監察，便可形成中間防線。
部署廣泛覆蓋、具備 7×24 監控的 SOC 或 Managed XDR
單點式的防禦已無法應對現代複合式攻擊，可視性是現化安全防護最重要的一環。企業需要建立覆蓋更廣泛的SOC或Managed XDR，盡量收集環境內的數據例如:
- Endpoint
- Server
- Cloud workload
- Identity and Access
- Network (Firewall, Swtich等)
- SaaS 應用程式
- Web Application
- WAF
- API Gateway
- VPN、零信任及遠程存取平台。
透過部署先進的 XDR 方案，將以上的活動數據進行關聯分析。一旦攻擊者透過類似 PHP2Shell 的漏洞成功入侵並企圖進行橫向移動（Lateral Movement）或憑證竊取時，XDR 系統能立即發出警報。而例如Sophos Managed XDR + Next Gen SIEM 更能7×27由專家分析可疑警報及即時嚮應，串聯各個防線進行全域封鎖，將災害降到最低。
結論 – 不能再救火式應對攻擊
PHP2Shell 的出現絕對不會是最後一次。在 AI 時代，軟件漏洞的發現與武器化速度只會越來越快，過去那種傳統「有漏洞公怖才慢慢排隊修補」的救火式模式已不能追上攻擊的速度及密度，如果企業的資安管理依然只把重心放在被動式跟廠商進行漏洞修補，防線很容易就會崩潰。
因此，企業必須徹底轉型為主動防禦，擺脫疲於奔命的救火心態。透過持續性的外部風險監控掌握破口，在修補空窗期內運用 WAF 與自動化防禦平台築起緩衝防線，並藉由 7×24 的 Managed XDR / SOC 實現全域聯防。唯有建立主動且具韌性的防禦生態系，企業才能在瞬息萬變的威脅浪潮中真正掌握安全的主導權。
