PHP 重大漏洞有多嚴重？日本首相示警，pixiv、BASE 等服務掀停機潮
2026 年 10 月 21 日的 PHP 重大漏洞事件，讓「緊急維護」同時出現在插畫平台、網路商店與托育 App。光看 pixiv、BOOTH、BASE、CoDMON 這幾個名字，就知道影響已經走出工程師的工作群組，進入一般人的日常生活。
連日本首相高市早苗都發文呼籲當晚處理，無法迅速修補時，可考慮暫停網站。這次究竟嚴重在哪裡？先看官方資訊，再看哪些服務真的公告暫停。
資料截點：2026 年 10 月 21 日 22:48，台灣時間。 下文維護時段統一標示為日本時間（JST，快台灣 1 小時），均為官方公告的安排，不代表實測停機長度；恢復情形請以各服務最新公告為準。PHP 官方在本次查證時已公布修正版，不能再只看白天的「等待更新」消息。
今天的 PHP 漏洞，到底是什麼問題？
PHP 團隊在 10 月 20 日預告重大安全更新，原訂於 10 月 21 日 14:00 UTC，也就是台灣 22:00、日本 23:00 發布。兩個漏洞的嚴重度均為 CVSS v4.0 9.2，Critical。
目前已公開的兩份上游公告，分別是：
- CVE-2026-109618：記憶體不足時的處理可能讓內部資料處於不完整狀態，後續清理卻繼續使用它，可能導致遠端程式碼執行。PHP 上游公告
- CVE-2026-109619：前一個請求留下的內部狀態，可能在記憶體釋放後仍被後續請求使用，同樣可能導致遠端程式碼執行。PHP 上游公告
白話來說，風險可能涉及攻擊者不必先登入，就能讓伺服器執行其指定的程式碼。實際利用仍有環境與觸發條件；「不必登入」不代表每個 PHP 網站都能被同一個請求直接攻破。
這也不是只更新某個 WordPress 外掛就能處理的問題。漏洞位於 PHP 執行環境本身；網站管理者需要確認主機實際使用的 PHP 是否已修補。
連日本首相都提醒：必要時，先把網站暫停
高市早苗的原始貼文把它列為當晚需要緊急處理的事項：確認公開網站是否使用 PHP，準備迅速套用更新；如果無法立即完成，暫時停止網站也是降低風險的選項。
這不是社群自行喊出的「全部關站」。CERT-EU 的事前警報同樣建議，無法即時修補時，應考慮把對外應用程式與公開網路隔離。
對業者而言，暫停服務會中斷使用者操作，也可能影響收入。當官方把隔離列為應對選項，業者又真的停止接單、登入或整套系統，事情的份量就比一串漏洞分數更容易理解。
有多誇張？先看這六組官方停機公告
以下都能找到業者自己的公告。有些明確提到 PHP，有些只說安全性維護；後者不能自行補成「已確認受這兩個 CVE 影響」。
| 網站或服務 | 官方公告的暫停範圍 | 時間與原因的查證結果 |
|---|---|---|
| pixiv、pixiv 百科、pixivFANBOX 等 | 對象服務的網站與 App 無法使用，其他採用 pixiv 帳號的服務也可能有部分功能受限 | 10/21 19:00 至 10/22 凌晨，公告理由為確保安全性，未點名 PHP。官方貼文 |
| BOOTH | 暫停新登入、商品購買等功能，不能直接說成所有頁面均關閉 | 10/21 19:00 至 10/22 凌晨；公告為安全性強化，未點名 PHP。官方公告 |
| BASE／PAY ID | 商店管理、商店頁面瀏覽與下單、PAY ID App 操作及 BASE API | 開始時間已提前至 10/21 15:50，預計到 10/22 07:00；更新公告明確指出 PHP 重大漏洞。官方公告 |
| CoDMON | 包含家長 App 在內的全部服務停止，另提供紙本出缺勤紀錄等替代範本 | 10/21 公告停機，預計 10/22 清晨恢復；現行公告稱使用軟體有重大漏洞，未點名 PHP。官方公告 |
| Konica Minolta tomoLinks | 教育服務暫停提供，待處理完成後再恢復 | 10/21 的 PHP 漏洞相關公告確認服務暫停，並連向 IPA 警報，未給固定恢復時間。官方公告 |
| CyberMates | 全部內容與服務暫停 | 10/21 起預防性停機，明確提及 PHP，待修補與安全確認後恢復。官方公告 |
最有感的地方，是不同生活場景一起受影響。想看作品會遇到維護；想買商品，登入與結帳可能受限；商家連後台與 API 都無法操作；托育機構還得準備替代紀錄方式。
BOOTH 也讓人看見另一層連動：即使你只想購物，帳號服務的維護仍可能阻斷流程。網站之間共用的登入與基礎元件，平常很方便，遇到緊急修補時也會把影響帶到其他服務。
社群名單很長，但不是「遭駭名單」
你如果是從 @anywhere_otaku 的整理串看到這件事，應該會對那一長串名字很有感：從《碧藍幻想》《賽馬娘》，到 pixiv、BOOTH、BOOK☆WALKER、Niconico，都出現在網友彙整中。
原作者註明是自己的整理，包含已進入維護或準備維護的服務。這份名單適合拿來找線索；若要判斷停了哪些功能、是否與 PHP 有關，仍須回到各家公告。上表因此只列已核對官方說明的案例，也保留了沒有點名 PHP 的情況。
還有一點必須講清楚：預防性停機不等於已遭入侵，更不等於個資已經外洩。 pixiv、BOOTH、BASE、CoDMON 與 CyberMates 的上述公告，都表示在各自公告時尚未確認相關入侵或資料外洩；不能把停止服務解讀成受駭證據。
修正版已公布，網站管理者要確認的是實際執行環境
PHP 官方安全公告已列出此次修正版：
| 使用的 PHP 分支 | 此次修補版本 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
如果主機商或 Linux 發行版採用回補修正，應以該供應商的安全公告與套件修訂版判斷，不能只看主版本號。仍用舊版 PHP 的系統，也需要確認維護來源，或遷移到受支援版本。
實務上要確認三件事：對外服務的 PHP 已套用修正、運行中的處理程序已重新載入更新、關鍵功能通過檢查後才恢復對外服務。 只更新應用程式套件，或只看命令列顯示的版本，都不足以證明提供網站服務的環境已完成修補。
官方也明確提醒，設定調整只能減少特定攻擊路徑的暴露，不能完整取代更新。一般使用者則先看服務官方的恢復公告；看到維護畫面，不需要直接推定自己的帳號出了問題。
這次事件最值得記住的畫面，是業者願意承擔停機成本，也要先處理共用執行環境的風險。當一個底層元件需要緊急修補，影響會一路傳到看圖、購物、開店與家長聯絡。這就是今天這波停機潮讓人特別有感的原因。
