2026 年 10 月 21 日，PHP 官方發布安全公告，修補兩個高風險漏洞：CVE-2026-109618 與 CVE-2026-109619（社群稱為「PHP2Shell」）。兩者的 CVSS 嚴重度都是 9.2，攻擊者不需要登入，就可能在網站主機上遠端執行程式。
PHP 是許多網站與系統的基礎，這類漏洞影響的範圍很廣。接下來幾天，國家級資安單位發出預警，各政府機關也陸續要求委外廠商盤點、回報。
我們維運的系統，包括電商網站、品牌官網，以及多個政府單位的網站與系統。以下整理這幾天實際做了哪些事，以及為什麼這樣做。
一、通知到的時候，我們已經處理好了
這次最關鍵的，是時間差。我們在收到漏洞消息、查證屬實後，約 30 分鐘內就在負責的主機上套上緩解設定，這時 PHP 官方的修補版都還沒推出。
之後各客戶陸續收到通知或主動詢問時，情況是這樣：
| 客戶 | 通知或詢問 | 那時我們的狀態 |
|---|---|---|
| 政府單位 A | 國家級資安單位發布預警，機關再轉寄給所有委外廠商（收件廠商超過 50 家），要求確認並儘速更新 | 緩解在預警發布前約 11 小時就已生效；機關轉知時，我們回覆的是「已處理完成」，不是「開始處理」 |
| 政府單位 B | 客戶的資安窗口轉發主管機關通知，要求盤點風險並改善 | 緩解比主管機關的通知早約 21 小時；客戶轉信給我們時，官方修補版也已經升級完成，約 1 小時後即書面回覆 |
| 客戶 C | 客戶的系統窗口在漏洞公開隔天上午主動詢問「對我們會有影響嗎？」 | 前一天下午就已套上緩解，回覆客戶「已經先關掉這個元件」 |
| 客戶 D | 客戶的資安窗口轉傳新聞詢問是否需要調整，之後轉來填報表 | 測試環境前一天已處理；正式環境需要客戶同意時段，客戶同意後約 3 分鐘完成，服務零中斷 |
收到通知後，我們也不是只回一句「已處理」。例如政府單位 A，我們先逐台再確認一次設定確實生效，才寫書面回覆，內容包含使用情形、已完成的處置與後續計畫。
二、先緩解，再修補
處理這類漏洞，通常分成兩層：
| 緩解 | 修補 | |
|---|---|---|
| 做法 | 關掉有問題的功能，讓已知的攻擊路徑失效 | 升級到官方修好的版本 |
| 需要多久 | 幾分鐘到幾十分鐘，不必等官方 | 要等官方釋出，還要測試、挑時段 |
| 限制 | 不完整 | 才是根本解決 |
圖：緩解像先把破窗封起來，幾分鐘到幾十分鐘就能做、不用等官方；修補像換一扇新窗，要等官方修補版並測試後才上正式站。
這次我們套用的是官方建議的緩解設定：關閉 session.upload_progress（上傳進度追蹤）。關掉後檔案上傳照常可以使用。
要特別說明的是，PHP 官方在公告中寫得很清楚：「沒有完整的緩解方式，升級是唯一安全的選擇。」 緩解是為了在修補到位之前爭取時間，不是處理完了。所以官方修補版一推出，我們就接著安排升級。
圖：這次的處置順序。下面第三到第七節，依序說明每一步實際怎麼做。
三、同一台主機，可能不只一份 PHP 設定
一台主機上的 PHP 可能同時以好幾種方式執行（例如內嵌在網頁伺服器、獨立的 FPM 服務、命令列），也可能同時裝了好幾個版本。只改其中一份設定，其他的照樣有漏洞。
所以我們是每個版本、每種執行方式逐一加上設定，連主機上裝著但沒在使用的版本也一起處理，再逐一確認實際生效的值是關閉的，並確認網站運作正常。
四、套用設定，也要不影響使用者
設定改了，要讓服務重新載入才會生效。我們的做法是「平順重新載入」：舊的處理程序把手上的請求處理完，才換成新的，使用者不會斷線。
跟客戶約時段時，我們預估「大概會停個 1 到 10 秒」；實際執行時，我們對網站連續發送請求監測，全程零中斷。
這中間也有個小插曲：第一次執行時，因為「完全沒有任何中斷」，我們反而覺得不對勁，去查服務紀錄才發現那次的重新載入其實沒有生效。改用正確的方式重做後，再實際讀出設定值確認已經關閉。零中斷不等於已生效，一定要驗證。
五、修補不是一出來就直接上正式站
官方修補版發布後，我們先在測試環境升級，結果遇到一個狀況：升級後只「重新載入設定」，部分網站出現錯誤。原因是網頁伺服器的主程式還掛著舊版的 PHP 模組，改成完整重新啟動後就恢復了。
有了這次經驗，正式環境的升級就排在晚上的離峰時段，直接做完整重新啟動，升級前後逐站確認狀態一致。
另外，這次只升級 PHP 本體。部分附加元件同時有較大的版本跳升，因為漏洞在 PHP 核心、不在這些元件，所以另外排時間測試，不在同一晚一起冒險。
六、確認「真的生效」，不只看版號
升級完成，不代表正在執行的程式已經換成新的。我們做了兩件事：
- 檢查執行中的程式：確認沒有任何執行中的程序還載入著已被替換掉的舊檔案。
- 看更新紀錄，不只看版號：Ubuntu 這類發行版，常把修補直接打進原本的版本號裡。例如 Ubuntu 24.04 的 PHP 8.3 修補後仍顯示 8.3.6，只是發行版自己的小版次改變。只看「8.3.6」會以為沒修，要看套件內附的更新紀錄（changelog）有沒有列出這兩個 CVE，才能確定。
七、檢查有沒有被入侵
緩解套上之前，有一段「已知有風險、還沒擋住」的空窗。所以我們從漏洞公布當天起，每一台主機都檢查了這段期間：
- 網站目錄有沒有新增或被修改的程式檔，有沒有常見的後門寫法
- 網站的執行身分底下，有沒有異常的程序或排程
- 暫存目錄有沒有可執行檔
- 有沒有異常的對外連線
- 存取紀錄裡有沒有異常的請求
結果是沒有發現任何被入侵的跡象。期間看到的多半是自動掃描程式在試探其他舊漏洞的路徑，都沒有成功。
這類檢查也有它的極限：我們看的是檔案、程序、排程、連線與存取紀錄；只存在記憶體、不留下檔案的攻擊，無法完全排除；網站的存取紀錄也不會記下送出的內容，這部分只能從「同一來源短時間大量送出請求」這類跡象去近似判斷。所以我們的說法是「沒有發現跡象」，而不是「證明沒有被入侵」。
另外，我們在事件發生前，剛把正式環境的網站程式碼改成網站本身沒有寫入權限。就算攻擊者真的取得執行能力，也無法改寫網站程式，能造成的損害會小很多。
八、盤點時，也抓到我們自己的疏漏
這次逐台盤點，不只是找 PHP 漏洞。過程中我們也發現一個跟 PHP2Shell 無關、但屬於我們自己的疏漏：其中一台正式主機上的資料庫管理介面（phpMyAdmin）對外公開，任何人都連得到登入頁。
錯誤紀錄裡累計約 6,000 次登入失敗，光是 10 月就有 767 次，都是境外的自動化工具在猜帳號密碼，全部失敗。
我們先查清楚它背後連的是什麼：這個管理介面只連到主機本機一套沒在使用的舊版資料庫，裡面只有系統預設的資料、沒有任何業務資料，設定上也不允許改連其他主機；正式資料庫在另一台內網主機上，它碰不到。
接著分三步處理：
- 先限制只有指定的來源可以連線
- 再把這個管理介面整個關閉，不論從外網或內網都無法開啟
- 最後把那套沒在使用的舊資料庫停用、設為開機不啟動（資料先備份，需要時可以還原）
處理完逐項確認網站與每日資料同步都正常。
這裡也要照實說明限制：錯誤紀錄只記失敗、不記成功，所以我們無法用紀錄證明「從來沒有人成功登入」。能確定的是，它背後沒有資料、也連不到正式資料庫，就算有人登入，也拿不到東西。
管理介面是給維運人員用的，不該讓外界連得到。盤點的價值，有一部分就在於把這類平常不會注意到的問題翻出來。
九、已停止維護的舊版 PHP，只剩緩解
這次官方的修補版只涵蓋 PHP 8.2 以上。8.1 以下（包含 7.x）已經停止維護，官方不會推出正式的修補版。
在我們維運的範圍內，也有部分系統仍在使用舊版 PHP。這些主機的緩解設定會永久保留，並納入每日自動檢查，設定被改掉就會發出告警。
但要坦白說：官方自己都說緩解不完整。舊版本不是「還能跑就好」，下一次核心漏洞出現時，它只剩緩解、沒有修補。這也是我們在這次事件中，同步和使用舊版本的客戶討論升級規劃的原因。
升級我們採「先建後切」：新系統在測試環境建好、驗收通過才切換，升級期間舊系統照常運作，防護也持續維持。
如果你的網站或系統是委外維運，可以問這幾件事
以下是依這次實際處理過程整理的問題，可以作為評估維運服務時的參考：
- 重大漏洞公告後，多久能套上緩解？ 是等主管機關通知才動，還是主動處理？
- 緩解和修補分得清楚嗎？ 舊版本沒有修補時，打算怎麼處理？
- 升級後怎麼確認真的生效，而不只是看版本號碼？
- 有沒有做入侵檢查？ 檢查的範圍和極限有沒有說清楚？
- 我的系統是不是跑在已停止維護的版本上？ 有沒有升級規劃？
- 網站程式碼，網站自己改得動嗎？ 改不動的話，被打進來時損害會小很多。
- 資料庫管理介面這類維運工具，外面連得到嗎？
漏洞不會因為網站上線就停止出現。上線之後誰在看、多快能反應，和網站本身一樣重要。
想了解我們的網站維護與代管方式，可以參考 電商網站開發、品牌形象官網設計 服務說明、維護服務條款，或直接 與我們聯繫。
參考資料：PHP 官方安全公告（2026-10-21）、Ubuntu CVE-2026-109618、Ubuntu CVE-2026-109619
