php2shell 漏洞深度解析：兩個 PHP RCE 怎麼修、誰該先動

10 月 21 日 UTC 下午兩點，PHP 一口氣發布了 8.5.12、8.4.27、8.3.36、8.2.35 四個版本，修補兩個被合稱為 php2shell 的漏洞：CVE-2026-109618 和 CVE-2026-109619。兩個都是無需認證的遠端執行程式碼（RCE），CVSS v4.0 評為 9.2。官方公告只有一句結論：「沒有完整的緩解措施，升級是唯一安全的選擇。」

這件事值得寫一篇深度文，有三個理由。第一，受影響的範圍是「所有對外提供網頁服務的 PHP」，而 PHP 撐著網路上一大半的網站。第二，公開之前四天，就已經有人在真實網路上嘗試攻擊，代表這不是紙上談兵。第三，網路上多數中文報導停在「快升級」三個字，但真正麻煩的是「不能馬上升級怎麼辦」，以及「我的環境到底算不算高風險」。

我把官方的兩份 GitHub 安全公告、php.net 的發布說明、PHP Foundation 的事後說明、Calif 的技術文章，加上 Tenable、Rapid7、CISA、Amazon 的分析，整理成一份給開發者和維運的懶人包。本文不會提供任何攻擊步驟或概念驗證，只談清楚風險、修補和防禦。文末我也實際檢查了一台自己的 Laragon 開發機。這幾頁我都在 10 月 22 日打開核對過。

先給結論：你現在該做什麼

圖 1：php.net 首頁的安全公告（來源：php.net）

如果你只有五分鐘，照這個順序做：

1. 盤點。 找出所有在跑 PHP 的機器，包括你沒特別注意、但內含 PHP 的軟體。CISA 特別提醒 PHP 常常是別的軟體的一個元件。
2. 對外的先升。 升到 8.5.12、8.4.27、8.3.36 或 8.2.35，先處理能從網際網路連到的系統。
3. 還在跑 8.1 或更舊的，先下線。 CISA 的建議是，如果沒辦法馬上升級、或還在用已停止支援的版本，就把系統下線直到修好。
4. 升完別急著收工。 去看 web 的 worker 行程有沒有異常地去啟動 shell 或下載工具，這是官方點名要監控的跡象。

就這樣。後面的篇幅是解釋「為什麼」，以及處理那些沒辦法五分鐘搞定的情況。

php2shell 到底是什麼？

名字是研究者取的。發現這組漏洞的資安公司 Calif 把整個利用鏈命名為 php2shell，字面意思就是「從 PHP 打到拿 shell」。它其實是兩個獨立的漏洞，共用一個很底層的成因，所以被綁在一起公布、一起修。

Calif 在技術文章裡把根源追到 2004 年，PHP 當年處理記憶體上限（memory_limit）的方式就埋下了種子；2020 年和 2024 年都有人回報過相關的問題，但當時沒有證明能利用。這次 Calif 用 AI 工具輔助稽核，把它推到了可以穩定遠端執行程式碼的程度。他們在文章裡講得很明白：沒有用到一般人拿不到的特殊模型，AI 也不是「下個簡單指令就挖出所有 bug」，它是研究過程裡的輔助。

兩個漏洞的技術成因，我用一句話各帶過，不展開可被利用的細節：

• CVE-2026-109618（OOM corruption）：PHP 用 longjmp() 處理記憶體不足的錯誤時，會在請求資料還沒完全初始化的狀態下中斷，後續的清理程序可能把這些無效資料當成正常的來用。
• CVE-2026-109619（stale global state）：PHP 的某些全域狀態（錯誤、session、物件、擴充套件的狀態）本該在請求結束時重置，但一個致命錯誤可能讓重置沒做完，下一個請求就可能碰到指向已釋放記憶體的殘留狀態。

兩個的 CVSS 向量一樣：AV:N/AC:H/AT:P/PR:N/UI:N。翻成白話是「可以從網路打、不需要任何權限、不需要使用者互動，但攻擊複雜度高、而且有前提條件」。攻擊複雜度高這點很重要，後面會解釋它為什麼既是壞消息也是好消息。

