前言

2026 年 10 月 21 日晚間，pixiv、Niconico、BASE 與多款日本遊戲陸續出現緊急維護公告。這波異動的重要背景，是 PHP 發布兩個重大漏洞的安全更新：CVE-2026-109618 與 CVE-2026-109619，研究團隊將相關問題稱為 PHP2Shell。PHP 官方確認，它們可能讓未登入的攻擊者在受影響伺服器上執行程式碼。本文會整理漏洞原理、更新範圍與各站公告。PHP 官方公告、Wiz 研究報告

先補上最容易過時的一項消息：pixiv 已公告於日本時間 10 月 21 日 23:30，也就是台灣時間 22:30，結束緊急維護。 原先預告的「維護到隔天凌晨」已經有更新；停站與恢復時間都應以官方後續公告為準。pixiv 維護完成公告

資料截點：2026-10-21 22:53，台灣時間 UTC+8。 相當於日本時間 2026-10-21 23:53（UTC+9）。本文網站維護表統一使用日本時間，預定結束時間不代表實際恢復時間。封面為 AI 生成的概念插畫，描繪服務暫停後修補共用元件，並非事件現場或遭駭證據。

一、今晚發生什麼事？先掌握嚴重程度與時間

PHP 安全團隊在 10 月 20 日預告，將於 10 月 21 日 14:00 UTC 發布緊急安全更新，換算為台灣時間 22:00、日本時間 23:00。預告同時要求使用者準備更新，並保留在資訊提前公開或發現利用跡象時提早發布的可能。本文查核時，修正版與技術公告已經公開。PHP 更新預告與正式公告

PHP Foundation 的事後說明補充：原本協調的發布日期是 10 月 22 日，在 CVE 編號提前流傳後，團隊將正式發布提前一天。這也解釋了為什麼業者需要臨時調整維護排程，不能只照較早的轉貼消息安排工作。PHP Foundation 對揭露過程的說明

兩個漏洞在官方公告中的評分均為 CVSS v4.0 9.2，Critical：

漏洞 官方名稱 問題概要 可能後果
CVE-2026-109618 RCE via OOM corruption 記憶體不足時，中斷尚未完成的內部資料初始化，清理階段可能誤用無效資料 無須登入驗證的遠端程式碼執行
CVE-2026-109619 RCE via stale global state 舊請求留下的狀態仍指向已釋放記憶體，後續請求可能再次使用 記憶體資訊洩漏、遠端程式碼執行

來源：CVE-2026-109618 官方技術公告、CVE-2026-109619 官方技術公告。

遠端程式碼執行（Remote Code Execution，RCE），代表攻擊者有機會讓伺服器執行其控制的程式碼。官方已驗證的權限範圍是 Web worker 帳號；後續能否讀取應用機密、修改檔案或存取其他系統，還取決於該帳號的權限與環境配置，不能直接等同取得整台主機的 root 權限。

二、影響範圍：全球 PHP 網站都需要盤點

這次需要處理的是 PHP 執行階段本身。PHP 官方將提供 Web 請求服務的部署列為風險範圍，包含 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed。PHP 安全公告

PHP Foundation 特別說明，mod_php 已有在應用程式碼執行前觸發的攻擊驗證，OOM 相關的 RCE 也已透過應用層路徑在 FPM 確認。這些差異影響可利用路徑，需要按實際部署判斷。PHP Foundation 技術摘要

受支援分支，應更新到哪一版？

以下是各自分支內的上游版本對照。閱讀時要先確認自己的分支，不能把四個「低於」條件混成一條跨分支規則。

PHP 分支 該分支受影響的上游版本 本次修正版
8.2 8.2.35 之前 8.2.35
8.3 8.3.36 之前 8.3.36
8.4 8.4.27 之前 8.4.27
8.5 8.5.12 之前 8.5.12

來源：PHP 官方版本與更新說明。

Linux 發行版或長期支援廠商可能提供 backport（將修補移植到既有版本），因此套件的完整修訂號與廠商公告也必須一起核對。單看 php -v 顯示的上游數字，未必能判斷廠商套件是否已修補。

PHP 7、8.0、8.1 與更舊版本呢？

舊版不能因為沒有出現在上面的支援分支表，就被當作安全。Wiz 表示，至少一項相關問題可追溯到 PHP 5.4。PHP 官方則說明，8.1 與更舊版本已停止一般上游支援；這次另提供 7.4、8.0、8.1 的最小原始碼 backport，供自行建置或沒有 LTS 廠商支援的使用者參考。這不代表舊分支恢復完整維護。Wiz 影響範圍說明、PHP 舊分支處理說明

