PHP2Shell現疑似真實利用：PHP網站應即時查核
iThome 報道指出，PHP2Shell（CVE-2026-109618、CVE-2026-109619）公布修補後不久，Perplexity 研究員 Adel Karimi 在自行部署的蜜罐中，觀察到攻擊者成功啟動 /bin/sh 並執行 Shell 指令。對營運 PHP 網站、尤其使用 Apache mod_php 的管理員而言，這令事件由「掃描及偵察風險」提升至必須假設可被用作遠端程式碼執行的緊急修補事項。
不過，現階段證據來自單一研究員的蜜罐觀察，並非大規模受害個案統計；攻擊者身分及兩個來源是否屬同一組織亦未能確定。因此，不能據此斷言漏洞已被廣泛利用，但足以支持網站營運者立即盤點暴露面及保留調查所需日誌。
蜜罐觀察到甚麼
iThome 報道稱，Karimi 在 10 月 24 日 UTC 19:26 至 19:31 之間，經六個感測器捕捉到 35 次 Shell 處理程序執行。目標蜜罐運行 PHP 8.4.26，並採用 Apache mod_php；攻擊流程透過 Apache 的特定處理程序啟動 /bin/sh。
報道所述流程分為四步：先製造 RAM 壓力，再以過大的 PHPSESSID Cookie 取得記憶體資訊；其後再次施加壓力，最後按取得的記憶體位址調整請求內容，以達成利用。這種流程反映攻擊並非單靠一次普通 HTTP 請求即可完成，惟對外提供服務的主機不應把利用門檻較高，當作延後修補的理由。
管理員可優先做的事
來源資料未列出完整受影響版本範圍及各分支的修補版本，部署團隊應直接核對 PHP 開發團隊的安全公告及自身套件庫更新紀錄，確認已套用針對兩個 CVE 的修補。就現有報道可支持的條件而言，使用 PHP 及 Apache mod_php 的環境應列為優先檢查對象。
日誌覆核可集中於以下線索：
- 異常巨大的
PHPSESSIDCookie，以及短時間內重複、內容逐步變化的請求。 - Apache 或 PHP 相關處理程序意外衍生
/bin/sh。 - 同一主機在可疑請求後出現
phpCLI、curl、wget等命令執行痕跡。 - 來源 IP
15.204.59[.]70與162.35.99[.]94的連線紀錄；它們可作排查線索，不能單獨作為攻擊歸屬證據。
若發現上述跡象，較穩妥的處置是先隔離相關主機、保存 Web、PHP 與系統程序日誌，再檢查帳戶、排程、網站目錄及對外連線是否出現後續入侵痕跡。單純封鎖來源 IP 並不足以處理已成功取得 Shell 的情況。
iThome 指出，先前外界看到的不少 PHP2Shell 活動較偏向尋找脆弱環境；這次蜜罐紀錄則顯示至少有人正在嘗試完整利用鏈。接下來應觀察是否有更多獨立研究或事故通報，確認利用是否擴散至不同 PHP 部署方式；在此之前，修補狀態與日誌可見度會是 PHP 網站最實際的防線。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — 重大漏洞PHP2Shell傳出駭客成功利用，於伺服器執行Shell指令 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
