全球網站常用的伺服器端程式語言 PHP，近日被發現兩項代號「PHP2Shell」極嚴重安全漏洞，攻擊者在特定條件下毋須登入網站，便可能遠端執行惡意程式碼，甚至控制伺服器。兩項漏洞的 CVSS v4.0 風險評分均達 9.2 分，影響包括 WordPress、Drupal、Joomla 等大量使用 PHP 的網站系統。
PHP 開發團隊已於 2026 年 10 月 21 日發布緊急安全更新，歐盟網絡安全局 ENISA、CERT-EU 及多個國家網絡安全機構亦聯合呼籲企業立即修補。由於漏洞存在於 PHP 核心，而非個別網站外掛程式，單靠更新 WordPress 或停用插件，並不能解決問題。
國家工信部亦發出《關於防範 PHP 遠程代碼執行超危漏洞的風險提示》，建議相關單位及使用者立即進行全面排查，及時升級至最新安全版本，或採取臨時下線、關閉會話上傳進度功能、網路隔離、網路存取限制等臨時防護措施；加強網路安全監控與管理，及時修改帳號、口令及金鑰等憑證，防範網路攻擊風險。
香港資訊科技商會榮譽會長方保僑表示，當務之急是盡快完成系統盤點，並安裝官方最新發布的安全修補程式（Patch）。若網站架構較為複雜，暫時無法在短時間內升級修正，最安全的應對做法是果斷將網站暫時離線或切換至維護模式，待徹底解決安全漏洞後再重新開放，絕不能抱有僥倖心理，給予黑客任何可乘之機。
兩項記憶體管理漏洞 可能令黑客取得伺服器控制權
這次發現的漏洞分別為 CVE-2026-109618 及 CVE-2026-109619，均涉及 PHP 在處理網頁請求時的內部記憶體管理機制。
CVE-2026-109618 屬於記憶體不足（Out-of-Memory，OOM）處理缺陷。當 PHP 處理請求時遇上記憶體配置失敗，部分內部資料可能尚未完成初始化，清理程序卻把這些不完整資料當成有效資料處理，造成記憶體損毀。
CVE-2026-109619 則涉及殘留的全域狀態（Stale Global State）。當 PHP 完成請求並釋放記憶體後，部分內部指標仍可能保留舊有狀態。當同一個 PHP 工作程序處理下一項請求時，便可能錯誤地使用已釋放的記憶體。
這類問題可能形成 Use-after-free 等記憶體安全風險，讓攻擊者在特定條件下控制程式執行流程。安全研究人員已展示可成功利用相關漏洞執行惡意程式碼的攻擊方法，意味着風險不再只是理論推測。一旦攻擊成功，攻擊者可能以 PHP 工作程序的權限執行指令，讀取網站設定、存取資料庫憑證、篡改網頁內容，甚至進一步入侵同一伺服器上的其他服務。
Apache mod_php 風險最高 PHP-FPM 同樣不能掉以輕心
PHP 官方指出，今次問題影響各種負責處理網頁請求的 PHP 執行環境，包括 Apache mod_php、PHP-FPM、php-cgi、FrankenPHP 及 LiteSpeed。其中 Apache mod_php 被評為風險最高的部署方式。
研究人員已證實，在特定配置下，攻擊者可以於應用程式本身的 PHP 程式碼尚未開始執行前，便利用 PHP 處理請求的內部流程觸發漏洞。
PHP-FPM 雖然採用不同的工作程序管理機制，能阻止部分針對 mod_php 的利用方式，但研究人員亦已驗證，配合合適的應用程式操作及錯誤處理條件，PHP-FPM 仍可能遭到攻擊。因此，即使網站使用 Nginx 配合 PHP-FPM，也不能認為已經安全。
PHP 官方發布四個安全版本
PHP 開發團隊已發布以下安全修補版本：
| PHP 系列 | 最低修補版本 |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
使用上述系列舊版本的網站，應盡快更新至相應修補版本或更新的安全版本。
PHP 8.1 及更舊版本已停止由 PHP 官方提供一般安全更新。不過，部分 Linux 發行商及長期支援供應商可能自行把修補程式回溯移植至舊版本，因此管理員應檢查供應商的安全公告，而不能只看 PHP 的版本號判斷是否已修補。
PHP 官方亦特別提供 PHP 7.4、8.0 及 8.1 的最小化原始碼修補，方便仍然需要維護舊系統的供應商與開發者使用，但這並不代表相關舊版本重新獲得官方長期支援。
關閉 Session Upload Progress 只能減低部分風險
漏洞正式公開前，部分網絡安全研究機構曾建議網站管理員透過修改 PHP 設定，停用 Session Upload Progress 功能：
session.upload_progress.enabled = Off
這項功能原本用於追蹤檔案上載進度，預設情況下處於啟用狀態。PHP 官方確認，停用功能可以阻止其中一條已知攻擊路徑，但無法完整修補兩項漏洞。原因是 CVE-2026-109618 涉及更廣泛的記憶體不足處理問題，而 CVE-2026-109619 亦存在其他可能觸發殘留狀態的途徑。
此外，相關設定必須在 PHP 開始解析請求前生效，並重新啟動 PHP 工作程序。若僅在應用程式內使用 ini_set()，或依賴 PHP-FPM 的 .user.ini 設定，便可能無法阻止已確認的攻擊流程。
對無法立即更新的網站，PHP 官方亦提出限制請求大小、降低可由外部觸發的嚴重錯誤，以及在適當情況下調整記憶體管理設定等臨時措施。然而，部分緩解方法可能增加伺服器耗盡記憶體的風險，必須按實際部署環境評估。
PHP 官方明確指出，沒有任何已知臨時措施能完整取代安全更新。
WordPress 網站須更新伺服器 PHP 只升級網站程式並不足夠
這次漏洞對 WordPress 網站尤其值得關注。WordPress 本身以 PHP 開發，WooCommerce、Drupal、Joomla，以及大量網站插件和主題亦依賴 PHP 執行。即使網站已安裝最新 WordPress Core、Plugin 及 Theme，只要底層 PHP 執行環境仍然存在漏洞，便可能受到影響。
使用 AWS Lightsail、Amazon EC2、VPS、自架伺服器或其他雲端託管平台的管理員，應首先核實網站實際使用的 PHP 版本，而不是單純檢查主機的 Linux 版本。若使用 Linux 發行商提供的 PHP 套件，應查看相關安全修補是否已經回溯整合；如果使用自行編譯的 PHP、第三方套件庫或預先安裝的應用程式映像，則需要另外確認更新來源。AWS Lightsail 等雲端平台的作業系統映像發布日期，也不一定能證明其中的 PHP 已經修補。管理員應檢查已安裝套件的實際安全更新及 PHP 執行環境。
由於跨主要 PHP 版本升級可能影響網站插件、主題及自訂程式碼，企業應先備份網站及資料庫，在測試環境驗證兼容性，再安排正式更新。但考慮到這次漏洞的嚴重程度，企業不應僅因等待下一輪例行系統升級，而長時間繼續使用未修補版本。
GPT-5.6 Sol 協助發現漏洞 OpenAI 聯同 Wiz、Cloudflare 協調全球修補
這次事件另一個值得關注的地方，是人工智能在漏洞研究中扮演的重要角色。OpenAI 表示，網絡安全研究公司 Calif 在「Patch the Planet」計劃中，利用 GPT-5.6 Sol 協助發現其中一項 PHP 嚴重漏洞。
Google 旗下網絡安全公司 Wiz 則獨立發現並通報兩項漏洞。在過去約兩個月，OpenAI、Wiz、Cloudflare、PHP 維護團隊及其他合作夥伴共同進行漏洞驗證、修補測試及全球協調披露。PHP 開發團隊負責正式修補及發布安全版本，而雲端服務商與網絡安全機構則提前準備防護措施。
OpenAI 指出，先進 AI 模型正大幅提高發現複雜軟件漏洞的能力。然而，同樣的技術亦可能被攻擊者利用，加快分析安全修補程式、尋找可利用的漏洞，以及開發自動化攻擊工具。這意味着未來重大漏洞由發現、公開到大規模利用之間的時間，可能進一步縮短。
歐盟發出聯合警告 企業應立即盤點及修補系統
歐盟委員會、ENISA、CERT-EU、Europol 歐洲網絡犯罪中心及歐盟各國電腦保安事故應變團隊，已就今次 PHP 漏洞發出聯合安全警告。當局要求企業立即盤點使用 PHP 的網站與服務，優先修補公開連接互聯網的系統，並與雲端及託管供應商協調更新。企業亦應監察伺服器的異常請求、PHP 工作程序崩潰、可疑檔案變更及不明對外連線，評估更新前是否已有可疑活動。
對香港企業而言，除了網站及電子商貿平台，內部使用 PHP 的客戶管理系統、員工入口、檔案上載服務及舊式業務應用程式，同樣需要納入檢查範圍。
這次 PHP 漏洞事件反映，網站安全不僅取決於 WordPress 等應用程式是否維持最新版本，底層程式語言、Web Server、作業系統及託管平台的安全維護同樣重要。在 AI 已經能夠協助發現如此複雜的底層漏洞之際，企業必須縮短安全更新周期，並建立更有效的漏洞管理及緊急應變程序。
