📍 真實場景
小林，接案的網站管理員，替三家小店維護 WordPress 網站
今天早上他在社群上看到「PHP 出大事了」，但客戶的網站都放在租來的主機上，他不確定自己要不要動手
😖 卡住的地方：他不知道客戶網站跑的 PHP 版本是否受影響，也怕漏洞被利用後，客戶的密碼和金鑰外洩，自己卻毫無察覺
💡 讀完你能在 10 分鐘內查出網站用的 PHP 版本，並知道該做哪些更新和確認
⚡ 一句話講清楚
資安公司 Wiz 的研究團隊公布了 PHP 核心中的多個嚴重漏洞，並歸為兩個 CVE（CVE資安漏洞的公開編號，像是漏洞的身分證字號，方便全世界用同一個名字討論同一個問題），嚴重程度最高到 CVSS 9.2（CVSS替漏洞嚴重程度打分數的標準，滿分 10 分，越高越危險）。PHP 是很多網站背後的程式語言，WordPress、Drupal、維基百科使用的 MediaWiki 都靠它運作。Wiz 指出，這些問題出在 PHP 引擎本身，就算你的網站程式寫得很安全，也可能受到影響。
這些漏洞有兩種危害。第一種是記憶體洩漏（記憶體洩漏程式不小心把自己記憶體裡不該給人看的內容送出去，裡面可能有密碼、登入憑證、API 金鑰）。第二種是未經驗證的遠端程式碼執行（RCERemote Code Execution，遠端程式碼執行，意思是陌生人不用登入，就能在你的伺服器上執行他想跑的指令）。Wiz 說這兩種問題的攻擊者都可以從遠端發動，有些情況相當容易。根據 Wiz 的說法，過去十年發行的每個 PHP 版本，往前回溯到 5.4，至少都受其中一個漏洞影響。
這則消息的特別之處是 AI 扮演了關鍵角色。Wiz 表示，這些缺陷存在了很多年，但要證明它們真的能被利用，必須串起一條極度複雜的步驟，幾乎已經是人類研究員能力的邊緣。前沿 AI 模型大幅降低了這道門檻，把長期存在的缺陷變成了可行的攻擊。PHP 官方已在 2026 年 10 月 21 日釋出修補。Wiz 把這件事比作 Heartbleed 和 Log4Shell 那類震撼業界的事件，這是 Wiz 自己的判斷，但至少要即刻更新這一點，他們的建議很明確。
🏃 快速上手三步（今天就能做）
1
查出你用的 PHP 版本有伺服器權限的話，在終端機執行 php -v，看第一行的版本號。用共享主機的話，到主機商後台找「PHP 版本」或「PHP 設定」頁面。WordPress 使用者可到「工具 → 網站健康狀態 → 資訊 → 伺服器」，裡面會列出 PHP 版本。把每個網站的版本記在一張表上。
▼
2
對照官方公告並更新打開 Wiz 的原文 https://www.wiz.io/blog/php2shell-php-rce，以及 PHP 官方網站 php.net 的發行公告，確認你所用的那個分支（例如 8.x）修補版的版本號。自己管伺服器就用套件管理員或 Docker 映像更新到修補版，更新後再執行一次 php -v 驗證。用主機商的就開客服單問清楚：「貴公司是否已套用 2026/10/21 的 PHP 安全修補？」，並要求書面答覆。
▼
3
假設最壞情況，檢查並預備輪替機密這類漏洞可能洩漏記憶體裡的密碼、權杖、API 金鑰和憑證。如果你的網站在修補前一直暴露在公開網路上，就檢查伺服器日誌有沒有可疑的陌生請求，同時列出網站使用的金鑰和資料庫密碼。只要日誌出現異常，或主機商無法保證沒被入侵，就把這些機密換新。注意：不要等到確認被攻擊才行動，換金鑰的成本遠低於外洩的代價。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 漏洞出在語言引擎本身，而不是你的應用程式，防禦思路有什麼不同？
平常的資安工作多半集中在自己寫的程式碼，像是輸入驗證和權限控制。但這次問題在 PHP 引擎的記憶體安全，應用層寫得再嚴謹也擋不住。所以重點轉到基礎設施的維運：你得知道自己跑什麼版本、誰負責更新、多久能套用修補。能快速更新（容器映像、自動化部署）的團隊，暴露窗口就短；手動維護、版本老舊的團隊則風險最高。另外，縱深防禦（網站防火牆、最小權限、機密不要放在同一個行程可讀的地方）能降低即使被突破後的損失，但不能取代修補。
🔭 AI 讓攻擊者更容易把舊缺陷變成可用的攻擊，這會改變修補的時間壓力嗎？
Wiz 的說法是，以前因為利用鏈太複雜而被視為難以利用的缺陷，現在 AI 可以幫忙跨過這道門檻。這代表過去那種「這個漏洞很難利用，先放著」的風險判斷會越來越不可靠。權衡在於：立刻更新有相容性風險，可能影響舊版外掛或舊程式；延遲更新則是把賭注壓在攻擊者還沒盯上你。比較穩妥的做法是縮短修補週期，先在測試環境驗證，再快速上線，並且特別留意仍在用 PHP 5.x 到 7.x 這類老版本的系統，因為它們可能根本沒有官方修補可用，需要規劃升級。