重點摘要
- 2026 年 10 月 21 日，PHP 與 Node.js 官方在同一天發布重大安全更新。PHP 的兩個漏洞（CVE-2026-109618、CVE-2026-109619，社群稱為 PHP2Shell）可讓攻擊者未經身分驗證即遠端執行程式碼；Node.js 一次修補 10 個漏洞，其中 4 個為高風險。
- PHP 8.1 以下與 Node.js 20 以下版本已停止官方維護，不會獲得修補，唯一的解法是升級。
- 影響視覺科技資安團隊於當晚接獲自家 AI 監控流程的推播，隨即盤點所有維運中的專案，在 10 月 22 日清晨五點前完成 25 個 PHP 與 Node.js 專案的升級，並於上班時間依專案性質分級通報客戶。
- 如果你的網站或系統使用 PHP 或 Node.js，請立刻檢查版本。文末附自我檢查清單與常見問題。
PHP 與 Node.js 同日發布重大安全更新：發生了什麼事？
2026 年 10 月 21 日，PHP 與 Node.js 這兩個支撐全球大量網站的執行環境在同一天發布安全更新，而且都包含可導致遠端程式碼執行（RCE）的漏洞。對 Web 開發圈來說，這是不尋常的一天。
PHP2Shell：兩個 CVSS 9.2 的遠端程式碼執行漏洞
PHP 官方修補了兩個位於核心記憶體管理與錯誤處理層的漏洞，CVSS v4.0 評分皆為 9.2（Critical）：
- CVE-2026-109618：當請求恰好觸及
memory_limit時，PHP 可能留下只初始化一部分的內部資料，並在請求清理階段把它當成有效資料使用，造成記憶體損毀。在 Apache mod_php 環境下，研究人員以預設設定就示範了完整的遠端程式碼執行。 - CVE-2026-109619：致命錯誤發生時，內部狀態可能指向前一個請求已釋放的記憶體，形成 use-after-free。同一個 worker 處理的下一個請求，可能在狀態被正常重置前就使用了這些過期狀態。
這兩個漏洞的危險之處在於：攻擊者只需要一個未經驗證的 HTTP 請求，就能在任何應用程式碼執行之前觸發。也就是說，無論你的網站是 WordPress、Laravel 還是自行開發的系統，只要 PHP 版本有漏洞，都在風險範圍內。所有處理網頁請求的 PHP 執行方式都受影響，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed。
事件的時間線也很緊迫。CVE 編號在 10 月 20 日提前外洩至論壇與社群媒體，PHP 安全團隊因此將原訂時程提前，於 10 月 21 日 14:00 GMT（台灣時間 22:00）發布修補。發布後不久，Cloudflare 表示已觀測到針對這兩個漏洞的攻擊流量，並為所有方案（含免費方案）部署了 WAF 規則；英國國家網路安全中心（NCSC）則建議無法立即修補的系統考慮暫時下線。
| PHP 版本線 | 修補版本 | 狀態 |
|---|---|---|
| 8.5 | 8.5.12 | 有修補 |
| 8.4 | 8.4.27 | 有修補 |
| 8.3 | 8.3.36 | 有修補 |
| 8.2 | 8.2.35 | 有修補，但安全支援將於 2026 年 12 月 31 日結束 |
| 8.1 以下（含 7.4、8.0） | 無 | 已停止維護，不會修補，必須升級 |
Node.js 十月安全更新：10 個漏洞、4 個高風險
同一天，Node.js 官方發布 26.x、24.x、22.x 三條版本線的安全更新，共修補 10 個 CVE，其中 4 個為 High：
| CVE | 嚴重度 | 影響版本線 | 說明 |
|---|---|---|---|
| CVE-2026-111497 | High | 26.x、24.x、22.x | Brotli 解碼器越界寫入，可導致遠端執行程式碼。由於 fetch() 會自動解壓 Content-Encoding: br 的回應，凡是會呼叫外部 API 的服務都可能受影響 |
| CVE-2026-106069 | High | 26.x、24.x、22.x | 主機名稱可被寬鬆解讀為 IP 位址時，TLS 主機名驗證可被繞過 |
| CVE-2026-105483 | High | 26.x、24.x | IP 位址以全形數字書寫時，TLS 主機名驗證可被繞過 |
| CVE-2026-105482 | High | 26.x、24.x、22.x | dns.resolve 遇到 NUL 字元會截斷網域名稱，可能被用來繞過 SSRF 防護或網域白名單 |
修補版本為 26.12.1、24.22.1、22.23.4。Node.js 20.x 已於 2026 年 4 月 30 日結束維護，不會獲得修補，官方建議升級至 22.x 以上。
Node.js 的升級比表面上複雜。除了伺服器上的執行環境，還要同步更新 Docker 映像、.nvmrc、package.json 的 engines 欄位、CI/CD 設定中的 Node 版本，以及任何內嵌 Node.js 的桌面應用程式。使用啟動快照或單一執行檔（SEA）的專案，必須以新版重新建置，否則其中一個漏洞（randomUUID 重複值問題）仍會存在。
為什麼 PHP 7.4 的網站不能只打補丁，必須升級？
這是本次事件中最多客戶問到的問題，也是我們認為最值得說清楚的觀念。
軟體版本都有生命週期。PHP 7.4 的安全支援在 2022 年 11 月 28 日結束，8.0 在 2023 年 11 月 26 日結束，8.1 在 2025 年 12 月 31 日結束。這些版本統稱 EOL（End of Life），官方不再為它們發布任何修補，即使發現了 CVSS 9.2 的重大漏洞也一樣。
這表示，一個停留在 PHP 7.4 的網站，在 10 月 21 日之後面對的不是「等官方補丁」，而是「永遠不會有補丁」。唯一的路是升級到仍受支援的版本，也就是 8.2 以上。而且考量 8.2 的支援只剩到 2026 年底，更務實的目標是 8.3 或 8.4。
但從 7.4 升到 8.4 跨越了兩個大版本，並不是改一個設定就完成。常見的相容性問題包括：動態屬性在 8.2 起被棄用、字串與數字的比較語意在 8.0 改變、多個舊函式被移除或參數型別檢查變嚴格、以及最常見的，網站所依賴的舊外掛或套件早已停止維護，沒有相容新版 PHP 的版本可用。這些問題需要有經驗的工程師逐一判斷與處理，這也是為什麼許多網站會「一直停在 7.4」：不是不知道該升級，而是升級的成本與風險讓人卻步。
我們的看法是：平時不升級所省下的成本，會在出事的那一天連本帶利還回去。差別只在於，是在你選的時間、以你選的方式還，還是在攻擊者選的時間還。
漏洞修補時間軸：從官方公告到 25 個專案全數完成
從官方公告到 25 個專案全數升級並驗證完成，前後僅數小時。以下是完整時間軸：
| 時間 | 事項 |
|---|---|
| 10 月 21 日 晚間 | 團隊的 AI 漏洞監控流程偵測到 PHP 與 Node.js 官方公告，分析後判定為重大等級，推播通知並附上初步受影響專案清單 |
| 10 月 21 日 深夜 | 完成所有維運中專案的版本盤點與風險評估，依 ISO/IEC 27001 緊急變更程序啟動處置，進行備份並規劃回復方案 |
| 10 月 21 日 深夜至 10 月 22 日 清晨 | 分工進行升級，PHP 專案從 7.4 升至 8.4 或 8.2，Node.js 專案升至對應修補版本，逐一執行升級後驗證 |
| 10 月 22 日 05:00 前 | 全部 25 個專案升級與驗證完成 |
| 10 月 22 日 上班時間 | 依專案規模與性質，以訊息、書面報告或線上會議分級通報所有客戶 |
| 10 月 22 日 當日 | 完成符合稽核要求的變更紀錄與佐證留存 |
資安團隊如何在一夜之間完成漏洞修補？
能在一夜之間完成修補，速度本身不是重點，重點是速度從哪裡來。回顧這次處理，有七件事值得分享。
第一時間知道，靠的是流程而不是運氣
團隊平時訂閱多個官方安全公告與資安情報來源，並由 AI 工作流自動讀取、分析與分級，只有判定與我們維運的專案相關的公告，才會推播給團隊，同時附上比對後的受影響專案清單。這套流程讓我們在公告發布後不久就知道「哪些專案中、嚴重程度多高」，而不是隔天看新聞才驚覺。這部分的做法，我們在另一篇文章〈資安團隊如何靠 AI 工作流做到第一時間反應〉有完整說明。
專案版本盤點不用從零開始
因為平時就維護所有專案的版本清單，盤點階段要做的是確認與補漏，而不是一台一台登入查版本。這次受影響的專案橫跨政府機關、非營利基金會、大學研究單位、科技與製造業企業官網以及新媒體平台，若沒有現成清單，光是盤點就可能耗掉半個晚上。
同時處理 PHP 與 Node.js 兩種技術棧
PHP 與 Node.js 是兩個完全不同的生態系，升級方式、相容性問題與驗證重點都不一樣。團隊同時具備兩者的實戰經驗，才能在同一個晚上並行處理，而不是先修完一邊再學另一邊。
選在深夜，是因為了解客戶的業務
升級必然伴隨短暫的服務重啟，也有相容性問題需要現場處理。團隊清楚每個客戶網站的流量高峰與業務性質，知道哪些網站白天停機代價最高，因此選擇在深夜到清晨這段對客戶影響最小的時間完成，讓多數客戶在上班時收到的是「已處理完成」的通知，而不是「即將停機」的預告。
PHP 8.4 還是 8.2？版本選擇是專業判斷，不是一刀切
本次十個 PHP 7.4.33 專案中，九個直接升級至 8.4.27，一個因既有程式與相依套件的相容性考量，暫時升級至 8.2.35。這個決定是在「立即消除重大漏洞」與「不讓網站因升級而故障」之間取得平衡：8.2.35 同樣包含本次漏洞的修補，能先把風險壓下來，而我們也清楚 8.2 的安全支援將於 2026 年 12 月 31 日結束，因此已將該專案的下一階段升級與相容性測試排入計畫。修補不是修完就結束，而是要追蹤到該專案回到長期受支援的版本為止。
每個專案都走過同一份升級後驗證清單
深夜作業最怕的是「以為修好了」。每個專案升級後都依照固定清單驗證：執行環境版本、服務重啟狀態、前後台主要頁面與功能、HTTPS、表單送出與郵件、檔案上傳、API 與第三方串接、排程程式、錯誤紀錄。其中可自動化的項目由 AI 工作流執行，涉及業務邏輯的項目由工程師確認。
客戶通報也要分級
不同客戶需要的通報深度不同。規模較小或性質單純的網站，以訊息告知處理結果與驗證狀態；規模較大或有合規需求的專案，提供書面報告；對系統複雜或關係重大的客戶，則在當天上午即安排線上會議當面說明。這些通知的初稿由 AI 工作流依專案類型產生，再由負責的工程師審核與調整後送出。至於為什麼我們選擇「先處置、後通報」，以及曾因此被客戶質疑的經驗，我們在〈重大漏洞先修補再報告，錯了嗎？〉一文中完整說明。
能在深夜以這樣的節奏完成，背後還有一件事：團隊成員之間的信任與默契。每個人知道自己負責哪些專案、遇到問題找誰、什麼情況要停下來討論，這些不是當晚才建立的。
ISO/IEC 27001 的制度如何支撐緊急變更？
有人會以為，資訊安全管理制度在緊急狀況下只會拖慢速度。我們的經驗正好相反。
影響視覺科技已取得 ISO/IEC 27001 認證，本次處置依制度中的弱點管理與變更管理程序執行，屬於「弱點修補（Patch Management）」與「緊急變更（Emergency Change）」。制度提供的是判斷依據與行動框架：
- 風險評估有依據：依機密性、完整性、可用性三個面向評估漏洞影響，判定為需優先處理的重大弱點，這讓「要不要半夜動手」不是憑感覺決定。
- 處置有程序：備份、回復計畫、離峰時段執行、變更後驗證，每一步都有既定要求，深夜作業時不需要臨時想。
- 佐證有留存：升級前後的版本紀錄、驗證結果、主機變更紀錄、錯誤紀錄與備份紀錄，事件當天就整理完成，作為日後稽核與客戶查核的依據。
制度讓快速決策有所本，AI 工作流則讓制度跑得快。兩者缺一，這個晚上都不會是這個結果。
這次漏洞事件教會我們什麼？
這次能一夜完成，證明的是團隊的應變能力。但我們也想誠實地談另一件事：為什麼還有十個專案停留在 PHP 7.4。
這十個專案並不是被遺忘的。每一次定期盤點都看得到它們，每一次也都做了評估，而評估的結論一直是「風險可接受，暫不升級」。理由有三個：這些多半是接手維護的既有系統，原始開發團隊已不在，程式碼裡的相依與客製無法完整掌握，維運上以最小變更為原則，貿然跨兩個大版本升級反而可能改壞；這些網站功能穩定、以內容為主，跨版本升級所需的相容性盤點、修改、測試與客戶驗收，成本與時間都不小，在客戶與我們雙方的優先序裡都很難排到「目前沒有問題」的系統前面；而 WAF、監控、備份等補償性控制一直都在，評估時認為足以把風險壓在可接受範圍。
這些評估在當時都站得住腳。這次事件改變的是評估的前提：EOL 版本遇到重大漏洞時沒有補丁可打，風險從「可能」變成「確定」，而且發生的時間由攻擊者決定。所以我們的下一步不是慶祝修得快，而是把「被迫漏夜升級」變成「排程內的例行升級」：對接近 EOL 的執行環境提前預警、把專案資產清單從「人工維護」升級為「自動掃描」、讓重大版本升級的相容性處理有更多自動化支援。這些目標的細節，同樣在〈資安團隊如何靠 AI 工作流做到第一時間反應〉一文中說明；我們的創辦人也從經營者的角度寫下了他對這一夜的看法：〈團隊一夜修完 25 個專案，我卻不想談速度〉。
PHP／Node.js 網站負責人自我檢查清單
無論你的網站由誰維護，以下項目都值得現在確認：
- 伺服器上的 PHP 版本是否為 8.2.35、8.3.36、8.4.27、8.5.12 或更新？執行
php -v或在 WordPress 後台「工具 → 網站狀態 → 資訊 → 伺服器」查看。 - 若使用 Linux 發行版套件，版本號可能不變但已套用修補，請向主機商或系統管理者確認。
- Node.js 版本是否為 22.23.4、24.22.1、26.12.1 或更新？執行
node -v確認。 - Docker 映像是否已重新拉取並重建？
.nvmrc、engines、CI/CD 的 Node 版本設定是否同步更新？ - 使用 Cloudflare 的網站，WAF 規則是否設為「阻擋」而非「僅記錄」？（這只是額外防護層，不能取代更新）
- 若網站仍在 PHP 8.1 以下或 Node.js 20 以下，是否已排定升級時程？
- 你的維護廠商是否主動通知了你？如果沒有，值得問問為什麼。
常見問題
WordPress 網站需要更新 WordPress 本身嗎？ 不需要。這次的漏洞在 PHP 執行環境本身，不在 WordPress 核心、外掛或佈景主題。WordPress.org 已表示不會為此發布更新，修補只需要更新 PHP。
只用 Cloudflare 或 WAF 擋住攻擊可以嗎？ 不能取代更新。Cloudflare 的規則只涵蓋已知的攻擊路徑，無法保證阻擋所有變種。PHP 官方明確表示更新是唯一完整的修補方式。WAF 應視為升級前的暫時緩解，而不是終點。
PHP 7.4 或 8.1 的網站有修補嗎？ 官方沒有。PHP 8.1 以下版本已結束安全支援，不會獲得修補。部分 Linux 發行版或付費長期支援廠商可能提供回補，但對多數網站而言，升級至 8.2 以上是唯一可靠的做法。
Node.js 20 的專案該怎麼辦？ Node.js 20 已於 2026 年 4 月 30 日結束維護，不會修補。請升級至 22.x 以上，並同步更新 Docker 映像與 CI 設定。
升級 PHP 之後要測試哪些功能？ 至少確認首頁與主要頁面、HTTPS、後台登入、表單送出與郵件、檔案上傳、API 串接、排程程式，並檢查 PHP 與 Web Server 的錯誤紀錄有無相容性錯誤。電商網站務必測試完整結帳流程。
暫時無法升級，有什麼緩解措施？ PHP 方面，將 session.upload_progress.enabled 設為 0 並重啟，可阻斷 CVE-2026-109619 的一條已知攻擊路徑，但無法阻斷所有變種。Node.js 方面，可對不可信來源拒絕 br 編碼、避免以 IP 位址直接建立 HTTPS 連線。這些都只是爭取時間，不是解法。
需要協助嗎？
如果你不確定自己的網站或系統是否受影響、不知道該由誰處理，或希望有一支團隊在下一次重大漏洞爆發時主動替你盯著，歡迎預約諮詢。影響視覺科技的資安團隊提供網站與系統的弱點評估、版本升級規劃，以及 ISO/IEC 27001 的建置與導入協助。
參考資料
- Node.js 官方：October 2026 Security Releases
- The PHP Foundation：Today’s PHP Security Release, and How We’re Strengthening PHP Security
- Help Net Security：PHP2Shell: Critical PHP vulnerabilities patched
- Infosecurity Magazine：Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patch
- CyberQ：Node.js 2026 年 10 月安全更新