自行編譯：7.4／8.0／8.1 官方回移植

先想清楚要不要自己編

自行編譯只適合有人能長期維護建置的團隊：之後的每一次安全修補，你都得自己再做一次。多數情況下，下面這些路比較穩：

發行版或 LTS 廠商已回移植的套件（例如 Ubuntu Pro 的 ESM、RHEL 8 的 php:7.4 勘誤，見各平台頁）。

註：發行版、LTS、回移植

發行版
例如 Debian、Ubuntu、RHEL。套件版號可能不是 8.3.36 這種 php.net 版號，仍可能已經回移植。官方寫明 rpms.remirepo.net 當天不會更新。
LTS
Long-term support。Linux 發行版與 LTS 廠商事先拿到修補。版號可能仍是廠商自己的編號，要以該廠商的安全公告為準。
回移植
發行版不升級大版本，只把安全性修補搬回舊版套件。7.4、8.0、8.1 這次有官方最小化原始碼回移植，沒有新的官方安裝包。確認時要看發行版安全公告，不要只對 php.net 版號。
控制台廠商的延長支援：cPanel 與 Plesk 都把舊分支指向 TuxCare。
直接升級到仍受支援的 8.2 至 8.5 分支。

7.3 以前（含 5.x）連原始碼回移植都沒有，見舊版本策略。

1. 檢查

確認網站真正在用的版本與編譯方式（自行編譯、或某個第三方套件）：

目前的版本與當初的編譯參數

php -v
php -i | grep 'Configure Command'

把 Configure Command 那一行存下來，重建時用同一組參數；並確認網站的 PHP-FPM 或 mod_php 是同一份建置，見我受影響嗎？。

註：PHP-FPM、mod_php

PHP-FPM: 以獨立行程池處理請求的常見跑法。基金會確認經應用層路徑可以 RCE。官方沒有把 PHP-FPM 寫成安全，只是沒有把它排在 mod_php 前面。
mod_php: 把 PHP 嵌進 Apache 行程的模組。未驗證的請求可在應用程式碼開始前碰到漏洞；官方稱預設設定下已展示完整 RCE。worker 會跨請求重複使用的部署，過期狀態更有機會留下來。

2. 更新

PHP 官方公告把回移植放在 php-src 的三個分支：PHP-7.4-CVE-2026-109618-109619、PHP-8.0-CVE-2026-109618-109619、PHP-8.1-CVE-2026-109618-109619。

取得 8.1 的回移植分支並編譯（7.4、8.0 換分支名；configure 參數用上一步存下的）

git clone --depth 1 --branch PHP-8.1-CVE-2026-109618-109619 https://github.com/php/php-src.git
cd php-src
./buildconf --force
./configure <原本的 Configure Command 參數>
make -j"$(nproc)"

先在測試環境跑應用的測試。php2shell.com 指出修補會加入硬性記憶體上限，超過時終止行程，而且不執行 shutdown handler；若程式靠 shutdown function 寫日誌或釋放鎖，行為會改變。

註：shutdown handler

shutdown handler
研究團隊寫，修補新增的硬性記憶體上限到達時會終止行程，shutdown handler 不會執行。官方 GHSA 相符的部分是較高的那一道門檻會立刻結束行程。依賴收尾函式的應用要在更新後看過這個行為變化。
封裝成你們能重複部署的形式（套件或映像），不要在正式機上手動編譯。

3. 重啟

部署新建置之後，重啟所有 php-fpm、Apache 與 LiteSpeed 的 worker，確認沒有舊行程留著。

註：LiteSpeed、worker

LiteSpeed: 官方把 LiteSpeed 列在服務網頁請求、需要假設有風險的安裝裡，沒有單獨排成第二名或第三名。
worker: 處理網頁請求的 PHP 行程。同一支 worker 接下一個請求時，可能在正常初始化把殘留狀態清掉之前就用到它。修補後要重啟所有 worker。

4. 驗證

確認正在接流量的 PHP 是新的建置（版號可能和舊建置相同，請比對建置日期或你自己的建置標記）。
確認測試環境觀察到的記憶體上限行為在正式環境不會造成意外中斷。
記錄這份建置的來源與套用的回移植，之後的修補才找得到。

來源

查詢日期：2026-10-23。官方公告優先列出；內容如與 PHP 官方公告不一致，以官方公告為準。