實務上應取得廠商對這兩個 CVE 的明確修補確認，並安排升級到受支援分支；對沒有修補管道的對外服務，應優先降低外部可達性。

Laravel、WordPress 與手機 App 也要看後端

Wiz 在研究環境以 WordPress、Drupal、Joomla 部署示範未登入的 RCE。這些是實驗目標，不能據此宣稱所有使用這些 CMS 的正式網站已遭入侵，也不能把 Wikipedia 等採用 PHP 生態的知名網站直接列為受害者。Wiz 實驗結果

同樣的盤點方式也適用於 Laravel API、購物網站後台與手機 App 的伺服器端。判斷依據是請求是否會進入受影響的 PHP，以及是否已有修補。瀏覽器只收到 HTML／JSON，或 App 本身用 Swift、Kotlin 撰寫，都不足以判斷後端安全。

此外，IPA 提醒，部分軟體產品與網路設備內部也使用 PHP。對這類系統，應查產品供應商的公告與更新管道。IPA 官方提醒

三、漏洞怎麼發生？請求結束後，worker 還可能繼續工作

理解這次問題，需要分清楚「一個 HTTP 請求的生命週期」與「處理請求的程序生命週期」。PHP-FPM 管理一組 worker，一個 worker 可以依序處理多個請求；理論上，請求專屬的狀態應在適當時機清乾淨，避免帶到下一個請求。PHP-FPM 官方文件

CVE-2026-109618：記憶體不足，中斷了尚未完成的工作

OOM 是 Out of Memory，表示記憶體配置失敗。PHP 會透過 longjmp() 離開當前執行位置；若此時內部資料僅完成一部分初始化，清理程序卻繼續把它當正常資料使用，就可能造成記憶體破壞並發展成 RCE。實際利用的可靠度會受到建置方式、擴充套件與前端處理等因素影響。OOM corruption 官方公告

CVE-2026-109619：舊請求的指標，指向已釋放的記憶體

第二個問題涉及 Use After Free（UAF，釋放後使用）：請求的記憶體已回收，worker 內的某些全域狀態卻仍保留舊指標。後續請求若在正常初始化之前碰到這些狀態，就可能讀取或操作已失效的記憶體。PHP Foundation 技術摘要

官方指出，已確認的跨請求路徑需要前後請求抵達同一個 worker。增加 worker 數量或回收頻率可能降低單次成功率，仍無法消除漏洞；session 生命週期相關的 RCE 已在 mod_php 與 FPM 驗證。stale global state 官方公告

以下用概念圖整理兩者的差異，圖中的風險結果仍取決於實際可達條件：

flowchart TD
    A[特製 HTTP 請求進入 PHP] --> B[觸發異常處理]
    B --> C[109618：OOM 中斷尚未完成的初始化]
    C --> D[清理當前請求時使用無效資料]
    B --> E[109619：請求記憶體釋放後仍保留舊狀態]
    E --> F[後續請求在同一 worker 使用失效指標]
    D --> G[記憶體安全問題可能發展為 RCE]
    F --> H[可能洩漏記憶體資訊或發展為 RCE]

這也說明了應用程式維護頁的位置為什麼重要：若必須先啟動受影響的 PHP 才能顯示維護頁，仍可能讓請求抵達漏洞所在的處理流程。 在需要隔離的情境下，較合適的做法是在負載平衡器、反向代理或其他不經 PHP 的入口回應維護內容，並確認外部無法繞過入口直接連到原站。這是根據漏洞觸發位置提出的部署建議。

四、哪些知名網站受到服務影響？逐一看官方公告

下表整理的是官方確認的維護與功能異動。BASE、兩款 Cygames 遊戲與 tomoLinks 直接點名 PHP；pixiv、BOOTH、Niconico、DMM 的所引公告使用安全維護或軟體漏洞等描述，公告本身未直接點名 PHP。媒體將這些服務異動放在同日 PHP 緊急更新的脈絡報導，仍不足以推定各站的版本、可利用性或入侵結果。Impress Watch 當日報導

以下時間全部為日本時間，預告排程與已確認完成會分開標示。

