2026 年 10 月 21 日，PHP 官方發布 8.5.12、8.4.27、8.3.36、8.2.35 四個版本，修補兩個嚴重度 9.2（CVSS v4.0，滿分 10）的漏洞，攻擊者不用登入就可能在伺服器上執行程式碼。這次事件被取名為 PHP2Shell。

漏洞本身很嚴重，但更值得注意的是它被發現的方式：至少三個團隊在幾週內各自用 AI 找到同一組漏洞；消息走漏後，又有一家公司只靠一句「PHP 有事要發生」的提示，用 AI 在一個晚上重新找到它。發現變快了，攻擊也跟著變快——官方修補版還沒發布，就已經有人在網路上試著攻擊。

本文整理自 PHP 官方公告與 Wiz、Recorded Future 等資安廠商的公開報告（2026-10-22 查閱）。各方說法有出入的地方會註明來源。

漏洞是什麼

PHP 是很多網站背後的程式語言，WordPress、Drupal、Joomla 這些常見的架站系統都用它。這次的問題出在 PHP 本身，不是某個外掛或網站程式寫錯，所以就算網站程式寫得再小心，只要 PHP 版本有問題，就可能中招。

官方公告列出的兩個漏洞：

  • CVE-2026-109618：記憶體不足（OOM）時的處理流程出錯，導致遠端執行程式碼。
  • CVE-2026-109619：前一個請求留下的狀態沒有清乾淨，被下一個請求拿去用，同樣可能導致遠端執行程式碼。

用白話講：一個網頁請求處理到一半因為記憶體不足被中斷時，PHP 可能留下指向「已經釋放的記憶體」的資料；同一個工作程序接著處理下一個請求時，又把這些殘留的資料當成正常的來用。攻擊者就是設法製造這種狀況，讓伺服器執行他想要的程式碼。

官方的說法有幾個重點：

  • 受影響範圍：所有處理網頁請求的 PHP 安裝都在風險內，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed。
  • PHP 官方認為使用 Apache mod_php 的環境風險最高，已有示範攻擊可以在任何網站程式執行之前就觸發。
  • 官方公告寫明「沒有完整的緩解措施，更新是唯一安全的選擇」。調整 memory_limit、post_max_size、關掉 session.upload_progress.enabled 等設定只能減少特定攻擊路徑，不能讓系統變安全。
  • PHP 8.1 以前的版本官方已經不再更新，安全團隊只為 7.4、8.0、8.1 提供最小的原始碼修補，給自己編譯的人用；其他人要找作業系統發行版或長期支援廠商的修補，或者升級到還有支援的版本。PHP 8.2 也會在 2026 年 12 月 31 日停止支援。

國內警訊：國家資通安全研究院已發布

國家資通安全研究院在 2026 年 10 月 22 日上午發布漏洞警訊，重點如下：

  • 漏洞類型是「使用釋放後記憶體」（Use After Free，程式繼續使用已經歸還的記憶體）；攻擊者只要送出特製的檔案上傳格式（multipart/form-data）請求，不用登入就能在伺服器上執行任意程式碼。
  • 網路上已經出現概念驗證程式（PoC，證明漏洞可被利用的示範程式）。
  • 受影響版本：官方仍支援的 8.5.11、8.4.26、8.3.35、8.2.34（含）以下；已停止維護的 PHP 5.4 到 8.1 所有版本也都受影響。
  • WordPress、Drupal、Joomla、Magento 等內容管理系統底層多半是 PHP，建議盤點後儘速處置。
  • 處置方式：升級到 8.5.12、8.4.27、8.3.36、8.2.35；8.1 以下不會有官方修補，建議儘速升級到仍受支援的版本。

誰找到的：三組人馬，同一個漏洞

依照 Wiz 自己公布的時間軸，他們的研究團隊在 8 月 19 日找到第一個漏洞，隔天在 Drupal 上確認可以不登入就遠端執行程式碼，8 月 21 日在 WordPress 上也確認了，8 月 24 日回報給 PHP 安全團隊。PHP 在 9 月 21 日確認報告、開始修補，10 月 21 日發布。

Wiz 公開了他們用的工具：自家的 Wiz Atlas，加上 Gemini 4 Argon 與 GPT-5.6 Sol 兩個模型。文中提到，AI 幫忙把攻擊程式調整到不同的 PHP 版本、設定與記憶體配置，失敗了也能快速換方法再試；他們的說法是「一個研究員一週做完的事，以前要一組世界級團隊花好幾個月」。

但 Wiz 不是唯一找到的人。PHP 在 GitHub 上的公告列了四個回報者帳號，CVE 紀錄則記載了三個單位：Calif、Wiz 與 OpenAI。根據轉述 Calif 說法的報導，Calif 最早在 8 月初就發現問題，8 月 11 日向 PHP 回報，比 Wiz 早；他們用的是 OpenAI 的模型，沒有特殊的實驗環境，也沒有使用未公開的模型，是由研究人員引導模型去比對過去的漏洞模式。

