舊版本策略（8.1 以前）

發行版套件的版號可能不是上表的 php.net 版號，仍可能已經回移植修補，以該發行版的安全公告為準。程式碼被認為可回溯到 5.4.0，但並非每一個歷史版號都經過逐一驗證。

8.2：修得到，但快要 EOL

8.2 有官方修補版 8.2.35，但安全支援只到 2026-12-31。打完這次的修補後，仍要排程升級到 8.3 以上，不要停在「已經打了 8.2 的安全更新」。

7.4、8.0、8.1：先找廠商，再考慮自己編

官方因這次的嚴重性，為 7.4、8.0、8.1 提供了最小化的原始碼回移植，沒有新的官方安裝包。依序考慮：

1. 發行版或 LTS 廠商的回移植套件。例如：Ubuntu 22.04 LTS 的 php8.1 已有修補；Ubuntu 20.04 LTS 的 php7.4 修補經 Ubuntu Pro 提供；RHEL 8 的 php:7.4 已有勘誤。版號會是廠商自己的編號，以其安全公告為準。
2. 控制台的套件：Plesk 在 Linux 上的 8.1.34、8.0.30、7.4.33 版號不變，2026-10-21 建置的才含修補；cPanel 的 ea-php74／80／81 有對應修補版，見控制台頁。
3. 付費延長支援：cPanel 與 Plesk 都把更舊的分支指向 TuxCare。
4. 自行編譯：只適合能長期維護建置的團隊。

7.3 以前（含 5.x）：沒有官方修補

7.3 以前（含 5.x）在現有官方公告中沒有修補。部分廠商仍有延長支援（例如 Ubuntu Pro 的 Legacy Support 涵蓋 16.04 的 php7.0 與 14.04 的 php5，Plesk 把 5.6、7.2、7.3 指向 TuxCare），但以自己的維護能力來說，策略應該是：

1. 立刻規劃升級到仍受支援且已修補的分支（8.3 以上最理想）。
2. 升級完成前，不要直接對網際網路開放。ICSDA 提到的過渡做法是只走 VPN 或內網，或 WAF 加上限縮來源 IP。這些都不是修補。
3. WordPress 官方新聞稿的建議：自行管理主機且還停在更舊版本時，考慮先把網站下線，再準備升級。
4. 在升級前先套官方暫時緩解，並照偵測與應變查日誌。

升級舊分支時要注意

• 跨大版本升級常牽動應用程式本身（框架、外掛、擴充）的相容性，先在測試環境驗證。
• 盤點時別漏掉控制台、廠商設備與 Windows 軟體內建的舊 PHP，這些最常停在很舊的版本。