PHP 核心兩個 RCE 在修補前外洩,
六成對外主機沒有官方修補版可裝

速讀:5 分鐘掌握重點

為什麼現在很紅:PHP 官方只說「兩個 9.2 分的重大漏洞、明天修」,社群卻已經知道編號、知道是 RCE、還看到一張攻擊工具截圖;修補隔天出來了,但全球近 88 萬台對外主機跑的版本,官方沒有出修補版。

一句話結論
10 月 20 日官方預告只寫了三件事:兩個重大漏洞、都是 CVSS v4.0 9.2、10 月 21 日 14:00 UTC 釋出修補。編號 CVE-2026-109618/109619 與「PHP 核心的遠端程式碼執行」,先是從禁運期前外洩的貼文流出、再由 watchTowr 證實。
他要的是什麼
他原本在等修補程式碼,結果研究文章和攻擊工具都公開了,連比對新舊版本都省了。接下來只是把全網掃一遍,挑那些還沒更新、或永遠不會更新的主機。沒有官方修補版的 88 萬台,對他來說是一份沒有期限的清單。
你今天做一件事
修補已經出來,而且野外已有攻擊:8.2 以上現在就更新到 8.5.12、8.4.27、8.3.36、8.2.35,mod_php 先做;8.1 以下今天就決定是限制存取、下線,還是排升級。更新完再看一次網頁根目錄有沒有多出來的 .php 檔。 直接去做 →
哪些能信
4 可證明2 推論3 缺口 每個主張都標了等級,缺口是誠實寫出來的。
破口速查
受害端一律去識別化;寫「未公開」代表公開資料查不到。
伺服器服務商
不限雲。Mallory 依 Shodan 統計,回報 PHP 的對外主機最多在 Amazon(約 29 萬台)、Hostinger、Alibaba Cloud、Hetzner、DigitalOcean、OVH;台灣的主機數與占比未公開
網路服務商
不適用(漏洞在 PHP 直譯器本身,與網路服務商無關);共享主機一個 IP 可能掛很多個網站
漏洞出現的地方
PHP 直譯器核心的請求生命週期(官方 2026-10-21 安全公告):記憶體不足時請求資料只初始化一半(CVE-2026-109618),以及請求擁有的內部狀態在記憶體釋放後殘留到下一個請求(CVE-2026-109619)。前提:以 PHP 處理網頁請求,PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed 全部在內;不需要登入,官方認為 mod_php 風險最高,攻擊在任何應用程式碼執行前就能觸發
馬上自我檢測
php -v(並對照網頁實際用的那個 PHP,不是只看 CLI) ps -eo comm,args | grep -E 'php-fpm|php-cgi|apache2|httpd' | grep -v grep dpkg -l | grep -E 'php[0-9.]*-(fpm|cgi|cli)|libapache2-mod-php'(RHEL 系用 rpm -qa | grep -i php)
漏洞修補方式
官方說法:更新到 8.5.12、8.4.27、8.3.36 或 8.2.35,這是唯一完整的解法。發行版已提前拿到修補(Debian DSA-6574-1/DLA-4848-1、Ubuntu USN-8948-1/-2),用套件裝的以發行版公告為準;Remi 套件庫當天不會更新,官方建議改用發行版套件或自行編譯。8.1 以下沒有官方修補版,官方破例在 php-src 放了 7.4、8.0、8.1 的最小化原始碼回移分支,Ubuntu Pro 另有舊版回移;PHP 5 等更舊版本只能升級、限制存取或下線。來不及更新時,官方列了只能降低特定路徑的暫時措施:memory_limit=-1、調低 post_max_size、session.upload_progress.enabled=0(8.5 另加 fatal_error_backtraces=0),都要在請求解析前生效並重啟 worker
有 15 分鐘再看:其餘 2 點
  1. (2026-10-22 更新)10 月 21 日官方釋出 8.5.12、8.4.27、8.3.36、8.2.35 與安全公告,正式確認兩個編號、不需登入的遠端程式碼執行,以及 PHP-FPM、mod_php、php-cgi 等全部網頁執行模式都受影響。watchTowr 回報 10 月 21 日起蜜罐已觀察到野外利用;研究文章與攻擊工具已公開。
  2. 結構性問題是版本:PHP 官方只修 8.2 以後。Mallory 依 Shodan 統計,約 150 萬台回報版本的對外主機裡,883,717 台(59%)跑 8.1 以下,沒有官方修補版可裝(官方只給了 7.4 到 8.1 的最小化原始碼回移,要自己編譯)。台灣大量的 WordPress、WooCommerce、共享主機與十年前的 PHP 5/7 舊站,就在這一群裡。

