前文〈PHP2Shell：AI 一周找出十年舊洞 七成網站急補 政府索性關站〉梳理了事件起點；10 月 21 日，PHP 發布 8.5.12、8.4.27、8.3.36 與 8.2.35 修補 PHP2Shell（CVE-2026-109618、CVE-2026-109619）；攻擊卻在當日 07:43 已經開始，早過官方發布（Cloudflare）。三日之後，已修補的發行版套件陸續到位，但真正的長尾仍在舊版本：PHP 5.4 至 8.1 沒有官方更新，大量網站仍跑在這些版本上。為這些舊系統提供安全補丁，不是哪一家雲端供應商，而是義工維護者——Ondřej Surý。
Ondřej Surý 在 10 月 21 日晚間，將有關修補程式放進自己 Debian／Ubuntu 套件庫，覆蓋由 PHP 5.6 到 8.5 分支（HeroDevs，2026 年 10 月 23 日；Wikipedia「PHP2Shell」）。對沒有能力自行編譯 PHP 管理人員，一次 apt upgrade 就能補上，而不必重寫應用或整站遷移。
時間線：由洩漏到套件
| 時間（2026 年） | 事件 |
|---|---|
| 8 月 19 日 | Wiz 研究團隊以 AI 工具鏈找出第一個問題；8 月 24 日向 PHP 專案報告 |
| 10 月 20 日 | 詳情外洩，CVE 編號與 exploit 工具在網上流傳 |
| 10 月 21 日 07:43 | Cloudflare 錄得首批攻擊，早於修補發布 |
| 10 月 21 日 13:30–14:00 | PHP 發布 8.5.12、8.4.27、8.3.36、8.2.35 |
| 10 月 21 日 17:40 | 官方 Docker 映像全部更新；Homebrew 亦已更新 |
| 10 月 21 日 18:46 | Surý 的 PPA 已有 amd64 修補套件（8.2、8.3 另有 arm64） |
| 10 月 22 日 | Plesk 修補 7.4、8.0、8.1（未及 5.6 與 7.0–7.3）；Surý 的 arm64 建置陸續補上 |
| 10 月 23–24 日 | cPanel、XAMPP、NativePHP 相繼提供修補；Surý 的 arm64 分支繼續補齊 |
（時間線來源：PHP 官方公告、Cloudflare、Sansec、ma.ttias.be 的套件狀態追蹤、HeroDevs。）
誰是 Ondřej Surý？
他是 Debian 開發者，2000 年加入；自 PHP 5 年代起就負責 Debian 的 PHP 打包。用他的自己說法，Debian 與 Ubuntu 官方 PHP 套件，不是由他開發，就是基於他撰寫的軟件（deb.sury.org）。他的兩個主要渠道是 Ubuntu 的 PPA（ppa:ondrej/php）與 Debian 的 packages.sury.org；倉庫同時提供 PHP 5.6、7.0–7.4、8.0–8.3 多版本共存，並與 Freexian 合作，為已停止支援的發行版提供 PHP LTS 商業支援。
Ondřej Surý 的正職是 Internet Systems Consortium（ISC）的 DNS 工程總監，自 2017 年起領導 BIND 9 的開發（ISC 部落格、ISC 公開帖文）。換句話說，白天維護互聯網的 DNS 骨幹，晚上維護半個互聯網的 PHP 套件——後者是義工工作，收入來自 GitHub Sponsors 捐款（HeroDevs）。
這次 PHP 專案讓他在修補公開前取得修補內容，使他預先建置套件。他獲的捐款在數日內急增；Surý 向媒體表示，24 小時內收到的金額，已相當於過去一年的總和。
為什麼他的套件能救舊系統
PHP2Shell 的漏洞在引擎，不在應用程式碼。你可以把 WordPress、Laravel、Symfony、Drupal 全部更新，只要伺服器上的 PHP 仍是 5.4 至 8.1，就仍然暴露；而這些分支早已停止官方支援，PHP 專案不再發布修補（PHP 官方公告）。發行版對此的處理不一：Ubuntu 為所有受支援版本提供修補（Canonical，2026 年 10 月），Debian 亦然；但已過支援期的發行版，以及自行編譯或使用第三方倉庫的系統，就落在灰色地帶。
Surý 的套件正好填補這一格：同一個倉庫提供多個 PHP 分支的可安裝版本，管理員不必升級應用，也不必把伺服器由 Ubuntu 18 搬到 24，只要把 PHP 換成已修補的建置。對中小企業與共享主機而言，這是成本最低、風險最可控的補救路徑。
實作：在 Ubuntu／Debian 用他的套件修補
Ubuntu（PPA）
1. 加入 PPA：sudo add-apt-repository ppa:ondrej/php
2. 更新索引：sudo apt update
3. 只升級 PHP（把 8.4 換成你實際使用的分支）：sudo apt install --only-upgrade php8.4-fpm php8.4-cli
4. 重啟 FPM 與網頁伺服器：sudo systemctl restart php8.4-fpm && sudo systemctl reload apache2
Debian（packages.sury.org，官方 README 步驟）
1. sudo apt-get update && sudo apt-get -y install lsb-release ca-certificates curl
2. sudo curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
3. sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
4. sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
5. sudo apt-get update，然後 sudo apt-get install --only-upgrade php8.4-fpm php8.4-cli
6. sudo systemctl restart php8.4-fpm
其他環境
Docker 使用者直接拉更新後的官方映像；cPanel、Plesk、XAMPP 與 NativePHP 已在 10 月 22 至 24 日陸續提供修補（ma.ttias.be）。不過大家要注意，許多托管平台的共享主機，無法自行更新，應向主機商查詢 PHP 版本與修補狀態。
你是否需要他的套件？三種情境
第一種：伺服器跑 Ubuntu 或 Debian，PHP 由發行版提供，且發行版仍在支援期。這種情況優先等發行版更新，因為與系統其他套件一起測試，風險最低。第二種：跑的是已停止支援的 PHP 分支（例如 7.4、8.0、8.1），但作業系統仍受支援。發行版通常不再為這些分支提供修補，Surý 倉庫就是最直接的路徑。第三種：作業系統本身已停止支援（例如 Ubuntu 18.04、Debian 10）。可考慮 Freexian 的 PHP LTS，或把「升級作業系統」正式排進季度計劃；用第三方套件硬撐，只是把技術問題向後推，遲早都要解決。
要留意第三方倉庫的代價：這些由一個人維護，雖然歷史長、與官方套件同源，但始終不是發行版的安全團隊；版本可能與發行版不同步，升級時要先在測試機驗證，並以 apt pinning 固定來源，避免日後不小心把系統其他元件一併升級。對合規要求高的機構，應把使用第三方 PHP 倉庫寫進風險登記冊，而不是當成默認選項。
驗證：確認「真的修好了」
更新後要做三件事。第一，核對版本：php -v 應顯示 8.5.12、8.4.27、8.3.36 或 8.2.35。第二，核對網頁用的 SAPI，而不只是命令列——FPM 與 CLI 可以是不同二進位；可用 systemctl status php8.4-fpm 確認服務已重啟，並以一個臨時 phpinfo 頁（用完即刪）查看 Server API 與 PHP Version。第三，核對套件來源：dpkg -l | grep php 應顯示來自 packages.sury.org 或發行版的已修補版本。若你之前做了臨時緩解（封鎖 multipart、memory_limit=-1），修補驗證後應逐步還原，否則上傳功能會一直失效。
社群競賽與維護赤字
這次事件暴露了一個不對稱現場：AI 數日內找出潛伏十年的漏洞，攻擊者可以在修補發布前四至六小時開始掃描；但修補最後一公里，往往少數義工深夜完成。Surý 之外，還有 Remi Collet 等打包者，以及各發行版安全團隊；他們不在 PHP Foundation 的編制，沒政府資助。
結果是：Canonical、Red Hat、Docker、Plesk、cPanel 各自按自己的節奏補；arm64 版本建置更慢；舊發行版要靠商業 LTS 或義工的回溯修補。企業付費買的是雲端與授權，但真正托住整個生態，是這些沒 SLA 套件庫。捐款急增是好事，卻也說明平日投入不足。
社群的反應也值得記錄。r/PHP 在事件期間出現「Sponsor Ondřej Surý」置頂提醒；有開發者自行把 7.3 修補回溯到 Ubuntu 18／20，因為 Surý 只為 Ubuntu 22.04 以上與 Debian 11 以上建置修補軟件。Mattias Geniar 維護一份套件狀態表，逐日記錄哪個發行版、哪個架構、哪個分支已有修補——工作看似瑣碎，卻正是深夜決定「現在能不能重啟」系統的依據。
香港機構的三步
第一，補：按上文更新 PHP，或要求主機商提供已修補的版本；無法即時修補的對外系統，繼續封鎖 multipart/form-data 並收緊上傳限制。第二，驗：確認網頁 SAPI 的版本，而不只是 CLI；檢查日誌有無異常 multipart POST。第三，遷：把 PHP 5.4–8.1 的系統列入 12 個月遷移計劃，下一個漏洞不會等義工有空。數字辦亦已向所有部門發出保安警報，要求受影響系統盡快修補，否則暫時離線（見〈數字辦向所有部門發保安警報 受影響 PHP 系統須盡快修補 否則暫時離線〉，2026 年 10 月 23 日）
這場競賽誰贏？修補已經有了，工具也變得可負擔；但條件不應該是「有義工」，而是「制度」——資產清單、版本管理、演練更新流程，以及誰願意為開源維護付費，廠商組不能夠一直佔開源軟件的便宜，又不願意付出。Surý 的套件買到了時間，買不到開源軟件的制度。