值得一提的是，官方公告和 CVE 紀錄都沒有寫出用了哪個 AI 模型。CVE 的格式其實有「工具」欄位，但很少被填寫；目前關於 AI 參與的說法，都來自各家公司的部落格和媒體報導。

走漏與搶先：最後一天的混亂

原本的協調揭露時間是 10 月 21 日 14:00（世界標準時間，台灣時間晚上 10 點）。最後幾天發生了幾件事：

  • CVE 編號先流出：漏洞編號在論壇和社群上流傳，附帶錯誤的發布時間和嚴重度，但沒有技術細節。PHP 因此把發布提前一天。
  • 示範影片誤發：據報導，Calif 不小心公開了一段攻擊示範影片，之後撤下。
  • Chainguard 提前發布修補映像檔：容器映像檔公司 Chainguard 聽到研究人員提示「PHP 有事要發生」後，當天晚上就用自家的 AI 工具搭配前沿模型找到同樣的漏洞，並在 10 月 21 日早上 7:41（世界標準時間）發布含修補的映像檔，比協調時間早了六個多小時。PHP 的維護者公開批評這等於打破保密協議：攻擊者可以從修補後的程式反推漏洞在哪裡。Chainguard 執行長 Dan Lorenc 不否認時間軸，但表示公司沒有洩漏任何東西，是自己獨立找到的。

依 Recorded Future 整理的時間軸，一份含漏洞資訊的壓縮檔在 10 月 21 日 02:29（世界標準時間）被上傳到 VirusTotal；07:34 Patchstack 回報多家主機合作夥伴出現實際攻擊事件；13:52 PHP 發布修補版本。也就是說，官方修補還沒出來，攻擊就已經開始了。Cloudflare 也表示觀察到早期的攻擊，並部署了防火牆規則。

AI 讓攻防同時加速

這次事件可以看到幾個趨勢：

  • 找漏洞的門檻變低：同一組藏在 PHP 核心多年的漏洞，三組人馬在幾週內各自找到，第四家公司拿到一句提示就在一個晚上找到。以前要大量專業人力和時間才做得到的事，現在有 AI 協助可以快很多。
  • 從找到到能攻擊的時間變短：Wiz 的描述是 AI 幫忙把攻擊程式改寫到各種環境，失敗也能快速重試。防守方能用，攻擊方當然也能用。
  • 「保密到修補發布」越來越難：只要知道大概的方向，就有人能用 AI 很快重現。編號、影片、提前出現的修補檔，任何一點線索都可能讓攻擊者搶先。
  • 紀錄跟不上：誰先找到、用了哪個模型、人做了多少，官方紀錄沒有寫清楚，只能看各家公司自己的說法。

另一面是，防守方也在用同樣的工具。Wiz 提到 AI 也參與了偵測攻擊與驗證修補；Cloudflare 等網路服務商能在修補發布前就部署防火牆規則。對一般網站管理者來說，結論很簡單：修補的速度要跟得上，從「有空再更新」變成「公告當天就更新」。

網站管理者現在該做的事

  • 先確認自己有沒有用 PHP：用 WordPress 等架站系統、租用虛擬主機，幾乎都有用到。純靜態網站（例如部署在 GitHub Pages、Cloudflare Pages、只有 HTML／CSS／JavaScript 的網站）沒有 PHP，不受這次漏洞影響。
  • 查版本：在伺服器上執行 php -v，或到主機控制台查看 PHP 版本，確認是否已更新到 8.5.12、8.4.27、8.3.36、8.2.35 或更新。
  • 更新後要重新啟動：PHP-FPM、Apache 都要重新啟動，新版本才會生效。
  • 容器要重建：用 Docker 跑的 WordPress、LibreNMS、GLPI 等服務，要拉新的映像檔重建容器，只更新主機上的 PHP 沒有用。
  • 虛擬主機找業者：自己沒有權限更新時，請主機商確認是否已更新，或在控制台切換到新版本。
  • 還在用 8.1 以前（含 PHP 5.4～7.x）：同樣受影響，找作業系統或長期支援廠商的修補版本，或盡快升級。
  • 沒對外開放也要更新：只在內部網路使用的服務，一旦內網有其他裝置被入侵，一樣可能被拿來攻擊。
  • 看紀錄有沒有異常：資安廠商提醒可以留意 10 月 20 日以後的紀錄，例如大量 500 錯誤、記憶體不足的錯誤、異常大的 PHPSESSID cookie、PHP 工作程序不明原因地反覆重啟。

小結

PHP2Shell 是一個很嚴重的漏洞，但它更像是一個訊號：AI 讓找漏洞、寫攻擊程式、重現漏洞的速度都大幅提高，從發現到被攻擊的時間正在縮短。對防守方來說，能做的就是把「更新」這件事做得更快、更有系統：知道自己有哪些服務、用了哪些版本，公告出來當天就能處理。

參考來源