PHP 官方 10 月 21 日釋出 8.5.12、8.4.27、8.3.36、8.2.35,修補兩個 CVSS v4.0 9.2、不需登入就能遠端執行程式碼的漏洞。編號與「RCE」先在禁運期結束前外洩,官方隔天才正式確認;資安公司也回報修補釋出前後已有野外攻擊。真正麻煩的是另一個數字:依 Shodan 統計,回報版本的對外 PHP 主機有 59% 跑 8.1 以下,沒有官方修補版可裝。(2026-10-22 更新)

PHP 核心 CVE-2026-109618/CVE-2026-109619 禁運期前外洩,官方提前一天釋出 8.5.12/8.4.27/8.3.36/8.2.35·2026-10-20 15:20 UTC Hacker News 外洩貼文 → 同日 PHP 官方預告、watchTowr 證實 → 2026-10-21 釋出修補與安全公告(GitHub 公告 13:34 UTC 公開,原訂協調揭露為 10-22)→ 同日資安公司回報野外攻擊、Debian/Ubuntu 出修補·全文 9 分鐘
本篇目錄

發生了什麼

想像一家鎖匠公會發通知:「我們的鎖有兩個嚴重問題,明晚十點發新鎖芯,請大家準備換。」通知只寫了這幾句。可是前一天下午,論壇上已經有人貼出問題的編號、說這兩個問題「隨便一把都能打開」,還附上一張據說是開鎖工具的截圖。更麻煩的是,公會只替最近四代的鎖出新鎖芯;全世界還掛在門上的鎖,有六成是更老的型號,不會有新鎖芯。這篇把 PHP 這次的事拆開來看:官方說了什麼、外洩的部分有多可信,以及你今晚之前能做什麼。

本文 2026-10-22 更新:PHP 官方已於 10 月 21 日釋出修補與安全公告,正式確認了原本只來自外洩與資安公司的編號與漏洞類型;資安公司也回報已有野外攻擊。時間軸、證據等級、修補版本與「如何避免」都已依官方公告改寫,新進展整理在文末的「後續」。

2026 年 10 月 20 日,PHP 安全團隊在 php.net 與 ANNOUNCE 郵件列表發布預告:將在 10 月 21 日 14:00 UTC(台灣時間 22:00)釋出安全更新,修補兩個重大漏洞,兩者都是 CVSS v4.0 9.2;並保留「若任一漏洞細節公開、或出現野外利用跡象時提前釋出」的權利。完整細節、受影響版本與修補版本,會隨版本一起公布。

先講清楚這份第一手文件的性質。這是一則預告,不是安全公告。它沒有 CVE 編號,沒有「遠端程式碼執行」這幾個字,也沒有寫影響哪些版本。下面所有關於編號、漏洞類型、版本範圍的說法,都來自外洩的貼文與資安公司,本篇會一條一條標出來源與證據等級。

PHP 官方預告重點(php.net news archive,2026-10-20)READ-ONLY
Upcoming Critical PHP Security Release

- 排定時間:2026-10-21(三)14:00 UTC
- 內容:修補兩個 critical 漏洞,兩者皆為 CVSS v4.0 9.2
- 建議:所有 PHP 使用者現在就準備,版本一出就升級
- 保留:若任一漏洞細節公開、或野外出現利用跡象,可能提前釋出
- 完整細節、受影響版本與修補版本,隨版本一併公布

(公告中沒有 CVE 編號,也沒有說明漏洞類型)

