我寫了一篇文章，整理了 PHP 的緊急漏洞（俗稱 PHP2Shell、CVE-2026-109618 / CVE-2026-109619）的機制與應對檢查清單。
原本主要是彙整對應方法，但在後續持續出現的反應中，我也注意到不少令人介意的聲音。
「乾脆別再用 PHP 了」
「現在還在用 PHP，本來就很老派了」
「這就是那種遺留語言的宿命吧。。」
……真的是這樣嗎？
我個人認為，從這起事件應該讀出的訊息，反而是完全相反的。
這個漏洞不只是 PHP 使用者才需要關心，也不是「選了 PHP 就是錯」的問題。更應該把它看成更大地殼變動的第一個案例。
本文將整理以下三點：
- AI 已經進入能把 C/C++ 製執行環境的記憶體錯誤轉化為實際攻擊的時代
- 為什麼「因為用了 PHP（或舊框架）所以有問題」這個結論是偏離重點的
- 在此之上，我們真正應該投資的是什麼
AI 已經變成能把記憶體錯誤轉換為攻擊的工具
首先要先釐清一個前提：在漏洞世界裡，其實有兩個階段。
- 找出 bug（缺陷）
- 把這個 bug 轉換成攻擊（完成 exploit）
對於記憶體破壞類漏洞來說，第二階段一直都是非常高的門檻。比方說，即使知道有「重複使用已釋放記憶體（use-after-free）」這種缺陷，要把它一路推進到伺服器上的任意程式碼執行，仍然需要大量反覆試驗，例如：
- 推測程序的記憶體配置，並依攻擊者需求準備 heap 狀態
- 規避 ASLR（位址空間配置隨機化）等緩解機制
- 針對 PHP 版本、執行模式（FPM / mod_php / CGI）、以及各種設定差異逐一調整條件
也就是說，從「找到 bug」到「可以攻擊」之間，有一道深谷，必須由熟練研究者花上數個月去跨越。
在漏洞研究界，「已經重現，但放棄武器化」這類報告其實是家常便飯。
換句話說，在過去 30 年找到的龐大記憶體錯誤，有很多其實都只是「已知存在，但還沒變成實用武器」的沉睡狀態，堆積在全世界各地。
那這次到底發生了什麼？
回顧 PHP2Shell 的時間線，大致如下：
- 2024 年：PHP 核心開發者已經注意到這個記憶體問題的早期徵兆。不過因為找不到攻擊路徑（利用方式），修補一直卡住，處於擱置狀態
- 2026 年夏天：安全研究員透過活用 AI 模型（例如 GPT-5.6 Sol 等）進行原始碼分析，成功把這個「沉睡的缺陷」轉換成真正可運作的遠端程式碼執行攻擊鏈。另一家大型資安公司也使用 AI 代理人獨立發現並驗證了它
- 2026 年 10 月：攻擊鏈資訊外洩，PHP 方面以緊急版本釋出進行應對
值得注意的是，這個缺陷本身其實兩年前就已經被知道了。改變的不是「第一階段（發現）」，而是「第二階段（武器化）」的難度。人類研究者花了兩年都沒走到的攻擊路徑，透過 AI 輔助分析卻在數週內完成了。而且還是多個組織獨立做到的。
為什麼這代表「時代變了」
把上述情況一般化來看，意思是這樣：
過去我們的資安評估，（即使是默認的）一直建立在「難以武器化的 bug，實際危害風險較低」這個前提上。漏洞嚴重度判定、修補優先順序安排，以及「應該還好吧」這種樂觀判斷，很多時候都仰賴這個前提。
而現在 AI 已經能填補那道深谷，這個前提就崩解了。
- 全球 C/C++ 製作業軟體中累積的「沉睡 bug」山堆，全部都會成為重新評估的對象
- 未來新發現的 bug，從發現到武器化的 lead time 也會大幅縮短
也就是說，「AI 能把記憶體錯誤變成武器」並不只是某種特定攻擊手法的問題，而是全球軟體資安前提整體上移了一個層級。PHP2Shell 只是第一個大型實例，下一次同樣的事情發生在什麼地方，不一定還是 PHP。
這不是 PHP 的問題，而是「C/C++ 製執行環境」整體的問題。
接下來，來把語言的部分釐清一下。
PHP 的內部是 C
一聽到「PHP 的漏洞」，很多人會以為是 PHP 這門語言本身的規格有缺陷。但這次真正出問題的是 PHP 直譯器本體，也就是用 C 語言寫成的軟體之記憶體管理。而這並不是 PHP 特有的結構。
語言實作 記憶體破壞類 bug 的風險
PHP 有
Python（CPython） 有
Node.js 有
Ruby 有
Go / Rust / Java / C# 記憶體安全語言，結構上較不容易發生
Python 的 CPython 也持續有 buffer overflow 類的 CVE 被發現；而 Node.js 的核心 V8，從 Chrome 的資安更新就看得出來，本來就是記憶體破壞類漏洞的常客（近期甚至也修補了 Chrome 網路堆疊因記憶體破壞而導致的 RCE，CVSS 9.6）。
「只要從 PHP 換成 Python 或 Node，就能解決這類風險」——實際上只是搬進了同樣結構的房子而已。
即使是「現代化」的生態系，致命漏洞依然持續發生。
此外，就算先不談記憶體錯誤，單純從「用了新技術就比較安全」這個假設來看，事實也早已否定了它。
- Java：2021 年的 Log4Shell（CVE-2021-44228）是 CVSS 10.0。其嚴重程度高於 PHP2Shell（9.2），而且直接打到當時企業標準、非常「現代」的 Java 技術堆疊
- Node.js 生態系：光是 2026 年就已經出現被廣泛使用的樣板引擎 RCE（CVE-2026-45618，附公開 PoC），以及透過工具套件導致的任意 JavaScript 執行（CVE-2026-107700）。這兩個都屬於「最新」套件的問題
每個生態系都有、而且形式不同但同樣致命的漏洞。你的技術堆疊這次不是當事者，並不能證明「我們的選擇是正確的」。
「因為用了 PHP 或舊框架所以不行」：三個反駁
前面鋪陳得有點長，來切入主題。對於「因為用了 PHP 所以不好」「因為用了舊框架所以不好」這類主張，事實上有三個明顯錯誤。
反駁①：「用了新東西就比較安全」是有前例可查的謊言
前面已經提過了。Log4Shell 是 Java 的問題，2026 年那一波 RCE 連發是 Node.js 的問題，兩者都是「現在很常見」的技術堆疊。而 PHP2Shell 的缺陷其實從 PHP 5.4 時代就已潛伏，也就是說，這是十多年以前就存在的 bug，直到現在才突然被武器化。變的不是 bug 的「新舊」，而是「能不能武器化」。因此「換成新語言就能避免」這個說法並不成立。下一次也可能發生在你要換去的那個平台上。
反駁②：PHP 不是被放生的語言
對於認為「PHP 已經是化石」的人來說，這點可能會讓你意外，但我們還是看事實。
- PHP 8.x 目前仍持續積極開發中，PHP 8.6 也已經進入 RC（候選版本）階段
- 這次漏洞事件中，官方在接獲資訊外洩後，將原本預定公開的時程提前一天，進行緊急釋出，並且事先把補丁提供給主要 Linux 發行版
- 此外，連已停止支援的 EOL 版本（7.4 / 8.0 / 8.1）也特別準備了例外性的原始碼 backport
真正該看的是發現漏洞之後如何應對，而不是漏洞本身被發現這件事。從這個角度來看，PHP 的處理反而屬於相當迅速且周全的一方。
對「框架太舊」的批評也一樣。Laravel 與 Symfony 都是持續推出主要版本、仍在活躍使用的現代框架；而 PHP 也被約 7 成已知伺服器端語言的網站所使用，單一 WordPress 就撐起了約 4 成的整體網站。若「正在被大量使用的東西就是不好」這個說法成立，那麼就等於大半個網際網路都不好。那不是批評，而是無視現實的說法。
反駁③：這次事件真正「不對」的不是語言，而是營運
整理到這裡，可以歸納成以下幾點：
- 記憶體錯誤的風險不是 PHP 特有，而是 C/C++ 實作的執行環境共同問題
- 「現代化」生態系中，也一樣持續存在其他形式的致命漏洞
- PHP 本身的維護體制其實正常運作中
那麼，這次事件真正危險的是什麼？是繼續使用已終止支援（EOL）版本的環境，以及沒有建立好套用補丁體制的組織。
回頭看這次預期最嚴重的受害情境，像是「還在用 PHP 8.1 以前的 EOL 版本，而且沒有更新計畫」、「PHP 以 root 身分執行的舊式架構改不掉」等等，問題都不是語言選擇，而是營運面。相反地，若是認真追著支援中的 PHP 8.2～8.5 版本的人，只要更新套件、重新啟動 worker 就能完成應對。
不用說，把 EOL 版本放著不管的運作方式，就算你把 PHP 換成別的語言也一樣會沿用下去。語言換了，營運沒變，下一次還是會踩到同樣的坑。
那麼未來該怎麼做？
先暫時離開「PHP 有問題」這個討論，我認為真正有效的投資有以下三項：
- 持續使用受支援版本的體制
這是理所當然的，EOL 不能放著不管。
不要因為「程式能跑就好」或「嫌麻煩所以不想更新」而把版本凍結成永久措施。 - 能以日為單位套用修補的機制
這次事件中，處理速度直接決定了暴露時間。從資訊外洩到官方補丁之間，攻擊準備也在持續進行。
包含套件管理的整備、自動重建容器映像、以及在 staging 環境先行驗證的管線。
「每季集中更新一次」這種做法，在這種事件裡會成為致命延遲。 - 即使被攻擊，也能把損害壓到最低的設計
不要讓 PHP 程序以 root 執行，改成用最小權限的使用者執行。
最小化資料庫使用者權限，並將應用程式、管理介面與資料庫做網路隔離。 - 日誌保全與監控。這次，
我們應該還記得，曾經發現即使攻擊成功，worker 也可能不會當掉，仍然回傳 200 的情況。
關於記憶體安全語言的移轉
「那不是應該轉去 Go 或 Rust（或 Java / C#）嗎？」這樣的討論自然會出現。
美國政府也已經公開鼓勵移轉到記憶體安全語言的報告，從長期趨勢來看，我認為這是正確方向。
記憶體破壞類漏洞這個類別，本來就會逐漸移到那些以結構上較不容易發生這類問題的語言所寫的執行環境。
我也支持這個趨勢。
不過，這和「這次漏洞的對策」是不同時間軸的事情。即使是記憶體安全語言，也無法阻止相依函式庫的漏洞（Log4Shell 就是代表例子）、邏輯 bug、以及供應鏈攻擊。而既有系統的移轉成本，往往是數年規模。
比較務實的做法，是在新開發或大規模重寫的時機納入選項；但不應因為這次事件，就把既有資產因恐慌而全面改寫。這是我個人的看法。
結語
這次事件失去的，不是「PHP 的信用」，而是「沉睡中的 bug 應該無害」這個世界前提。下一次發生同樣事情的，不一定是 PHP。可能是 Python，可能是 Node，也可能是那個你以為「已經捨棄 PHP 時代包袱而換過去的」語言。
到那時候，把責任推給語言的組織，和已經做好準備的組織之間的差距，不會靠幾天的修補作業就能彌補。真正拉開差距的，是日常營運。
原文出處：https://qiita.com/kotowazaman/items/aab621d31a8501617eb4
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
