您知道公司裡有多少 PHP 系統嗎？ 4 步驟用 AWS 快速找出受影響系統

全球網站爆發重大資安漏洞！全球最普及的伺服器語言之一 PHP，常見於新聞網站、線上購物與企業官網，近日 PHP 官方針對兩個重大漏洞發布緊急更新，攻擊者不需要帳號密碼，就可能遠端控制網站伺服器，消息一出，引發各界譁然。 
 

台灣數位發展部資安署已發布警訊，呼籲使用 PHP 的機關、學校與企業儘速確認版本並更新，資安署也提醒，部分軟體雖未明說，內部其實也用到 PHP，換句話說，很多企業並不確定自己有多少系統受到影響。 

本文從架構師的角度，說明如何在 AWS 環境中找出所有 PHP 執行環境、判斷版本風險，並建立下一次重大漏洞來臨時能快速反應的盤點機制。 
 

PHP 是什麼？ 

簡單來說，PHP 是一種在伺服器端執行的網站程式語言，您每天瀏覽的新聞網站、使用的購物平台，背後都可能由 PHP 支撐，當用戶登入會員、將商品加入購物車，或點開一篇最新報導時，PHP 就在伺服器上處理這些請求，再把結果組成網頁回傳給您。 

如果把網站比喻成一家店，網頁是門市櫥窗，PHP 則是在後場備貨、結帳的工作人員：雖然看不見，卻讓整家店得以運作，也正因為 PHP 位在後場，一旦出現漏洞，攻擊者就有機會直接進入網站最核心的區域。 

根據 W3Techs 的統計，在可辨識伺服器端語言的網站中，約 69.3% 使用 PHP；WordPress、Drupal、Magento 等常見網站與電商系統，底層也都是 PHP 在運行。 

PHP 漏洞應變第一步：先盤點，再修補 

2026 年 10 月，PHP 官方針對兩個可未經驗證遠端執行程式碼的漏洞（CVE-2026-109618、CVE-2026-109619，統稱 PHP2Shell）發布緊急修補，修正版本為 PHP 8.5.12、8.4.27、8.3.36 與 8.2.35，官方說明所有處理網頁請求的 PHP 安裝都受影響，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed，其中 mod_php 風險最高。 
 

在此情況下，企業能爭取的時間非常有限，要在最短時間內完成修補，前提是先弄清楚兩件事：公司裡到底有哪些主機、容器和服務在跑 PHP？它們各自是什麼版本？ 

例如官網用 WordPress 架設，內部系統是幾年前委外開發的 PHP 專案，還有部門自行在 Lightsail 上開了一台主機，這些系統分散在不同人手上，平常沒有統一記錄，少了一份完整清單，就算修補了一輪，也無法確定是否還有遺漏。 

AWS 資產盤點教學：4 步驟找出所有 PHP 主機與漏洞 

要做好盤點，不一定得另外導入第三方工具，AWS 本身就有三項服務可以分工合作 

• Systems Manager Inventory：定期整理每台主機裝了哪些軟體 

• Run Command：可以直接在主機上執行指令，確認目前實際運作的版 

• Amazon Inspector ：自動掃描，找出有已知漏洞的系統 

以下依實際操作的順序說明： 

步驟一：確認主機都在 Systems Manager 管理之下 

Systems Manager 並不會自動看到每一台主機，一台 EC2 要被納入管理，必須同時符合三個條件：裝有 SSM Agent 並正常運作、設定好對應的 IAM 權限，而且網路能連到 Systems Manager。 

因此第一步，請把 EC2 主控台的執行個體清單，和 Systems Manager 的「受管節點」清單放在一起對照，只要出現在 EC2、卻不在受管節點清單裡的主機，後續的工具都查不到，是最需要優先補上設定的盲點。 

圖 / Systems Manager 的受管節點清單，可查看每台主機的 SSM Agent 版本、連線狀態與作業系統。（圖片來源：AWS） 

步驟二：用 Systems Manager Inventory 查詢已安裝的 PHP 套件 

啟用 Systems Manager Inventory 後，它會定期記錄每台主機裝了哪些軟體，包括名稱、版本與發行者。您不需要逐台登入檢查，只要一行指令，就能找出所有主機上名稱以 php 開頭的套件： 
 

若有多個帳號與區域，可以將 Inventory 資料同步到 Amazon S3，再用 Amazon Athena 集中查詢，產出一份全公司的 PHP 版本清單。 

步驟三：用 Run Command 直接確認執行中的版本 

由於 Inventory 的資料是定期收集的，不一定是當下最新的狀態，遇到重大漏洞時，建議再用 Run Command 直接在主機上執行指令，確認現在實際運作的是哪個版本。例如，下面這段指令會對所有標記為正式環境的主機，一次查出 PHP 版本： 

這個方法還有一個好處：有些 PHP 不是透過套件管理工具安裝的，Inventory 查不到，但用 Run Command 一樣找得出來。 

步驟四：啟用 Amazon Inspector 持續掃描 

前面三個步驟是找出公司裡有哪些 PHP，Amazon Inspector 則能進一步找出哪些有已知漏洞，它會自動掃描 EC2 主機、Amazon ECR 裡的容器映像，以及 Lambda 函數，還能直接用 CVE 編號篩選結果。 

如果公司有使用容器，建議開啟 ECR 的增強型掃描（Enhanced scanning），開啟後，新推送的映像會自動接受檢查，不必一個個拉下來確認。 

另外，如果程式碼放在程式碼儲存庫中，也可以使用 Inspector 的程式碼安全功能，檢查 PHP 專案透過 Composer 引用的第三方套件是否有漏洞。 

不過要留意，AWS 官方文件列出的支援範圍是 PHP 8.2 以下版本，導入前請先確認專案使用的版本。 

PHP 漏洞修補指南：各版本升級與處理建議 

拿到清單後，不同版本的處理方式差異很大，以下以此次 PHP 事件為例： 
 

同一版本層級內，再依曝險程度排序：直接對網際網路開放、且使用 mod_php 的服務最優先，內部系統其次。 

更重要的是，把這次的盤點變成常態，Inventory 與 Inspector 保持啟用，新主機透過標準化的 AMI 或基礎設施即程式碼建立，預設就納入管理。下一次重大漏洞出現時，清單已經在那裡，團隊可以直接進入修補。 

AWS 環境中常見的 PHP 位置 

PHP 不只跑在「網站主機」上，以下是 AWS 環境中常見的 PHP 位置，以及它們容易被漏掉的原因。 
 

開始盤點前，建議先確認公司有哪些 AWS 帳號與區域，若使用 AWS Organizations，可以從管理帳號一次檢視所有成員帳號，避免只盤點到「自己記得的那幾個」。 

此次的 PHP 漏洞是由 AI 找到的，這也代表未來漏洞被發現的速度只會越來越快。平時就清楚掌握自家系統的企業，遇到事件時才能把時間花在修補上，而不是到處尋找哪些系統受到影響。 

銓鍇國際長期協助企業規劃、建置與維運 AWS 雲端環境，面對 PHP 這類重大漏洞，我們能協助您全面檢視多帳號、多區域的 AWS 環境，找出所有 PHP 系統與對應版本；如果您想確認公司的系統是否受到 PHP2Shell 影響，歡迎與我們聯繫。