把公開資料排成一條線,時間以 UTC 為準,台灣時間加 8 小時。

  1. 2026-10-20 15:20 UTC
    Hacker News 出現一則貼文,宣稱兩個 CVSS 10.0 的 PHP RCE 將於 10-22 揭露、影響 PHP 5 以後所有版本,並列出 CVE-2026-109618 與 CVE-2026-109619;貼文隨後被刪,截圖在 X 與 Mastodon 流傳
    BleepingComputer 看過貼文;Sansec 與 Cyber Kendra 時間軸
  2. 2026-10-20 下午
    watchTowr 在 X 證實外洩內容屬實,向 BleepingComputer 表示原訂禁運到美東時間 10-22(四)11:00,並稱已重現 CVE-2026-109618;技術細節在修補前不公開
    BleepingComputer 2026-10-20 報導引述 watchTowr 執行長
  3. 2026-10-20
    PHP 官方發布預告:10-21 14:00 UTC 釋出修補,兩個漏洞皆 CVSS v4.0 9.2,保留提前釋出權利
    php.net news archive;BleepingComputer 稱 ANNOUNCE 郵件列表同步發出
  4. 2026-10-20
    Sansec 指出隨外洩流出一張名為 PHP2Shell 的工具截圖,署名 Calif.IO,橫幅宣稱可用於 PHP 5.4.0 以後所有版本;截圖真偽未經官方確認
    Sansec research:PHP2Shell
  5. 2026-10-20 19:35 UTC
    watchTowr 發布 FAQ:未觀察到野外利用、未列入 CISA KEV、修補前沒有已確認的緩解方式
    watchTowr FAQ(10-21 更新仍維持)
  6. 2026-10-20 22:15 UTC
    Mallory 發布曝險分析:約 150 萬台回報版本的對外 PHP 主機中,883,717 台(59%)跑 8.1 以下、不會有官方修補;並列出預期的修補版本 8.5.12、8.4.27、8.3.36、8.2.35
    Mallory 部落格(Shodan 2026-10-20 計數);修補版本號官方尚未公布
  7. 2026-10-21 上午(台灣時間,本文撰寫時)
    php.net 首頁最新版本仍為 8.5.11、8.4.26、8.3.35、8.2.34,修補版尚未上線
    本站直接讀取 php.net 首頁
  8. 2026-10-21 07:43 UTC(台灣 15:43)
    Cloudflare 回報觀察到早期攻擊,早於原訂 14:00 UTC 的修補釋出
    Sansec 2026-10-21 更新引述 Cloudflare;本站未取得 Cloudflare 原始公告
  9. 2026-10-21
    watchTowr 的 Attacker Eye 蜜罐網路觀察到野外利用
    watchTowr FAQ 2026-10-22 更新
  10. 2026-10-21 13:34 UTC(台灣 21:34)
    GitHub 公開兩份安全公告 GHSA-w8hw-w9fx-j79w(CVE-2026-109618,RCE via OOM corruption)與 GHSA-6wmf-4rv5-p3rp(CVE-2026-109619,RCE via stale global state),兩者皆 critical、CVSS v4.0 9.2,修補版本 8.2.35、8.3.36、8.4.27、8.5.12
    GitHub php-src security advisories
  11. 2026-10-21
    php.net 發布四個修補版本與安全公告:不需登入即可遠端執行程式碼,所有處理網頁請求的 PHP 都在範圍內,mod_php 風險最高;破例提供 7.4、8.0、8.1 的最小化原始碼回移;Remi 套件庫當天不會更新
    php.net news archive 2026-10-21 的五則公告
  12. 2026-10-21
    Debian 發布 DSA-6574-1(trixie php8.4 → 8.4.27)與 DLA-4848-1(bookworm php8.2 → 8.2.35);Ubuntu 發布 USN-8948-1/-2,24.04 的 php8.3、22.04 的 php8.1 已修,更舊的 php5/7.x 經 Ubuntu Pro 提供回移
    Debian Security Tracker、Ubuntu CVE 頁
  13. 2026-10-21
    研究揭露頁 php2shell.com 上線,列出 Wiz Research、OpenAI Codex Security 與 Calif 為發現與揭露者;Sansec 轉述 Calif 示範了對 Magento、WordPress、Drupal、Joomla、MediaWiki、phpMyAdmin、Nextcloud 等 11 種應用的未驗證遠端執行
    php2shell.com;Sansec 2026-10-21 更新
  14. 未公開
    外洩源頭是誰、野外攻擊規模與受害者、台灣有多少主機還沒更新
    截至 2026-10-22,官方與研究者皆未公開;CISA KEV 截至本站查詢時尚未列入

從外洩貼文到官方決定提前,前後不到半天;原本的協調揭露日是 10 月 22 日,官方把它拉前了一天。而依 Cloudflare 與 watchTowr 的回報,攻擊者沒有等到修補釋出。

怎麼發現

這次不是誰「發現」了攻擊,而是協調揭露的流程漏了氣。正常的順序是:漏洞回報給 PHP,PHP 私下修好,同時通知 Linux 發行版、主機商與資安公司準備,到了約定時間,修補程式與公告一起出來。這段私下準備的窗口叫禁運期(embargo),目的是讓防守方拿到修補的那一刻,攻擊者才第一次知道有洞。

這次順序反了。編號、嚴重度、影響範圍先在 Hacker News 與社群上流傳,官方才被迫發預告、把時間提前。Cyber Kendra 的說法很直接:日期與嚴重度一外洩,任何手上本來就握有這兩個漏洞的人,都知道自己還剩多少時間。防守方這邊,知道「有東西要修」,卻不知道該防什麼。

攻擊者怎麼做到

到這裡,其實已經足夠理解整起事件。如果你關心的是該怎麼避免,可以直接往「如何避免」繼續閱讀。如果你想知道公開資料能還原到哪一步,下面開始進入技術拆解。

