工具已公開，但不是輸入網址就能保證安全
OpenAI 在 2026 年 10 月 21 日的公告中分享了 PHP 版本檢查工具 php2shell-checker。專案已在 GitHub 公開，採 Apache 2.0 授權，可免費取得程式碼，讓網站管理者從網址或本機 PHP 版本進行初篩；也提供 phpcheck-url 與 phpcheck-server 兩個 Codex 技能，協助整理檢查流程。
先釐清使用形式：這是可下載執行的工具與 AI 代理技能，不是瀏覽器打開就能使用的線上掃描服務。網址模式只比對網站回應中透露的版本，不測試漏洞能否被利用，也不會自動修補。
為什麼站長需要確認 PHP，而不只是更新外掛？
PHP 官方於 2026 年 10 月 21 日發布安全公告，指出 CVE-2026-109618 與 CVE-2026-109619 可能導致未經驗證的遠端程式碼執行。Ubuntu 公告列出兩者的 CVSS v4.0 分數均為 9.2。PHP 官方提醒，對外處理網頁請求的 PHP 部署都應檢查，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed，並認為 mod_php 風險最高。
官方修補版本為 PHP 8.5.12、8.4.27、8.3.36 與 8.2.35。這是 PHP 執行環境的問題，因此不能只因網站程式或外掛已更新，就認定底層 PHP 也已修妥。使用主機代管服務的站長，應向業者確認對應網站的 PHP 套件及修補狀態。
網址初篩怎麼做？三種結果要分開看
從官方 GitHub 下載並解壓專案，在已安裝 Node.js 的環境中進入專案資料夾，可用 node phpcheck.js "https://example.com" 檢查網址；請將範例換成自己管理或已獲授權檢查的網站。若要檢查目前環境的命令列 PHP，則使用 node phpcheck.js --local。
網址模式讀取 Server 與 X-Powered-By 標頭，先送 HEAD，只有收到 405 或 501 才改送 GET；不跟隨轉址，也不檢查網頁正文。網站未公開 PHP 版本時，工具可能無法判斷，不必為了得到結果而公開額外的版本資訊。
- OK（結束碼 0）：版本通過工具內建門檻比對，不等於已獨立驗證安全修補。
- VULNERABLE（結束碼 1）：版本落在內建受影響範圍，需確認修補；不表示網站已遭入侵。
- UNKNOWN（結束碼 3）：缺少版本、無回應或版本無法辨識等情況，不能當成安全通過。
最容易誤判的地方：命令列版本與網站版本不一定相同
OpenAI 的 phpcheck-server 說明要求從 php -v 開始，但還要確認該版本與網站實際使用的 PHP-FPM 或 Apache 安裝一致。因此，單獨執行 --local，並不等於已完成網站執行環境與修補狀態的核對。
另一個陷阱是發行商移植修補：安全修正可能套用到較舊版本，而非直接更換成 PHP 上游的新版本號。例如 Ubuntu 公告將 24.04 的已修補套件列為 8.3.6-0ubuntu0.24.04.13。只看 8.3.6，容易忽略套件後半段的修訂資訊；應以完整套件版本對照供應商公告。
Ubuntu 也提醒，安裝更新後，使用 PHP 的服務通常還需重新啟動，才能載入修補後的元件。多站點或多版本環境，應逐一確認實際提供服務的執行環境，不能用一個終端機結果代表全部網站。
AI 觀點分析與推論
AI 觀點：真正有價值的是縮短盤點，不是多一個綠燈
我傾向認為，這類工具最能幫助的是缺乏專職維運人力的小型團隊：先用一致方法收集版本訊號，再把無法確認的項目交給主機商或管理員追查。它降低的是開始盤點的門檻，並沒有消除專業判斷的必要。
反面情境是把 OK 當安全證書，或把 UNKNOWN 當作沒有問題，反而提早結束處理。較合理的流程應保留三份資料：對外觀察到的版本、實際服務使用的完整套件版本，以及對應修補公告。後續若工具能可靠結合發行商套件紀錄與服務端資訊，才有理由提高對自動判讀的信任。
檢查之後，仍要完成修補確認
PHP 官方明確指出，更新才是完整解法，暫時緩解只能降低特定攻擊路徑的風險。PHP 8.1 與更舊分支已不再取得 PHP 專案的一般更新，使用者應確認供應商是否提供移植修補，或規劃遷移到受支援版本。
本文由 AI 協作採寫，依官方文件核對工具用途與限制；未對任何讀者網站執行掃描，也不把文件核對視為實機安全測試。