服務 官方公告的時間 功能影響與最新已確認資訊 公告對原因／被害的說明
pixiv、pixiv 百科、pixivFANBOX 等 10/21 19:00 起；23:30 已公告完成 對象服務的網站與 App 曾暫停；使用 pixiv 帳號的其他服務可能連帶影響部分功能 安全性維護；原公告表示未確認不當存取或資訊外流。維護預告、完成公告
BOOTH 原公告為 10/21 19:00～10/22 未明（預定） 預告期間無法新登入、購買商品；本文不以原排程推定其目前仍停站 安全性維護；未確認不當存取或資訊外流。官方公告
BASE、PAY ID 10/21 15:50～10/22 07:00（預定） 商店瀏覽與下單、管理畫面、PAY ID App、BASE API 列入影響範圍 明確點名 PHP；公告表示未確認本事件造成的不當存取或資訊外洩。官方公告
Niconico 10/21 19:00 起陸續維護；結束未定 動畫、部分頻道與付費／創作者功能等列入維護；直播、帳號登入等另列為持續提供 因軟體重大漏洞預告而採取預防性維護；公告列明部分服務採用不受影響的技術構成。官方公告
《賽馬娘 Pretty Derby》 原訂 23:00 左右，後改為 10/21 22:00 左右開始 遊戲與資料連動等功能列入維護影響 明確點名 PHP；初始公告表示未確認漏洞被利用或使用者資料外流。官方說明、時間變更
《碧藍幻想》 後續公告改為 10/21 22:00 左右開始 為確保系統安全而調整遊戲維護時間 明確點名 PHP；所引時間變更公告未提供入侵調查結論。官方公告
DMM 的電子郵件兩階段驗證登入 10/21 22:00 起 所引公告列出的範圍是電子郵件兩階段驗證登入，不可據此推定所有 DMM 業務全部停用 外部軟體漏洞的預防性處置；公告表示未發生個資或資料外洩。官方公告
Konica Minolta tomoLinks 10/21 19:30 起緊急停止 服務暫停，待確認影響與安全性後另行公告恢復 明確點名 PHP；公告表示未確認不當存取或資訊外洩。官方公告

這份表不是完整受影響名單，也不是「遭駭網站清單」。其中「未確認外洩」描述的是營運方在公告當時掌握的資訊，後續調查若有新發現，仍應更新。

為什麼日本網站看起來同時關了很多？

這波公告顯示，多家業者在共用的安全更新時點前後安排維護，有些甚至在補丁發布前先停止服務。從風險管理角度看，這是在縮短「仍對外提供舊版本服務」的時間。漏洞影響由軟體與部署條件決定，範圍不限日本。

CERT-EU 在預告階段就建議，無法立即修補時，可考慮將對外應用隔離，直到能套用修補。至於個別服務是否必須全面停站，還取決於能否安全地限制入口、輪替更新與確認新版本正常。CERT-EU 建議

五、已經有攻擊了嗎？三種證據需要分清楚

截至本文截點，Cloudflare 的第一手報告表示，已觀測到針對客戶的攻擊流量，也看到攻擊者修改 payload 嘗試繞過防護。這足以說明風險已進入實際防禦階段；它沒有提供上述服務逐一遭入侵的證明。Cloudflare 攻擊觀測與防護說明

閱讀後續新聞時，可以用三個層次判斷：

已知資訊 可以支持的結論 尚缺什麼才能判斷被害
部署受影響版本，或廠商要求更新 存在需要處理的漏洞風險 實際請求可達條件、修補狀態與利用證據
WAF 偵測到特徵、來源發送攻擊請求 出現探測或利用嘗試 是否成功觸發漏洞、是否執行程式碼或取走資料
官方鑑識確認不當執行、檔案遭修改或資料外流 可依證據描述入侵與損害 完整時間線、受影響資料及後續處置

因此，停站數量不能當成入侵數量，PHP 市占也不能當成此次受害網站比例。 本文沒有足夠證據提供全球成功利用數量或上述各站的完整鑑識結果。

六、站長與後端工程師，現在應該怎麼處理？

以下是依本次公告整理的處理順序，屬於部署與事件應變建議。實際套件更新方式應依自己的作業系統、映像檔供應商與代管服務調整。

1. 先確認真正接收 HTTP 請求的是哪一套 PHP

建議至少記錄下列資料，讓修補能對應到實際服務：