白話結論:官方公告與研究文章已經公開了漏洞機制,本站只寫到機制的層級,不寫觸發方式。公開資料能說的,是洞在哪一層、誰在範圍內,以及被打穿之後通常長什麼樣子、防守方該盯哪裡。

「核心 RCE」和「WordPress 外掛漏洞」差在哪裡

過去台灣中小企業最常遇到的 PHP 事件,大多出在應用層:某個 WordPress 外掛、某個佈景主題、某支自己寫的上傳程式。那種洞只影響用了那個外掛的站,修法是更新外掛。

這次不同。依 watchTowr 與研究者 Florian Roth 的說法,洞在 PHP 直譯器核心。核心是所有 PHP 程式底下共用的那一層,所以影響範圍不看你跑的是 WordPress、Drupal、Magento、WooCommerce,還是十年前外包寫的會員系統。Sansec 也明講:這要在基礎設施層更新 PHP 才修得掉,從商店程式碼裡修不了;它們家的應用層防護規則,也可能在攻擊碰到商店程式碼之前就被繞過。

攻擊需要什麼前提,10 月 21 日的官方公告回答了:不需要登入。兩個洞都在 PHP 處理每一個請求的初始化與清理邊界上,一個是記憶體不足時請求資料只初始化了一半、清理時卻被當成有效資料,另一個是上一個請求的內部狀態在記憶體釋放後殘留下來、被同一個 worker 的下一個請求用到。所以官方說所有處理網頁請求的 PHP 都在範圍內,PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed 都算,其中 mod_php 風險最高,已有實證的攻擊可以在任何應用程式碼執行之前觸發。這也印證了 Huntress 研究者在修補前對「php2shell」這個名字的解讀(經 CyberQ 轉述):送一個請求就能拿到 shell、不需要先登入。

深入閱讀對照 MITRE ATT&CK:四格裡只有第一格有官方文字入口已由官方公告說明;後續行為與最終損失仍沒有公開的受害案例
發生了什麼 · MITRE ATT&CK T1190
官方 2026-10-21 安全公告:PHP 核心的未驗證遠端程式碼執行,所有處理網頁請求的 SAPI 都受影響,mod_php 風險最高。watchTowr 回報 10-21 起已有野外利用;攻擊者用的具體請求樣式未公開。
當時留下的訊號
對外 PHP 主機出現大量相同樣式的異常請求,或 worker 異常大量吃記憶體、崩潰重啟;WAF 與存取紀錄先留好。
能擋下它的控制
8.2 以上立即更新;8.1 以下限制存取或下線;清點所有對外 PHP 主機。

第一格現在有官方文字了,後三格仍標缺口:已有野外利用的回報,但攻擊者打進去之後做了什麼,還沒有公開的受害案例。能做的是先把會看到的訊號準備好。

這次外洩了什麼

這次「外洩」的不是任何人的資料或憑證,而是漏洞資訊本身。表格第一列是已經發生的外洩,其餘幾列是:如果你的主機被打穿,放在上面的哪些東西會跟著出去。

leaked credentials這次外洩了什麼:服務、用途、存在形式
服務憑證類型用途存在形式放在哪權限範圍狀態
PHP 協調揭露流程漏洞資訊:CVE 編號、嚴重度、影響範圍說法、揭露日期,以及一張攻擊工具截圖原本只在禁運期內給 PHP、發行版與合作方準備修補社群貼文與截圖(Hacker News 貼文已刪,截圖仍在 X、Mastodon 流傳)公開網路全球所有 PHP 使用者都受影響;技術細節在禁運期內沒有外洩,10-21 才隨官方公告與研究文章公開官方提前一天釋出修補
你的 PHP 網站(若遭利用)資料庫帳密(wp-config.php、.env、config.php 裡的明文)網站連資料庫設定檔明文網頁根目錄或其上一層以網頁程序的權限就讀得到;野外已有利用回報,但受害者與被拿走的內容無公開資訊未知
同上第三方 API 金鑰(金流、簡訊、寄信、雲端儲存、AI 服務)網站呼叫外部服務設定檔或環境變數同一台主機同上未知
同上(雲端主機)雲端執行身分的暫時憑證(例如 EC2 掛的 IAM Role)主機存取雲端資源執行個體中繼資料服務雲端主機本身若主機有掛角色,打穿網站就可能拿到雲端權限;本站 INC-2026-0915 那台剛好沒掛,擴散才停在主機未知
憑證本身已遮蔽或失效;這裡只說明它是哪個服務、拿來做什麼、以什麼形式存放,讓你能對照自己的環境。

後三列標缺口,因為它們描述的是「被打穿之後」的後果,不是已經發生的事;但這三列決定了你被打穿時損失有多大,現在就可以先盤。

證據等級