順帶一提，流出時曾有一個 CVSS 10.0 在傳，那是錯的，PHP Foundation 已經澄清正確分數是 9.2。

哪種部署方式最該緊張？

圖 2：CVE-2026-109618 的 GitHub 安全公告（來源：GitHub Advisory）

官方公告列的受影響清單是：PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed。但這幾種不是同一個等級的風險。

圖 3：各部署方式的官方風險評估（資料來源：php.net 安全公告、GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）

Apache mod_php 是官方明講風險最高的。 原因在公告裡寫得很清楚：mod_php 就算在請求啟動階段失敗，也會無條件執行請求的清理程序，這讓攻擊能在「你的應用程式碼都還沒開始跑」之前就成立。換句話說，你的程式寫得再安全都沒用，因為根本輪不到它執行。官方說，第一個漏洞已經在 mod_php 上、用「預設的輸入和記憶體上限」驗證成功，連多 worker 的 prefork 部署也一樣。

PHP-FPM 的情況比較微妙。 對第一個漏洞，FPM 在啟動失敗時會直接中止該 worker，擋掉了那條特定路徑；但原始碼分析顯示它在成功啟動之後仍可能受影響，只是官方沒有展示完整的 FPM 利用。對第二個漏洞，FPM 則有已驗證的利用路徑。所以 FPM 不是免疫，只是門檻高一點。

FrankenPHP、LiteSpeed 的評估各自不同，但結論一樣是「要升」。要強調的一點：CLI（命令列）不在這份清單裡，這個漏洞是關於「對外服務網頁請求」的。

這裡藏著一個很多人會忽略的現實。以我手上的 Laragon 為例，在 Windows 上用這類整合包做開發，預設往往就是 mod_php，也就是官方評估風險最高的那一種（XAMPP、WAMP 的預設我沒有逐一查）。開發機通常不對外，風險低一截，但如果你曾經把它暫時開到公網做展示，那就是另一回事了。

該升到哪個版本？

圖 4：各版本對應的修補（資料來源：php.net、Tenable）

四個受支援的分支都有對應的修補版本，直接升上去就對了。要注意的是停止支援的那些：

• 8.2 雖然這次有修，但它在 2026 年 12 月 31 日就停止支援，之後不會再有安全更新。如果你還在 8.2，這次升級只是爭取時間，該規劃往上升了。
• 7.4 到 8.1 沒有官方的二進位版本。PHP 只提供了原始碼層級的修補分支（branch 名稱是 PHP-7.4-CVE-2026-109618-109619 這種），也就是你得自己編譯，或等你的 Linux 發行版／LTS 廠商出套件。很多發行版其實事先就拿到了修補，記得去看你的 vendor。
• 5.4 到 7.3 完全沒有修補，只能升級。Calif 說最早可追到的受影響路徑是 PHP 5.4.0，也就是這個種子埋了超過十年。

Windows 使用者可以直接去 php.net 下載頁拿編譯好的版本。我查的時候，8.5.12 的 Windows build（VS17、x64，TS 和 NTS 都有）標的是 10 月 21 日 UTC 13:48 建置，跟發布同一天。

已經有人在打了嗎？

圖 5：Calif 的 php2shell 技術文章開頭（來源：calif.io）

這是這次事件最值得警惕的部分。

Amazon 的威脅情報團隊說，他們的 MadPot 蜜罐系統在 10 月 17 日就記錄到一次 php2shell 的攻擊嘗試，比 10 月 21 日的公開整整早了四天。來源是一個商業匿名網路的 IP。Amazon 說「不清楚攻擊者是怎麼在公開前拿到利用資訊的」。這代表漏洞細節在正式公布之前，就已經在某個圈子裡流動。

公開當天的情況更熱鬧。整個事件的時間線是這樣：

圖 6：從回報到修補的時間線（資料來源：Calif、PHP Foundation、AWS Security Blog）

