PHP php2shell 漏洞（CVE-2026-109618／109619）：我們怎麼處置，以及西布倫會員系統為什麼不在影響範圍

PHP 兩個重大漏洞，CVSS v4.0 都是 9.2，修補已在台北時間 10 月 21 日 22:00 發布（8.5.12、8.4.27、8.3.36、8.2.35）；編號是 CVE-2026-109618 與 CVE-2026-109619，外界叫它 php2shell。我們維運的七台 PHP 主機當天先關掉 session.upload_progress、修補出來就升級。西布倫會員系統不是 PHP，不在這次範圍；客服信件系統是 PHP，一起修補。

10 月 21 日下午，西布倫美國集運的會員系統換上新版。同一天，我們也在處理另一件事：PHP 官方前一晚預告，兩個重大漏洞的修補會在台北時間 22:00 發布。

10 月 21 日晚間更新：官方修補已在台北時間 22:00 發布，版本是 PHP 8.5.12、8.4.27、8.3.36、8.2.35，CVE 編號也寫進了官方公告。Debian 13 怎麼升級、怎麼驗證，寫在續集：Debian 13 的 PHP 從 sury 換回官方源：套上 php2shell 修補的步驟。

很多人問同一個問題：「西布倫的會員資料會不會受影響？」先講結論：會員帳號、運單與付款資料所在的系統不是 PHP，不在這次漏洞的範圍。但我們有七台主機跑 PHP，今天都做了處置。下面照順序寫。

目前知道的事

修補已發布：PHP 官方 10 月 21 日發布 8.5.12、8.4.27、8.3.36、8.2.35（官方安全公告），修補兩個可以未登入遠端執行程式碼的漏洞，公告寫明編號是 CVE-2026-109618 與 CVE-2026-109619。官方說所有處理網頁請求的 PHP 都在風險範圍，其中 mod_php 風險最高。各 Linux 發行版事先拿到了修補，要升級的請看自己作業系統的套件更新。

下面是修補發布前的資訊，留著當紀錄：

官方說的：PHP 安全團隊 10 月 20 日公告，修補版本排在 10 月 21 日 14:00 UTC（台北 22:00）發布，修的是兩個重大漏洞，CVSS v4.0 都是 9.2；完整細節、受影響版本與修補版本會跟著修補一起公布。官方也說，如果細節提前曝光或出現實際攻擊，會提前發布。

研究人員說的：資安公司 watchTowr 對 BleepingComputer 表示，這是兩個遠端執行程式碼（RCE）漏洞，編號 CVE-2026-109618 與 CVE-2026-109619，他們認為影響 PHP 5 到 8，也成功重現了其中一個。watchTowr 說兩個都是 CVSS 10.0，PHP 官方給的是 9.2，兩邊說法不同，我們照實並列。CVE 編號一開始出自研究人員，官方修補發布時的公告也用了同樣的編號。

有沒有人在攻擊：watchTowr 的 FAQ 寫，截至 10 月 21 日沒有在野攻擊的報告；Huntress 也說在它的合作夥伴環境裡沒看到。不過日本 GMO Flatt Security 10 月 21 日追記，宣稱能利用這個漏洞的程式碼已經開始在網路上流傳。資安公司 Sansec 預期修補發布後 15 分鐘內就會有大規模攻擊。

舊版本沒有官方修補：PHP 官方目前只支援 8.2 以後的版本。Sansec 寫明，8.1 或更舊的版本不會有官方修補。

臨時緩解：關掉 session.upload_progress

修補已經發布，現在該做的是升級。暫時升不了的，官方公告列了兩組臨時措施，也寫明只能減少特定攻擊路徑、不會讓主機變安全：

  • CVE-2026-109619：設 session.upload_progress.enabled=0，每一個 worker 都要重啟；要寫在 php.ini、FPM pool 或伺服器設定，不能靠 ini_set() 或 FPM 的 .user.ini
  • CVE-2026-109618：設 memory_limit=-1，最好用應用程式改不掉的 php_admin_value；post_max_size 調低，不需要上傳檔案的網站設 8M，需要的設 32M

下面是修補發布前我們的做法。當時社群流傳的臨時做法是把 session.upload_progress.enabled 設成 0。這個功能用來追蹤檔案上傳的進度，PHP 預設是開的。

要說清楚的是，這是緩解，不是修好。GMO Flatt Security 寫，他們不能斷言這個設定 100% 有效；10 月 21 日的追記更直接，認為只改這個設定，攻擊仍然可能成功，根本的解法還是修補。關掉之後，一般的檔案上傳照樣能用，只有依賴這個功能的上傳進度條會失效。

我們怎麼處置？