這篇的證據結構很特別:官方說得最少,外洩與第三方說得最多。下面把它們分開。

他們怎麼處理

照官方與研究者的公開動作排一次。PHP 安全團隊在外洩後的同一天發預告、把釋出時間從原訂的 10 月 22 日拉到 21 日,並保留再提前的權利;預告刻意不給任何技術線索,連編號都沒寫。watchTowr 在證實外洩屬實的同時,明說在修補釋出前不公開技術細節;Mallory 回頭翻了 php-src 最近的提交與 PR,說沒有任何東西能對上這兩個 CVE,因為禁運期的修補是私下開發的。

10 月 21 日的釋出也比 PHP 平常的做法多做了幾步:發行版與長期支援廠商事先拿到修補,所以 Debian、Ubuntu 同一天就有套件;官方破例替已經停止支援的 7.4、8.0、8.1 放了最小化原始碼回移;並明講志工維護的 Remi 套件庫當天不會更新,請依賴它的人改用發行版套件或自行編譯。安全公告裡還列了沒辦法馬上更新時的暫時措施,每一項都附上「只擋已確認路徑」的但書。

防守方能拿到的工具在修補前一天就出來了。Mallory 與 Sansec 給了清單;Florian Roth 為這次事件寫了 process-watcher 的快速設定說明,讓沒有 EDR 的 Linux 網頁主機也能看到 PHP 程序啟動了哪些程式;Huntress 表示會在修補前先記錄客戶端點上 PHP 的正常行為,細節公開後再比對。

哪裡做對,哪裡做錯

做對的地方,是官方在禁運破功後的反應。不硬撐原訂時間,提前一天;預告只講防守方需要的資訊(多嚴重、什麼時候、準備好),不給任何攻擊者用得上的細節;並預留「再提前」的空間。研究者這邊也守住了底線:證實真假、不公開細節,同時把防守方能做的事寫成清單。釋出當天,官方破例替停止支援的分支給原始碼回移,也把暫時措施的極限寫清楚,沒有讓人以為改個設定就安全。

該檢討的有兩層。第一層是流程:禁運期的資訊在約定日前兩天就外洩,連同一張攻擊工具截圖,代表知道細節的圈子不夠小,或其中有人不守約。第二層更大,而且不是 PHP 團隊能解決的:全球六成對外 PHP 主機跑的是官方不再修的版本。開源專案只維護幾個分支是合理的,但這代表每一次核心漏洞,都會留下一大群永遠等不到修補的主機。這是使用者端的技術債,這次只是把帳單一次攤開。

如何避免

這一節寫給台灣中小企業與接案團隊:有官網、有購物車、有內部系統,但不一定有專職維運的人。

第一件事還是盤點。把每一台跑 PHP 的機器列出來,包括官網、購物車、會員系統、內部報表,也包括廠商設備與 Windows 軟體裡內嵌的 php.exe 或 php-cgi.exe、cPanel 或 Plesk 這類主機控制台。每一台記下三件事:PHP 版本、執行模式(PHP-FPM、Apache mod_php、php-cgi)、對不對外。版本要看網頁實際用的那一支,不要只看命令列 php -v;同一台機器上命令列和網頁用的常常是不同版本。

接著依版本分流。8.2 到 8.5:現在就更新到 8.5.12、8.4.27、8.3.36、8.2.35,mod_php 與對外的先做;用 apt、dnf 安裝的,以 Debian、Ubuntu、RHEL 的安全公告為準,不要只對 php.net 的版本號;用 Remi 套件庫的,官方建議改用發行版套件或自行編譯。共享主機或代管的:今天就寫信給主機商,問他們更新了沒、你在哪一個版本上。8.1 以下:沒有官方修補版。7.4、8.0、8.1 有官方的原始碼回移分支,Ubuntu 舊版可以走 Ubuntu Pro,但這些都只修這兩個漏洞;長期還是要升級。不能馬上處理的,先用 VPN、IP 允許清單或 WAF 限制誰能連;只是展示用、早就沒人用的舊站,最好的處理是今天就下線。官方列的暫時措施(memory_limit=-1、調低 post_max_size、在 php.ini 或 FPM pool 關閉 session.upload_progress 並重啟所有 worker、8.5 另關 fatal_error_backtraces)可以爭取時間,但官方自己說只擋已確認的路徑,而且 memory_limit=-1 會讓單一請求吃光記憶體,要盯著記憶體用量,更新完就改回來。