盤點項目 需要得到的答案
執行版本與套件來源 PHP 分支、完整套件修訂號，或容器映像檔 digest；供應商是否確認修補兩個 CVE
Web 執行方式 FPM、mod_php、php-cgi 或其他 SAPI／整合；對應哪個服務、pool 與部署
設定與程序 CLI 和 Web 是否使用不同版本／設定；有沒有其他 pool、舊容器或舊程序仍接流量
外部入口 正式站、API、管理後台與原站入口是否都已納入處理

php -v 可以協助了解目前命令列的 PHP，仍需要與 Web 的實際執行環境交叉核對。避免為了檢查版本，把完整 phpinfo() 頁面長時間公開在網路上。

2. 套用執行階段修補，並完成程序輪替

升級應落在實際執行的 PHP 套件或映像檔。容器環境要確認新的基底映像已包含修補，重新建置、部署後，舊副本也已退出流量；單純修改 Dockerfile 的標籤文字不足以證明正式環境已更新。

程序輪替後，再確認實際版本、登入、檔案上傳、session、API 與錯誤率。若需要回復部署，回復版本也應包含安全修補。Drupal 安全團隊亦特別提醒，網站持有者需要維護第三方與執行平台的安全更新。Drupal 官方提醒

3. 暫時設定與 WAF，可用來降低部分暴露

本次官方公告的完整解法是更新到包含修補的版本。下列設定有特定作用與限制，不能僅憑設定值判定修補完成：

措施 作用與限制
session.upload_progress.enabled=0 在請求解析前以適當管理設定套用並重啟所有 worker，可阻擋已確認的 session 路徑；其他變體仍需處理
PHP 8.5 的 fatal_error_backtraces=0 針對已確認的 fatal backtrace 路徑，仍需重啟 worker
memory_limit=-1 移除 PHP 每請求記憶體上限，是針對 OOM 路徑的部分緩解；取消上限也會增加記憶體耗盡風險，不能當成已修補
入口的請求大小／multipart 限制 可縮小部分攻擊面，必須符合應用需求，並考慮解碼後大小與缺少可用 Content-Length 的請求
WAF 規則 提供額外攔截與觀測；需確認流量確實經過防護，並持續完成 PHP 更新

設定細節與適用條件應直接對照兩份 PHP 技術公告及相關狀態清理公告。Calif 研究團隊也明確提醒，移除記憶體上限只屬部分緩解，並有資源耗盡風險；Cloudflare 則要求客戶在啟用其防護時繼續修補 PHP。Calif 修補建議、Cloudflare 更新建議

4. 若出現疑似利用跡象，同步保存調查資料

修補解決的是往後的漏洞暴露。若懷疑先前已有利用，還需要保存入口／WAF／Web／PHP／系統的時間線與紀錄，檢查異常程序、檔案變動與對外連線，再依已確認的可讀取範圍處理憑證與權限。

這裡應避免兩種過早結論：看到 HTTP 500 就宣稱遭駭，或應用日誌沒有明顯異常就宣稱安全。Wiz 提醒，相關問題可能在應用層以下執行，應用日誌能提供的線索有限。Wiz 偵測注意事項

七、一般使用者需要做什麼？

如果只是使用 pixiv、遊戲或購物服務，這次 PHP 修補由服務營運方負責。可以先查看官方恢復公告；涉及訂單、活動期限或遊戲補償時，依各服務後續處理規則確認。

密碼與帳號處理也應跟著具體資訊走。目前引用的 pixiv 公告並未確認資料外流，不能直接據此認定密碼已外洩。若服務之後通知帳號風險，或自己觀察到異常登入，再依官方帳號安全流程處理。對透過私訊或陌生連結要求登入的「緊急修補通知」，應回到官方網站核對。

總結

PHP2Shell 需要優先處理，因為問題位於 PHP 執行階段，研究已驗證未登入即可觸發的 RCE 與記憶體資訊洩漏。應依分支套用 8.2.35、8.3.36、8.4.27、8.5.12 或供應商確認的 backport，再核對正式服務的程序與部署狀態。

今晚多個日本服務採取了預防性維護。pixiv 已公告恢復；BASE、《賽馬娘》與《碧藍幻想》等則有直接點名 PHP 的處理公告。 各站維護範圍與調查結果應分別看待，後續再依官方更新修正服務狀態。

對工程團隊來說，這次事件也提醒我們：資產清單需要包含執行階段與實際部署，緊急維護需要能在應用之前阻擋流量，發布流程則要能確認每個舊副本都已完成輪替。

延伸閱讀

官方與研究來源

技術與事件判讀的主要來源如下；各服務維護公告已直接附在對照表內。