PHP「PHP2shell」CVE-2026-109618:記憶體不足時的處理會破壞請求資料,可能讓未登入的攻擊者遠端執行程式碼

影響範圍

PHP 是許多網站在伺服器端使用的程式語言。這次一起修補的有兩個漏洞,合稱「PHP2shell」;本頁講的是 CVE-2026-109618(官方標題為「RCE via OOM corruption」,GitHub 公告編號 GHSA-w8hw-w9fx-j79w),另一個是 CVE-2026-109619。

舊版本是否受影響,各來源說法不一:

• Datadog 表示 PHP 5 到 8.1 也受影響,但已停止支援,不會有修補。Sansec 稱有問題的程式碼可追溯到 PHP 5.4.0(2012 年),官方未確認。
• 維護者的 GHSA 寫的受影響版本是「< 8.2.35、< 8.3.36、< 8.4.27、< 8.5.12」,第一段沒有下界;NVD 的 CPE 第一段也只有 versionEndExcluding 8.2.35、沒有起始版本,字面上包含 8.1 以前的版本。
• 同一廠商的 CVE 紀錄(CNA)只列出 8.2.–8.5. 的範圍,其他版本預設(defaultStatus)標為「不受影響」。本頁並列兩邊,不選邊;偵測與修復建議取聯集,8.1 以下請當作可能受影響。watchTowr 也指出「PHP 5 以後全部受影響」的說法未獲官方公告確認。
• PlainCVE 的判斷:官方特地為 7.4、8.0、8.1 提供回移植修補,顯示這些分支很可能受影響,但官方並沒有明說。

攻擊條件(官方確認的部分): 攻擊透過 HTTP 進行,官方表示不需登入。已有人在 Apache mod_php(把 PHP 直接載入 Apache)上示範成功,在 mod_php 上攻擊發生在網站程式碼執行之前(依 GHSA,FrankenPHP 可能相同)。FPM(獨立 PHP 程序池)在請求啟動失敗時會結束子程序,依原始碼分析仍可能受影響,但要在應用程式正常啟動後、由各應用程式自己的情境觸發,尚無完整示範;LSAPI 依 GHSA 與 FPM 類似。php.net 把 FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed 都列為有風險,並認為 mod_php 風險最高。

研究者補充: Datadog 表示應用程式自己的登入機制擋不住(官方只在 mod_php 上確認攻擊不經網站程式碼),而且任何 PHP 腳本都會經過有問題的程式路徑;Sansec 表示已知的觸發方式都是 multipart/form-data(表單上傳格式)請求。

是否需要開啟 session 上傳進度功能,各來源說法不一: JFrog(該頁含攻擊程式,本站不連結)把 session.upload_progress.enabled=On(預設值)加上接受 multipart 上傳列為必要條件;Datadog 則表示關掉這項設定並不能保護你;官方只把這項措施列在 CVE-2026-109619 下。

原理

PHP 處理一個網頁請求時,會先在記憶體裡建立這次請求要用的內部資料。如果中途記憶體不足(OOM,out of memory),PHP 會用 longjmp()(一種直接跳出目前流程的 C 語言機制)放棄這次請求。

問題是:有些程式路徑沒有考慮到「配置記憶體時可能被直接跳出」,在配置之前留下了還沒初始化的資料。接下來請求的清理程序把這些無效資料當成有效的來處理,導致記憶體損壞。CVE 紀錄列出的弱點類型包括 CWE-416(使用已釋放記憶體)、CWE-824(存取未初始化指標)、CWE-755(例外狀況處理不當)、CWE-1325 與 CWE-1419。CVE 紀錄指出有多種方式能穩定觸發記憶體不足,進而遠端執行程式碼。官方另說明:即使設定 memory_limit=-1,底層真正的記憶體配置失敗仍可能走到這段程式。

有問題的思路(概念示意,不是 PHP 原始程式碼):

req->data = /* 尚未設定 */;
buf = allocate(size);   // 記憶體不足 → 直接跳出,req->data 一直沒設定
req->data = buf;
...
cleanup(req);           // 把 req->data 當成有效資料處理 → 記憶體損壞

較安全的思路(概念示意):

req->data = NULL;       // 在任何可能失敗的配置之前,先設成安全的空值
buf = allocate(size);
req->data = buf;
...
cleanup(req);           // 能辨識空值,不會誤用

修補機制: 依維護者 GHSA 的說明,修補移除了記憶體不足時的 longjmp(),改成在下一個 VM 安全點才觸發的延遲式 soft OOM;超過更高門檻時則用 _exit() 立即結束(hard OOM)。修補 commit 編號 31c0ea7d7ff 出自 JFrog(該頁含攻擊程式,本站不連結)。上面兩段示意碼只是概念說明,不代表 PHP 官方的修法。

根本原因的描述,各來源說法不一: Sansec 把 CVE-2026-109618 歸類為「上傳進度反序列化器的使用已釋放記憶體」,JFrog 則說它把屬於請求的指標存進持久變數;但 PHP 官方對本漏洞的描述是記憶體不足時的半初始化資料,而上傳進度與殘留全域狀態的描述,在官方說法中比較接近另一個漏洞 CVE-2026-109619。本頁採用 PHP 官方的描述。

影響: 維護者 GHSA 表示已確認的影響是不需登入、以網站工作帳號身分遠端執行程式碼。Sansec 另稱此漏洞本身也會洩漏記憶體內容(類似 Heartbleed),官方未確認。

時間軸

延伸閱讀

• 評分差異: 本頁主嚴重度欄位採用 NVD 的 CVSS 3.1 9.8(向量 AV:N/AC:L/PR:N/UI:N),攻擊複雜度「低」。採用理由:NVD 是 CVSS 3.1 的評分機構,且 3.1 是目前最通用的版本,方便與其他漏洞比較。PHP(CNA)的 CVSS 4.0 為 9.2(AC:H/AT:P),認為攻擊複雜度「高」且有攻擊前提條件,同樣有效,請兩者並看。SANS ISC(該頁含攻擊程式,本站不連結)引用 9.4,與官方的 9.2 不同。
• 是否已遭利用,各方說法不一: watchTowr 稱誘捕系統在 10 月 21 日觀察到利用(同一頁面仍有「尚無修補」的過時文字);Aikido 稱有利用報告,但未說明是哪一個 CVE;修補前 SecurityWeek 報導 watchTowr 與 Huntress 尚未看到利用;CISA 的 SSVC 評估(2026-10-21 14:34 UTC)為「none」。截至 2026-10-21,未列入 CISA KEV。
• 公開的概念驗證程式: SANS ISC(該頁含攻擊程式,本站不連結)指出已有概念驗證(PoC)程式與技術細節公開,但它檢視的早期版本看起來並不可靠。本站不連結任何攻擊程式。
• 發現者: 依 Sansec,兩個漏洞由 Calif 的 Ryan Austin、Wiz Research(Sagi Tzadik、Shir Tamari、Nir Ohfeld、Tomer Schwartz)與 OpenAI 發現。
• 相關漏洞:CVE-2026-109619(同一次修補)。相關弱點類型包括:CWE-416、CWE-824、CWE-755、CWE-1325、CWE-1419。