原本 PHP 排定 10 月 22 日發布。但 10 月 20 日下午，兩個 CVE 編號在論壇和社群流出，PHP 於是把發布時間提前一天到 21 日。PHP Foundation 事後坦承，Calif 不慎公開了一段展示攻擊成功的影片，加速了各種概念驗證（PoC）的出現；提供給關鍵基礎設施業者的緩解建議可能也一併外流。另外，Chainguard 在協調發布前六個多小時，就片面公開了含修補的映像檔。

那現在到底被打得多嚴重？各家說法要分開看：

• Amazon 說 php2shell「正在被廣泛地在野利用」，並建議調查時從 10 月 17 日往前看。但同一篇也說，不確定那些嘗試在真實系統上會不會成功。
• CISA 的公告（10 月 21 日）說，截至發文為止「尚未觀察到利用」。這跟 Amazon 不衝突，只是 CISA 那句話有時間差。
• Rapid7 說預期很快會有可用的公開 exploit，因為 PHP 部署量太大。
• PHP 自己說，公開當下檢視過流出後出現的 PoC，「沒有發現任何可運作的 exploit」。

把這些放在一起，我的解讀是：成熟、穩定的公開武器可能還沒到位，但有能力的攻擊者顯然已經在動，而且時間是以小時計、不是天。Amazon 那句話講得最直接：「用小時來衡量你的修補時程，7 天或 30 天的 SLA 預設了一種已經不存在的從容。」

不能馬上升級？緩解措施與它們的極限

有些系統沒辦法說升就升——相依的擴充套件、要重新測試的應用、改不動的生產環境。官方給了一些緩解設定，但每一條都附帶「這不是完整的緩解」。先把這個前提記牢。

圖 7：官方列出的緩解設定與各自的限制（資料來源：php.net 安全公告、Rapid7、AWS）

幾個關鍵的注意點：

• 設定要從管理端強制。 例如 memory_limit=-1 要用 php_admin_value 這類方式鎖住，讓應用程式沒辦法用 ini_set() 自己改回來。靠應用層或 .user.ini 設的「太晚了」，在請求解析時還沒生效。改完每個 worker 都要重啟。
• 容器和 cgroup 的記憶體上限是不完整的。 Rapid7 特別說，不要用 RLIMIT_AS 或 RLIMIT_DATA 去限制，那反而可能觸發有問題的路徑。
• 把錯誤訊息藏起來沒有用。 關掉 display_errors、用 @ 壓錯誤，都不會阻止殘留狀態被讀取。看不到 log 不等於安全。
• WAF 只是權宜之計。 Cloudflare 當天就推了 WAF 規則，但他們自己也說這只是「STOPGAP only」，而且只覆蓋經過它的流量。如果你的應用根本不用 multipart 表單，在 PHP 之前就把這類請求擋掉，是比較實際的一道防線。

Amazon 另外給了偵測方向：檢查 web server 的日誌，留意表單上傳裡帶有 PHP_SESSION_UPLOAD_PROGRESS 字串的 POST 請求，以及 web 伺服器上有沒有非預期的行程執行或檔案異動。它也公布了幾個觀察到的 IP，但特別提醒那些是共享的匿名基礎設施，不該直接封鎖，而是「看到就去調查」。

一句話總結這一節：緩解措施是給你「撐到能升級」用的，不是替代品。官方的原話是這些措施「不會讓一套系統變安全」。

我檢查了一台自己的開發機

說真的，看再多公告，不如自己打一行指令。我在一台 Laragon 的 Windows 開發機上實際查了一遍，結果蠻有代表性的。

圖 8：本站作者開發機的檢查結果，2026 年 10 月 22 日（資料來源：作者本機的 php -v 與 php -i）

我用 php -v 和 php -i 看到的狀況：

