PHP2Shell 漏洞：自架網店現在該做的事

今天就該做的事#

1. 1

   確認網店使用的 PHP 版本

   到主機控制台查看；WordPress 可以到「工具」→「網站健康狀態」→「資訊」→「伺服器」查看。記下版本，並確認 PHP 是不是由主機商代管。

2. 2

   更新 PHP，或請主機商確認已修補

   升級到 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35；或以書面詢問主機商，伺服器是否已套用 2026 年 10 月 21 日針對 CVE-2026-109618 與 CVE-2026-109619 的修補。

3. 3

   更新前後都做完整備份

   下載網站檔案與資料庫的完整備份，並在伺服器以外的地方留一份，萬一發現異常，才能還原到乾淨的版本。

4. 4

   更新網店系統與所有外掛

   安裝 WordPress、WooCommerce 或電商系統、佈景主題，以及每個外掛或模組的待更新項目，並移除已經不用的外掛。

5. 5

   檢查管理員帳號並更換密碼

   刪除不認得的管理員帳號，再更換後台、主機、資料庫的密碼，以及網店裡存放的 Email 服務密碼與 API 金鑰。

發生了什麼事：白話說明#

PHP 是許多自架網店背後使用的程式語言。PHP 官方在 2026 年 10 月 21 日發布 8.5.12、8.4.27、8.3.36、8.2.35 四個版本，修補 CVE-2026-109618 與 CVE-2026-109619 兩個重大漏洞 ^S1。資安研究人員把這兩個漏洞合稱為 PHP2Shell ^S5S6，嚴重程度評分都是 9.2 分（滿分 10 分）^S5。

問題出在 PHP 本身，而不是某個外掛。依 PHP 官方說明，所有處理網頁請求的 PHP 安裝都受影響；在部分伺服器設定下，沒有登入的人送出的請求，就能在網店程式執行之前觸發攻擊 ^S1。也就是說，後台登入、資安外掛或高強度密碼本身都擋不住。PHP 官方表示沒有完整的替代做法，更新是唯一安全的選擇 ^S1。

攻擊嘗試很早就出現。Datadog 指出，AWS 最早在 2026 年 10 月 17 日、修補公開之前，就觀察到利用嘗試 ^S6。2026 年 10 月 26 日，美國網路安全暨基礎設施安全局（CISA）把這兩個 CVE 列入「已知遭利用漏洞」清單，代表已有實際遭利用的證據 ^S3S4。

另一個漏洞 CVE-2026-115560 由 PHP 官方在 2026 年 10 月 23 日公布，它不屬於 PHP2Shell，10 月 21 日的版本也沒有修補它。這個漏洞只影響同時使用特殊 session 設定的應用程式，修補預計隨下一個例行版本推出，在那之前官方建議設定 session.upload_progress.enabled = 0 ^S2。本文內容以 2026 年 10 月 30 日的狀況為準。

我的網店有受影響嗎？#

如果網店是自己架設的，很可能就是用 PHP 執行。WordPress 是 PHP 應用程式 ^S7，所以 WooCommerce 網店跑在 PHP 上；Magento（Adobe Commerce）、PrestaShop、OpenCart 也是。即使商店本身不在自己的主機上，用 WordPress 架的部落格、活動頁或會員專區也算在內。

查詢 PHP 版本的方法：到主機控制台的「PHP 設定」或「PHP 版本」選單查看。WordPress 則到「工具」→「網站健康狀態」→「資訊」分頁，展開「伺服器」。各分支的已修補版本為 8.5.12、8.4.27、8.3.36、8.2.35 或更新版本 ^S1。

版本號不一定能說明一切。Linux 發行版和主機廠商事先就拿到修補程式，可能把修補回移到自家套件裡，而不改版本號 ^S1S6。不確定的話，直接問主機商伺服器是否已包含 CVE-2026-109618 與 CVE-2026-109619 的修補。

還在用 PHP 8.1 或更舊版本的網店，處境比較麻煩。PHP 官方已不再更新這些版本，部分廠商提供回移修補，官方建議向廠商洽詢或直接升級 ^S1。另外，PHP 8.2 將在 2026 年 12 月 31 日停止支援 ^S1。

今天該做什麼#

上面的編號清單是精簡版，以下補充讓每一步更穩妥的細節。

如果伺服器由你自己管理

透過系統套件或主機控制台更新 PHP，接著重新啟動 PHP 與網頁伺服器，讓每個工作程序都換成修補後的版本。CISA 建議優先修補連上網際網路的系統；如果沒辦法很快修補，可以暫時讓系統下線，或在前面加上網站應用程式防火牆（WAF）作為過渡措施 ^S3。PHP 官方列了一些暫時性設定，但也提醒這些設定無法讓系統真正安全 ^S1。

如果由主機商或代理商管理

