修補:Debian

先看 PHP 是從 Debian 官方還是 Sury 裝的,從 security 套件庫更新到修補版,重啟所有 worker,再用套件版本與 changelog 確認。

1. 檢查

先看裝了哪些 PHP 套件、版本是多少:

列出已安裝的 PHP 套件與版本
dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/{print $2, $3}'

版本字串看得出來源:~deb13u1、~deb12u1 結尾的是 Debian 官方套件;含 +debian12~1.gbp…、+freexian… 的是 Sury(packages.sury.org)。再對照下表。

Debian 官方套件

Debian 每一版只附一個 PHP 分支,修補從 security 套件庫出:

發行版 套件 公告 修補版(security) 修補前
13 trixie php8.4 DSA-6574-1 8.4.27-1~deb13u1 8.4.24-1~deb13u1
12 bookworm php8.2 DLA-4848-1 8.2.35-1~deb12u1 8.2.32-1~deb12u1
11 bullseye php7.4 無 Debian 不再修補 —
  • bookworm 已轉由 Debian LTS 維護,所以公告編號是 DLA,不是 DSA;更新方式一樣。
    註:LTS
    LTS
    Long-term support。Linux 發行版與 LTS 廠商事先拿到修補。版號可能仍是廠商自己的編號,要以該廠商的安全公告為準。
  • bullseye 的 Debian LTS 已經結束,安全追蹤頁沒有列出 php7.4,不會有官方修補。見下面 Sury,或升級到 12/13。
  • forky(testing):2026-10-23 查詢時仍是 8.4.26-1,列為有漏洞;sid 已有 8.4.27-1。正式環境不要跑 testing。
  • Debian 官方沒有 php8.3;裝了 php8.3 就是來自 Sury 或其他套件庫。

Sury 套件庫

很多主機用 Ondřej Surý 維護的 Sury 套件庫裝其他 PHP 分支。它不在 Debian 安全公告範圍內,但 2026-10-21 起已經上架修補版(本站 2026-10-23 對照套件目錄):

分支 Sury 修補版 php -v 會顯示
8.5/8.4/8.3/8.2 8.5.12、8.4.27、8.3.36、8.2.35 新版號
8.1/8.0/7.4 同一個上游版本的新修訂,例如 7.4.33-31 舊版號不變,要看 changelog
  • arm64 等架構的套件有時比 amd64 晚一兩天,裝完要確認實際版本。
  • 加了 Sury 之後,Debian 自己的 php8.x 也可能改從 Sury 更新。同一台主機請想清楚 PHP 要從哪一邊來,不要混用。
  • 8.1 以前的分支 PHP 官方已不再發布更新,Sury 的修訂只是過渡,見舊版本策略。

2. 更新

更新套件清單,列出可更新的 PHP 套件
sudo apt-get update
apt list --upgradable 2>/dev/null | grep php
只更新已安裝的 PHP 套件(依你的分支改 php8.4 / php8.2 / php7.4)
sudo apt-get install --only-upgrade 'php8.4*' 'libapache2-mod-php8.4'

整台一起更新(sudo apt-get upgrade)也可以,會順便更新其他套件。

清單裡沒有 PHP? 多半是 sources 沒有 security 套件庫。確認有這一行(12 把 trixie 換成 bookworm),再 apt-get update:

security 套件庫(/etc/apt/sources.list 或 sources.list.d/ 內)
deb http://deb.debian.org/debian-security trixie-security main

用 deb822 格式(/etc/apt/sources.list.d/debian.sources)的,確認 Suites: 裡有 trixie-security。

3. 重啟

裝好套件之後,重啟所有 php-fpm 與 Apache(用 mod_php 時),讓每一支 worker 都換成新的程式。服務名稱跟著分支走:

註:php-fpm、mod_php、worker
php-fpm(PHP-FPM)
以獨立行程池處理請求的常見跑法。基金會確認經應用層路徑可以 RCE。官方沒有把 PHP-FPM 寫成安全,只是沒有把它排在 mod_php 前面。
mod_php
把 PHP 嵌進 Apache 行程的模組。未驗證的請求可在應用程式碼開始前碰到漏洞;官方稱預設設定下已展示完整 RCE。worker 會跨請求重複使用的部署,過期狀態更有機會留下來。
worker
處理網頁請求的 PHP 行程。同一支 worker 接下一個請求時,可能在正常初始化把殘留狀態清掉之前就用到它。修補後要重啟所有 worker。
重啟 PHP-FPM 與 Apache(服務名稱依實際安裝調整)
sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2

不確定還有哪些行程在用舊的函式庫,可以裝 needrestart 列出來:

列出需要重啟的服務
sudo needrestart -r l

只 reload 一部分、或滾動更新留下舊 worker,等於還沒修完。

4. 驗證

  • 再跑一次第 1 步的 dpkg -l,確認版本等於或新於上表的修補版。
  • 看套件的 changelog 有沒有提到這兩個 CVE(8.1 以前用 Sury 的修訂版,這是唯一看得出來的地方):
    註:CVE
    CVE
    這次是 CVE-2026-109618 與 CVE-2026-109619。外洩貼文曾把分數寫成 10.0,官方 CVSS v4.0 是 9.2。
changelog 裡找這次的 CVE(依分支改 php8.4 / php8.2 / php7.4)
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.4-common/changelog.Debian.gz
  • 向正在接流量的那一支 PHP 確認版本(PHP-FPM 執行檔的 -v、Apache 載入的模組),不只看命令列,見我受影響嗎?。
  • 若緩解期間把 memory_limit 設成 -1,修補後改回應用真正需要的上限。

來源

查詢日期:。官方公告優先列出;內容如與 PHP 官方公告不一致,以官方公告為準。