我們先盤點：維運的主機裡，實際在跑 PHP 的有七台，包括 WordPress 官網與客服信件系統。接著做三件事：

  1. 先關 upload_progress：七台都在 10 月 21 日下午關掉 session.upload_progress.enabled。每台驗兩層：設定檔確認是關的，再實際從網頁程式讀一次，確認執行中的 PHP 也是關的
  2. 修補出來就升級：修補 21:56 出現在作業系統的套件庫，我們當晚手動升級，七台都升到 PHP 8.4.27，並逐台確認網站實際在跑的是新版。用 Apache 的主機要完整重啟才會換上新版，詳細步驟寫在續集
  3. 查有沒有被打的跡象：七台從 10 月 20 日起的存取紀錄，沒有帶上傳進度欄位的請求；上傳目錄從 10 月 20 日起沒有新增 PHP 檔。要說明的是，存取紀錄不記錄 POST 的內容，這個欄位在內容裡，所以這一項只能當參考

我們不會說「絕對安全」。修補出來之前，任何臨時做法都只能降低風險；修補裝上、紀錄查過，才算告一段落。

西布倫會員系統為什麼不在範圍內？

西布倫的系統分兩塊：

  • 會員系統：會員帳號、收件地址、運單與付款資料都在這裡。它跑在 Java 系的後端上，整台沒有 PHP。今天下午上線的新版，是這套系統的一次大版本升級。php2shell 是 PHP 本身的漏洞，兩件事互不相干，只是剛好同一天
  • 官網：用 WordPress 做，是 PHP。放的是公開的文章、說明頁與詢價表單，不放會員帳號、運單或付款資料；WordPress 這邊就算出事，也碰不到會員資料庫。官網已經在這次處置的七台裡

另外，我們的客服信件系統也是 PHP，存的是客人與客服的往來信件，同樣在這七台裡、同步處置。所以準確的說法是：會員帳號、運單與付款資料不在 PHP 系統裡；跑 PHP 的官網與客服系統，都照上面三步處理。

為什麼我們的會員系統一開始就不用 PHP，寫在第三集：官網用 WordPress、核心自己寫的理由。

一般站長現在該做什麼？

如果你的網站是 WordPress，或任何用 PHP 寫的系統，現在可以做三件事（第 3 件最重要）：

  1. 關掉 upload_progress：在網站實際使用的 php.ini（PHP-FPM 或 Apache 模組用的那份，不是命令列那份）設 session.upload_progress.enabled = 0，再重新載入服務。用虛擬主機的話，先問主機商
  2. 先備份：網站檔案與資料庫各備一份，升級出問題時才回得去
  3. 現在就升級：官方修補已發布，升到 8.5.12、8.4.27、8.3.36 或 8.2.35 以上。用 Debian 13 的，步驟看續集教學；用虛擬主機的，看主機商的公告

PHP 8.1 或更舊的版本，不會有官方修補。這時候該做的是排升級到 8.2 以上，或請主機商說明他們怎麼處理。

需要人幫忙看自己的主機，可以跟我們聯絡。

常見問題

php2shell 是什麼？

是兩個 PHP 重大漏洞的外號，編號是 CVE-2026-109618 與 CVE-2026-109619。PHP 官方評為重大，CVSS v4.0 都是 9.2，修補版本 8.5.12、8.4.27、8.3.36、8.2.35 在台北時間 2026 年 10 月 21 日 22:00 發布。

關掉 session.upload_progress 就安全了嗎？

不算。PHP 官方說這只擋 CVE-2026-109619 已確認的攻擊路徑，臨時措施都不會讓主機變安全；GMO Flatt Security 也認為只改這個設定，攻擊仍可能成功。修補已發布，請升級。

我的 PHP 是 8.1 或更舊，會有修補嗎？

PHP 官方目前只支援 8.2 以後的版本，8.1 以前不會有官方修補。官方為自己編譯的人提供了 7.4、8.0、8.1 的最小修補原始碼；一般網站還是請排升級到 8.2 以上，或問主機商怎麼處理。

西布倫的會員資料會受影響嗎？

會員帳號、運單與付款資料所在的會員系統是 Java 系，不是 PHP，不在這次漏洞範圍。西布倫的 WordPress 官網與客服信件系統是 PHP，已經關掉 upload_progress、查過紀錄，官方修補出來當晚升級。

WordPress 網站要做什麼？

WordPress 跑在 PHP 上，要升級的是主機上的 PHP，不是 WordPress 本身。官方修補已發布，備份後升級 PHP；用虛擬主機的話請主機商處理。

參考來源

延伸閱讀

作者：Kevin C Lin｜火曜領航企業社 CTO 兼負責人｜AI SEO／GEO 與基礎建設實戰｜DENBA Taiwan 執行顧問｜天櫃 SKYCARGO INC 創辦人

最後更新：