凌晨兩點推 PHP 更新：寶塔面板做的這件事，其實是在替官方補位

10 月 22 日凌晨，V2EX 有使用者發文，注意到寶塔面板在凌晨兩點左右推送了一批 PHP 更新。內容包括 PHP 8.5.12、8.4.27、8.3.36、8.2.35 等官方最新版本，但真正值得注意的，是留言裡那幾行補充說明：PHP 官方這次只在 GitHub 上放了修補、沒有正式發包，因此 7.4、8.0、8.1 這幾個早已停止常規維護的舊版，是由寶塔自行打包修復版本，對應 7.4.34、8.0.27、8.1.35。

停援之後，補丁從哪裡來

PHP 的版本支援有明確年限，7.4、8.0、8.1 先後進入安全維護終止或僅限例外處理的狀態。照正常劇本，用舊版的人只能自己遷移。但現實是，大量中文圈網站跑在寶塔面板一鍵安裝的環境上，站長不一定有工程背景，也不會盯 php-src 的 GitHub 動態。

於是出現了一個特殊的分工：官方工程師在分支上提交了針對 CVE-2026-109618 與 CVE-2026-109619 的修補程式碼（討論串中有使用者貼出 PHP-7.4、8.0、8.1 對應的分支連結），寶塔把這些程式碼編譯成可直接安裝的套件，面板用戶在軟體商店點一下「更新軟體列表」就能裝上。

用一個日常比喻：這就像原廠已經停產某款老車的零件，但圖紙是公開的，於是熟識的保養廠自己照圖做出零件，讓老車主不用換車也能過年檢。方便歸方便，零件的品質責任也從原廠移到了保養廠手上。

討論串裡也有使用者提醒，面板有時不會主動顯示更新，得到軟體商店右上角手動點「更新軟體列表」才看得到入口。這個小細節對維運人員很實際：仰賴面板的更新提示，可能會漏掉這批修補。

維運責任的轉移，才是重點

討論串裡一位曾任 SRE 的使用者留言說，若還在原本的職位，大概又要熬夜處理。另一位的反應則完全相反，認為這是內卷。兩種反應正好說明了這類更新在實務上的兩面性。

對自己編譯、自己管伺服器的團隊來說，官方 GitHub 分支就在那裡，面板打包只是多一個選項。但對使用一鍵安裝環境的中小站長，面板等於是他們與底層軟體之間唯一的橋樑。官方不發包、面板補位，這條供應鏈上多了一個中間環節，資安修補的時效與正確性，開始取決於面板廠商的工程判斷。

同串還有使用者回報，另一款面板 AMH 也提供了升級，甚至有人在自家專案上做了安全中心。這說明「面板幫舊版 PHP 出修補版」已經是這個生態的普遍做法，而非單一行為。

給正在用舊版 PHP 的人

原始貼文的建議是至少升到 7.4 以上，更低版本已無任何補丁。這個建議方向合理，但更值得記住的是背後的結構：只要還在官方支援年限內的版本，修補會有正式發包與公告；一旦掉出年限，修補就變成看臉色的事，有時是面板廠商出手，有時什麼都沒有。

如果網站跑在面板環境上，這次事件可以直接換成三個動作：確認目前 PHP 版本、手動刷新軟體列表看有無更新、評估把仍在 7.4 以下版本的站點列入升級計畫。資安修補能不能及時到位，這次剛好有人凌晨兩點幫忙補位，下一次未必。