這一週要補的是偵測。不論漏洞細節最後是什麼,網頁程序被打穿時最常見的痕跡,是 php-fpm、php-cgi 或 Apache 底下冒出 shell、python、curl、wget 之類的子程序。有 EDR 的,確認這條規則有開、告警有人看;沒有的,可以用 process-watcher 這類工具先以觀察模式記錄,攔截功能等觀察一陣子再決定。因為修補釋出前後已有野外利用的回報,修補之後一定要再檢查一次網頁根目錄有沒有新的 .php 檔、有沒有新的排程與帳號;更新前就已經對外的主機,要當作可能已經被打過。

這一季要處理的是根本:把 8.1 以下的主機列進風險清冊,每一台寫上負責人、升級期限,以及在升級前用什麼補償控制。8.2 的安全支援也只到 12 月 31 日,現在跑 8.2 的,升級計畫要一起排。

這篇提到的項目要花多少錢

PHP 本身與修補都免費;這次真正的成本是人力、停機與舊站搬遷。下表除了開源軟體的價格,其餘都是本站的估算或對照。

cost現在更新一次,和舊站繼續放著,各要花多少
項目用量單價期間US$NT$舉證
PHP 修補版本身每台主機開源,US$0一次0.000php.net 免費下載;發行版套件同樣免費
8.2 以上主機的緊急更新工時
估:自己有維運人員的情況;夜間加班費另計
假設 5 台,每台 1 小時(含更新、重啟、驗證)估 NT$1,000/工時一次156.004,992本站估算
全面盤點 PHP 安裝點(含設備與內嵌 PHP)
估:主機越分散、文件越少,時間越長
假設 1 人 × 1 天估 NT$5,000/人日一次156.004,992本站估算
PHP 5/7 舊站升到 8.2 以上(程式相容性修改與測試)
估:落差很大;用 WordPress 且外掛都有維護的站通常少很多,十年前外包的自製系統可能更多
假設 1 個中型自製系統,5–15 人日估 NT$5,000/人日一次7802340.00249,674,880本站估算
process-watcher(Linux 網頁主機的子程序觀察)
需要 root、Linux kernel 5.15 以上;人力另計
每台主機開源,US$0持續0.000process-watcher 專案 README
暫時下線或限制存取的業務損失依網站營收而定—升級完成前——無法通用估算
主機商或發行版的舊版本延伸支援
有些發行版的長期支援或商業延伸支援會回移修補,價格與是否涵蓋本次漏洞要問各家
8.1 以下需要回移修補時依各家方案每年——Mallory 與 Sansec 提到回移可能性;價格無公開資料可對
對照:被打穿後的平均總成本
對照用,不是本次事件的金額
全球受訪組織平均US$4.44M/起2025 年度報告——IBM Cost of a Data Breach Report 2025
合計(僅可證明列)0.000
匯率假設 1 USD ≈ NT$32。單價為公開牌價或帳單實付,來源:php.net、process-watcher 專案頁、IBM 2025 報告、本站估算(2026-10)。「舉證」欄標明每筆損失的證據來源與等級( 可證明 推論 缺口)。

這張表要看的是第二列和第四列的差距:更新一台 8.2 以上的主機,是一小時的事;一台 PHP 5 的舊站,在這次之後每一個核心漏洞都會再欠一次。

你可以學到什麼

站在攻擊者那一側看,原本 10 月 21 日 22:00 是發令槍:修補程式一公開,新舊版本的差異就是一張藏寶圖。實際上有人沒等槍響,依 Cloudflare 與 watchTowr 的回報,修補釋出前後就已經有攻擊;而研究文章與攻擊工具公開之後,連比對都省了。對 8.2 以上、當天就更新的主機,他只有幾個小時的窗口;對那 88 萬台官方不修的主機,窗口沒有關閉的那一天。他不會挑最難打的那台,他會挑最舊的那台。

跟我們的防暴筆記對照

對照 INC-2026-0915(「關機前套用更新」這支程式,跑了 17,613 分鐘)。

相同的地方有兩個。一是入口:0915 是一支對公網開放的網頁程式,使用者的輸入進了系統指令,遠端就能執行任意指令;這次是 PHP 核心的遠端程式碼執行。層級不同,但結果是同一種:網頁程序替攻擊者跑程式。二是「沒人在看的舊東西」:0915 那台主機在業務停掉之後沒人登入,攻擊者挖礦 356 天才被發現;這次那 88 萬台跑 8.1 以下的主機,很多也是同樣的處境,網站還開著,但沒人記得它在那裡。

不同的地方在於修法。0915 的洞在我們自己的程式碼裡,修程式就能關;這次的洞在 PHP 本身,自己的程式碼寫得再好也沒用,只能更新直譯器,而舊版本連更新都沒有。0915 給的另一個教訓這次直接用得上:那次我們是看到「網頁程序底下有不該出現的子程序」才順藤摸瓜,這正是 Florian Roth 與 Huntress 這次建議盯的訊號。

