TL;DR：團隊在數小時內修完 25 個專案，我當然驕傲。但如果一家公司的資安靠的是應變速度，表示前面某個環節已經輸了。真正該談的是：為什麼還有十個專案停在 PHP 7.4，以及我們接下來怎麼讓「漏夜」不再需要發生。
10 月 21 日深夜，我收到團隊的訊息：PHP 和 Node.js 同一天爆出重大漏洞，受影響的專案已經盤點完，正在逐一升級。清晨五點多，第二則訊息：全部完成，驗證通過。上班後客戶陸續收到通知，有幾位特地回覆：「你們反應真快。」
我謝過他們，但心裡想的是另一件事：反應快是好事，需要反應快就不是了。
核心論點：資安能力不該用應變速度衡量，而該用「需要緊急應變的次數」衡量。那一夜證明了團隊的能力，也標出了我們下一個要消滅的問題。
先說那一夜值得驕傲的部分
先把事實攤開。PHP 官方在 10 月 21 日修補兩個核心層級的漏洞（CVE-2026-109618、CVE-2026-109619，社群稱為 PHP2Shell），CVSS v4 評分 9.2，攻擊者不需要帳號密碼，一個特製的 HTTP 請求就能在你的應用程式碼執行前取得伺服器控制權。同一天 Node.js 修補 10 個漏洞，其中 4 個高風險，最嚴重的一個同樣可導致遠端執行程式碼。更關鍵的是：PHP 8.1 以下、Node.js 20 以下已停止維護，不會有補丁。
團隊做了什麼，第一篇實錄寫得很完整，我只講三件讓我驕傲的事，而且都不是速度。
第一，沒有人問「要不要等明天」。公告一出，AI 監控工作流已經把受影響的專案清單比對好推到團隊面前，接下來的判斷是依 ISO/IEC 27001 的緊急變更程序走，不是靠誰的膽識。
第二，每一個專案走的是同一份驗證清單。深夜、疲倦、25 個專案，最容易發生的事是「以為修好了，其實沒有」，而這種錯誤往往要到幾天後客戶打電話來才會被發現。團隊沒有讓它發生，因為清單不是那晚才寫的。
第三，沒有一個客戶是從新聞得知的。上班時間一到，依專案規模與性質，該收訊息的收訊息、該收報告的收報告、該開會的當天上午就開會。這件事背後的工作流，團隊另外寫了一篇。
這三件事的共同點是：它們都在那一夜之前就存在。速度只是它們的副產品。
攻擊者的時鐘，比多數企業想像的快
為什麼「等明天開會再決定」不是選項？看數據。
Cloudflare 在 2024 年的應用安全報告裡記錄了一個案例：JetBrains TeamCity 的漏洞（CVE-2024-27198）概念驗證程式公開後，22 分鐘內就觀測到攻擊嘗試。報告的結論是，漏洞被利用的速度，經常快過人類撰寫防護規則的速度。
Google Mandiant 2026 年 3 月發布的 M-Trends 報告更直接：2025 年漏洞從公開到遭利用的平均時間已是負 7 天，也就是攻擊經常在補丁發布之前就開始；而漏洞利用仍是入侵的第一大途徑，占 32%。
回到這次。PHP2Shell 的 CVE 編號在 10 月 20 日提前外洩，官方被迫提前至 21 日發布修補；當天 Cloudflare 就表示觀測到針對該漏洞的攻擊流量，英國國家網路安全中心建議無法立即修補的系統考慮下線。從修補到攻擊，中間不到一天。
這就是為什麼我們多年前就把「先處置、後通報」寫進緊急變更程序，也是為什麼團隊曾經因此被客戶質疑，而我們選擇把那次質疑變成合約裡的事前授權條款。
那麼，為什麼還有十個專案在 PHP 7.4？
這是這篇文章真正想談的問題，也是我最不想迴避的問題。
PHP 7.4 的安全支援在 2022 年 11 月 28 日結束。三年後，我們手上還有十個網站跑在這個版本上。這不是沒人注意到，每一次定期盤點都看得到這十個，每一次都做了評估，而每一次評估的結論都是「風險可接受，暫不升級」。理由有三個，而且當時都站得住腳。
一是這些多半是接手維護的既有系統。原始開發團隊已不在，程式碼裡有多少未記錄的相依與客製，沒有人能完整掌握。維運的鐵律是變更範圍越小越安全，對接手的系統尤其如此，貿然跨兩個大版本升級，改壞的機率不低，而且壞在哪裡可能要很久才會被發現。
二是成本與效益的權衡。這些網站功能穩定、以內容為主，跨版本升級需要相容性盤點、修改、測試與客戶端的驗收排程，費用與時間都不小。在客戶的預算優先序裡，一個「目前沒有問題」的網站很難排到前面，在我們自己的排程裡也一樣。
三是前面有補償性控制。WAF、監控、備份、定期掃描都在，評估時認為這些能把 EOL 的風險壓在可接受的範圍。
我今天回頭看這三個理由，不認為當時的評估是錯的。錯的是評估裡有一個沒被寫出來的假設：「出事的時候會有補丁可打」。EOL 的真正意義不是「比較舊」，而是這個假設不成立。重大漏洞出現時，有支援的版本面對的是「要多快打補丁」，EOL 版本面對的是「要多快做完一次本來打算明年做的升級」。風險從「可能」變成「確定」，而且發生的時間由攻擊者決定。
我在八月談地端與雲端時說過，前提更新了，三年前的架構決定值得重新推導。EOL 這題是同一回事，只是我們自己也沒有回頭重算。這次重算了，代價是一個晚上。算便宜的。
把「漏夜」變成「例行」
所以接下來的目標很具體：不是讓下一次漏夜更快，而是讓下一次不需要漏夜。
第一，EOL 提前預警。每個專案的執行環境、框架、主要套件都追蹤支援終止日，到期前幾個月自動提醒並排進升級計畫，讓升級在我們選的時間、以我們選的方式發生。
第二，活的資產清單。這次盤點之所以快，是因為平時有清單；但清單是人維護的，人會漏。下一步是讓它由自動掃描產生，盤點從「確認」變成「查詢」。
第三，升級的自動化支援。跨大版本升級最花時間的是相容性盤點與語法調整，這部分讓 AI 工作流先跑，工程師審核。我在七月談 AI 代理時說，從出錯可逆的流程開始、人保留最後簽核，這裡就是實例：掃描與建議交給 AI，部署永遠是人按的。
第四，數字。平均偵測時間、平均修復時間、EOL 專案比例。沒有數字，「持續精進」就只是年終檢討時的一句話。
這些不是買工具。和我在五月談試點時的順序一樣：先定義問題，小規模試，驗證了再寫進流程。這次的問題定義得很清楚：十個專案，三年，一個沒寫出來的假設。
董事長的判斷
我判斷，接下來幾年企業評估維護廠商的標準會變。現在問的是「出事你們多快反應」，以後該問的是「你們多久盤點一次版本、手上有幾個系統在等一個不會來的補丁」。攻擊的自動化程度只會更高，AI 讓概念驗證程式出現得更快，EOL 軟體會成為中小企業最大的單一風險來源，因為它是唯一一種「公告出來就確定沒救、只能升級」的風險。
我可能錯的地方是，我可能低估了預算週期的黏性。即使客戶完全理解 EOL 的風險，「目前沒有問題」的升級案還是會被排到下一季，再下一季。如果是這樣，漏夜還會再發生幾次。我接受這個可能，但我不接受它成為常態，所以預警與清單這兩件事會先做，不等客戶點頭。
一句話帶走：別為反應快鼓掌太久，去數一數自己有幾個系統正在等一個永遠不會來的補丁。 想把這份名單盤出來，歡迎預約諮詢。
FAQ
Q：網站交給廠商維護，我需要知道 PHP 版本嗎？
需要，至少要知道版本和它的支援終止日。這不是技術細節，是風險資訊：支援中的版本出事可以打補丁，EOL 版本出事只能緊急升級。問廠商這兩個數字，答不出來的話，問題不在版本。
Q：升級 EOL 版本一定要停機嗎？
多數情況是短暫重啟加上相容性處理，選對時段影響很小。真正的成本在升級前的盤點與升級後的驗證，不在停機。這也是為什麼排程內的升級遠比漏夜升級便宜。
Q：有 WAF 就夠了嗎？
不夠。WAF 擋的是已知攻擊路徑，這次 PHP 官方的說法是更新是唯一完整的修補。WAF 的正確定位是爭取升級前的時間，不是取代升級。
來源清單
- Today’s PHP Security Release, and How We’re Strengthening PHP Security — The PHP Foundation — 2026-10-21 — https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
- Wednesday, October 21, 2026 Security Releases — Node.js — 2026-10-21 — https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
- PHP2Shell: Critical PHP vulnerabilities patched, update now! — Help Net Security — 2026-10-21 — https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
- Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patch — Infosecurity Magazine — 2026-10 — https://www.infosecurity-magazine.com/news/critical-php-vulnerabilities-leaked/
- Hackers use PoC exploits in attacks 22 minutes after release — BleepingComputer（引述 Cloudflare 2024 Application Security Report）— 2024-07 — https://www.bleepingcomputer.com/news/security/hackers-use-poc-exploits-in-attacks-22-minutes-after-release/
- M-Trends 2026: Data, Insights, and Strategies From the Frontlines — Google Cloud / Mandiant — 2026-03 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
- Supported Versions — PHP — 持續更新（7.4 安全支援終止日 2022-11-28）— https://www.php.net/supported-versions.php