寄一封簡短的書面詢問：「請確認我們的伺服器已套用 2026 年 10 月 21 日發布、針對 CVE-2026-109618 與 CVE-2026-109619 的 PHP 修補，並告訴我們目前使用的 PHP 版本或套件。」把對方的回覆留存備查。

動手之前先備份

把網站檔案與資料庫完整備份，存放在伺服器以外的地方。如果網店在修補前就已經被入侵，可能需要用更早的乾淨備份還原，所以先不要覆蓋舊的備份。

更新外掛並檢查管理員帳號

修補 PHP 能補上這個漏洞，但網店其他部分仍要照顧。更新 WordPress、WooCommerce 或電商系統、佈景主題和每個外掛。到使用者清單檢查有沒有不是你建立的管理員帳號。接著更換密碼，並重新產生網店裡存放的 API 金鑰與 SMTP 密碼，例如金流、物流和 Email 服務的設定，因為任何曾經進入伺服器的人都可能讀到它們。

保護顧客名單與寄件信譽#

網店資料庫存的不只是訂單，通常還包括每位顧客的姓名、Email、收件地址、購買紀錄，以及電子報訂閱名單。能在伺服器上執行程式的攻擊者，往往也能讀取這個資料庫，甚至用你的伺服器以你的名義寄信。

可能出問題的跡象

• 收到退信或回信，但那些信你根本沒寄過。
• 主機商通知伺服器在寄垃圾信，或負載異常。
• 出現你沒有新增的管理員帳號、外掛或檔案，或結帳頁被改過。
• DMARC 報告顯示有你沒在用的伺服器以你的網域寄信。
• 垃圾郵件檢舉突然增加，或網域、伺服器 IP 被列入黑名單。

網域的寄件人信譽要花時間累積，但垃圾信一旦以你的名義寄出，就可能很快下滑。SPF、DKIM、DMARC 紀錄告訴收件端哪些伺服器可以替你的網域寄信，DMARC 報告則讓你看到誰在嘗試冒用；SPF、DKIM、DMARC 說明逐一解釋三筆紀錄，DMARC 設定指南說明如何閱讀報告。如果網店伺服器本來就不負責寄行銷信，就不要把它列進 SPF 紀錄，這樣即使伺服器被入侵，能拿你的網域做的事也比較有限。

如果顧客資料可能外洩

資料外洩後的法律義務因國家而異。許多個資法規要求在一定期限內通報主管機關、受影響的顧客，或兩者都要通報；寫信給顧客之前，請先確認你銷售的每個市場的規定，或諮詢律師。我們的行銷信法規指南整理了各市場的同意規定；外洩通報規定則是另一回事，要依當地法律判斷。

通知顧客時，寫得直白就好：發生了什麼事、涉及哪些資料、你已經做了什麼、顧客要注意什麼。事後常見假冒網店寄出的釣魚信，所以要告訴顧客，你絕不會用 Email 要求他們提供密碼或信用卡號。以 Ninefold 這樣的服飾品牌為例，這封信會從平常的寄件地址寄出，不附任何折扣，避免看起來像行銷信。

降低下一次出事的風險#

PHP2Shell 不會是最後一次緊急更新。越容易維持在最新狀態的網店，越容易保護。

• 減少外掛。每個外掛或模組都是在你伺服器上執行、需要更新的程式。移除不用的外掛，能整合時，用一個維護良好的外掛取代好幾個小外掛。
• 使用仍受支援的 PHP 版本。在 2026 年 12 月 31 日 PHP 8.2 停止支援之前規劃升級，更舊的版本則現在就要處理 ^S1。
• 改用代管主機或託管服務。代管主機，或把金流、搜尋、Email 等功能交給託管服務，就能把修補工作交給以此為業的服務商。可以問問他們這次花了多久完成修補。
• 開啟自動更新，並在伺服器外備份。平台支援的話，開啟小版本自動更新，並定期把備份存到伺服器以外的地方。
• 指定負責人。決定由誰追蹤網店的資安公告，可能是你自己、工程師或主機商。

Tellnod 能幫上什麼#

Tellnod 是一個 MCP 連接器，讓你在 Claude 或 ChatGPT 裡撰寫、預覽並寄出行銷信。它是在 Tellnod 自己的基礎設施上運作的託管服務，不跑在你的網店伺服器上；用它取代電子報外掛，伺服器上就少一個要更新的外掛，網店資料庫裡也少存一組寄信憑證。

這能減少伺服器上的東西，但不會讓你的網店變得安全。PHP 和網店系統還是要修補；顧客名單也會同時存放在 Tellnod，所以詢問任何服務商如何保護資料都是合理的。安全性頁面說明 Tellnod 如何處理發送與資料。想試用的話，把 Tellnod 連接到 Claude 或 ChatGPT；你在核准卡片上按下 Confirm 之前，什麼都不會寄出。

常見問題#