攻擊者這幾天的盤算
  • 研究文章與攻擊工具都已公開,照著寫掃描器就好,不用自己挖漏洞。
  • 先掃 8.1 以下的主機,它們永遠不會更新,不用搶時間。
  • 打穿網頁程序之後,先讀設定檔裡的資料庫帳密與 API 金鑰,再看主機有沒有掛雲端角色。
  • 放一個 web shell,就算主機之後更新了也還能回來。
lessons本案的 4 個教訓
  1. 01
    禁運期外洩時,防守方先拿到的是時間表,不是修補。這段時間能做的只有盤點與準備偵測,所以平常就要有一份隨時能拿出來的對外主機清冊。
  2. 02
    核心漏洞的影響範圍不看你用哪一套應用程式。WordPress、自製系統、廠商設備裡內嵌的 PHP,全部都要算進來。
  3. 03
    官方只修受支援的分支。跑 EOL 版本不是「比較舊」,而是每一次核心漏洞都等不到修補;這筆技術債要列進風險清冊,寫上負責人與期限。
  4. 04
    官方預告說得少,不代表外洩的內容都對。分數以官方 9.2 為準,修補版本號以官方公告為準,在官方細節公布前,不要依未證實的說法大改設定。
keywords重點學習:最需要學習的 10 個關鍵字10 個
  1. 01
    RCE(Remote Code Execution,遠端程式碼執行)
    攻擊者從遠端讓你的伺服器執行他的程式;官方 10-21 公告確認這次兩個都是這一類,而且不需要登入。
  2. 02
    禁運期(embargo)
    漏洞修好到公開之間的私下準備窗口;這次在約定日前兩天就外洩。
  3. 03
    協調揭露(coordinated disclosure)
    修補與公告同時發布、讓防守方先拿到修補的流程;這次順序反了。
  4. 04
    EOL(End of Life,停止支援)
    官方不再修補的版本;PHP 8.1 以下都是,Mallory 估計占對外主機 59%。
  5. 05
    CVSS v4.0
    官方給的 9.2 用的是這一版;外洩貼文的 10.0 沒說用哪一版,以官方為準。
  6. 06
    SAPI(PHP-FPM、mod_php、php-cgi)
    PHP 跟網頁伺服器接在一起的方式;官方說全部都受影響,mod_php 風險最高,盤點時要記下來排優先順序。
  7. 07
    backport(回移修補)
    發行版把新修補移到它們維護的舊版本套件;看到舊版本號不一定代表沒修,以發行版公告為準。
  8. 08
    patch diffing(修補比對)
    攻擊者比對新舊版本找出洞在哪;這是修補一出、掃描就跟著來的原因。
  9. 09
    web shell
    放在網頁目錄、讓攻擊者之後還能回來的程式;修補後要檢查有沒有新檔案。
  10. 10
    子程序告警(child process alerting)
    網頁程序底下冒出 shell 或下載工具,是被打穿最常見的痕跡,不需要先知道漏洞細節。
try today今天就可以來試試約 15 分鐘