• 這台的 Apache 是用 mod_php 載入的（設定檔裡寫著 LoadModule php_module ... php8apache2_4.dll），正好是官方評估風險最高的那一種。
• 跑的是 PHP 8.5.5，落在受影響範圍，要升到 8.5.12。
• session.upload_progress.enabled 和 fatal_error_backtraces 都是 On，兩個都是第二個漏洞已確認路徑會用到的預設設定。
• 機器上還裝了 7.4.19、8.1.10、8.2.9 這些舊版本，其中 7.4 和 8.1 根本沒有官方修補版本。

這裡有一個 Windows 使用者特別容易踩的坑。我已經下載了 8.5.12，但抓到的是 NTS（Non Thread Safe） 版，而 Apache 的 mod_php 需要的是 TS（Thread Safe） 版，裡面才有 php8apache2_4.dll 這個模組。NTS 版沒有這個檔，不能直接換上去給 Apache 用——它是給 FPM／CGI 用的。所以升級時，要認清自己的執行方式，抓對 TS/NTS。這一步弄錯，換上去 Apache 直接起不來。

我這台是純本機開發、不對外，所以實際風險不高。但它完整示範了一般人會遇到的狀況：預設就是高風險的 mod_php、裝了一堆沒在維護的舊版本、而且連「該抓 TS 還是 NTS」都要想一下。如果這是一台對外的伺服器，上面每一條都得當真。

另一個值得想的問題：AI 正在改變漏洞的節奏

這次事件還有一條線，我覺得比漏洞本身更值得長期關注。

發現 php2shell 的三方是 Calif、OpenAI、Wiz。Calif 和 Wiz 都公開說研究過程用了 AI 模型，OpenAI 的回報則掛在它的 Codex Security 團隊名下。而 PHP Foundation 在事後的文章裡講了一段很實在的話：AI 輔助研究的興起，讓 PHP 安全團隊收到的回報量暴增，他們從 7 月以來發了 15 個 CVE，同時處理了超過 100 件「最後證實無效、重複或無法重現」的回報。AI 幫忙驗證，但「每一個判斷都是人做的，每一個修補也都是人寫的」。

把這件事放大看：找漏洞的那一方開始用 AI 加速，而修漏洞、審回報的維護者還是那幾個人。PHP Foundation 在文章裡直接點名，懂這套程式碼底層的工程師「太少了」，並呼籲贊助商和政府投入資金。這不是 PHP 獨有的問題，是整個開源基礎設施共同的處境。

所以 php2shell 的意義，不只是「又一個要修的 RCE」。它是一個預演：當攻防雙方的工具都變強，防守方的瓶頸會從「有沒有能力找到漏洞」轉移到「有沒有足夠的人手消化」。本站寫過一人加數百個 AI 代理攻破 440 台 PaperCut，也寫過 Anthropic 把內部評測的網路全斷，講的都是同一股趨勢的不同面向。Amazon 那句「用小時衡量」的建議，背後其實是同一件事。

我的判斷

這個漏洞該不該緊張？如果你有任何對外的 PHP 服務，該，而且是現在就處理。它無需認證、可遠端打、官方明說沒有完整的緩解——這三個條件湊在一起，就是「放著等於開門」。mod_php 的使用者又比別人多一層急迫。

但也不必恐慌。CVSS 向量裡的「攻擊複雜度高、有前提條件」是真的，這也是為什麼公開當下還沒有人端出穩定的公開武器。這給了你一個以小時計、但確實存在的時間窗。把它用在刀口上：對外的先升，升不動的先用緩解加 WAF 撐著，同時排好升級的時程。

什麼會讓我把警戒再往上調？如果出現經過驗證、穩定可用的公開 exploit，或者 Amazon 以外的多方都確認大規模在野利用成功，那門檻就從「有能力的攻擊者」降到「任何人」，到時候連內網的系統都要重新評估。反過來，如果接下來兩週證明這些利用路徑在真實環境裡的成功率很低，那現在的「以小時計」就可以稍微鬆一口氣——但該升的還是要升，因為 8.2 底還要再面對一次停止支援。

最後重複一次最重要、也最容易被跳過的一步：升級是唯一的完整修補。緩解措施只是讓你活到升級那一刻。