全部唯讀,不改任何設定;做完你會知道自己有沒有同樣的破口。

  1. 列出這台主機上正在跑的 PHP 執行模式(唯讀)
    ps -eo comm,args | grep -E 'php-fpm|php-cgi|apache2|httpd' | grep -v grep
    看到什麼代表什麼:看到 php-fpm: master process 或 php-fpm8.3 這類字樣代表 PHP-FPM;只有 apache2/httpd 而沒有 php-fpm,多半是 mod_php;出現 php-cgi 要特別記下來。每一台的結果抄進資產清冊。
  2. 查 PHP 版本,命令列與套件各看一次(唯讀)
    php -v
    dpkg -l | grep -E 'php[0-9.]*-(fpm|cgi|cli)|libapache2-mod-php'
    rpm -qa | grep -i php
    看到什麼代表什麼:主版本是 8.2 到 8.5:低於 8.5.12、8.4.27、8.3.36、8.2.35 的現在就更新。8.1、8.0、7.4:沒有 php.net 修補版,只有原始碼回移分支;7.3 以下與 5.x 什麼都沒有,今天就決定限制存取、下線或排升級。dpkg 或 rpm 顯示的套件版本,之後拿去對發行版的安全公告。命令列的 php -v 和網頁用的版本可能不同,以套件與 FPM 版本為準。
  3. 從外面看你的網站有沒有自己報版本(唯讀)
    curl -sI https://www.yoursite.com.tw/ | grep -i x-powered-by
    看到什麼代表什麼:出現 X-Powered-By: PHP/7.4.33 這種字樣,代表 Shodan 這類掃描器也看得到你的版本,你就在 Mallory 那張表裡。藏起版本(expose_php = Off)可以少被點名,但不是修補,不要因此延後更新。
  4. 找出主機上所有 php-cgi 與內嵌的 PHP(唯讀)
    find / -xdev -type f \( -name 'php-cgi*' -o -name 'php' -o -name 'php[0-9]*' \) -perm -u+x 2>/dev/null
    看到什麼代表什麼:除了系統套件的位置(/usr/bin、/usr/sbin),任何在 /opt、廠商軟體目錄、舊專案資料夾裡的 PHP 執行檔,都是盤點時容易漏掉、更新時也不會跟著更新的那一支。Windows 主機在檔案總管搜尋 php-cgi.exe 與 php.exe。
  5. 看一眼 PHP 程序底下現在有沒有子程序(唯讀)
    ps -eo pid,ppid,user,comm,args --forest | grep -A3 -E 'php-fpm|php-cgi' | grep -v grep
    看到什麼代表什麼:正常情況下,PHP 程序底下只有它自己的 worker。看到 sh、bash、python、perl、curl、wget、nc 掛在 php-fpm 或 php-cgi 底下,先截圖存證、不要急著砍,交給負責的人判斷。要長期盯,就把這條規則做成告警,命名為 alarm-phpfpm-spawn-k7,跟其他主機告警放在同一個頻道,今晚更新前後各看一次。
  6. 記下網頁根目錄目前的 .php 檔清單,當作修補後比對的基準(唯讀)
    find /var/www -type f -name '*.php' -newermt '2026-10-14' -ls 2>/dev/null | sort -k11
    看到什麼代表什麼:最近一週內新增或改過的 .php 檔,如果不是你們自己部署的,要追。把這份清單存下來,修補後再跑一次,多出來的檔案就是要先看的。網頁根目錄不在 /var/www 的,換成實際路徑。

後續(2026-10-22)

10 月 21 日,PHP 官方照預告釋出 8.5.12、8.4.27、8.3.36、8.2.35 與安全公告,GitHub 上的兩份公告在 13:34 UTC(台灣 21:34)公開。官方確認了外洩內容裡的編號與漏洞類型:兩個都是不需登入的遠端程式碼執行,洞在 PHP 處理請求的初始化與清理邊界,所有處理網頁請求的 PHP 都在範圍內,mod_php 風險最高。分數維持 CVSS v4.0 9.2,外洩貼文說的 10.0 不對。

同一天,Debian 與 Ubuntu 出了修補套件;官方破例替 7.4、8.0、8.1 放了最小化原始碼回移,但 PHP 5 與 7.0 到 7.3 仍然沒有。研究揭露頁 php2shell.com 列出 Wiz Research、OpenAI Codex Security 與 Calif 為發現與揭露者。最壞的預測也成真了:watchTowr 回報 10 月 21 日起蜜罐已觀察到野外利用,Sansec 引述 Cloudflare 說最早的攻擊比原訂釋出時間早六個多小時。

所以這篇原本「今晚之前先盤點」的建議,現在改成兩件事:還沒更新的立刻更新,已經對外跑了一陣子的主機,要當作可能被打過,去查網頁根目錄的新檔案、PHP 程序底下的子程序,以及新的排程與帳號。

回到那間鎖匠公會

公會說明晚十點發新鎖芯,新鎖芯也照時間發了。換得到新鎖芯的人,現在換掉就好;麻煩的是那六成掛著老型號的門,公會只給了其中幾款一份自己動手改的圖紙,更老的什麼都沒有,而開鎖的人在新鎖芯發出來之前就已經上門了。

不需要等任何公告才能做的事情一直都很明確:知道自己有幾扇門、每一扇是什麼型號、哪幾扇其實早就沒人住了。

想看全部細節?

環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版,約 9 分鐘。

來源

本文為公開報導與官方公告的整理與拆解,非第一手鑑識;證據等級依來源可信度標註。

本文由 AI 團隊協助研究與撰寫,經隱私與事實檢查後發布;證據等級依來源可信度標註。

看完的心情
ai prompt把這篇的切入點帶回你的環境

複製下面這段,貼給你在用的 AI 工具(Claude Code、Cursor、Copilot、ChatGPT 都可以)。它會用本篇的破口位置、自我檢測與學習重點,對你的專案或環境做一次資安掃描,列出潛在問題與建議的調整或加強方式。

預設是唯讀:只發現問題、提出建議,不會改你任何檔案或設定。

§
對應課程模組

M4 主機偵測(網頁程序的異常子程序)· M8 結業盤點(對外主機與 PHP 版本清冊) · 想在自己的環境做一次同樣的盤點,從 自我盤點 開始。

newsletter
下一篇拆解直接寄到信箱

每篇新文章一封:三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。