PHP2Shell 事件後，網際網路又安全了嗎？使用者與網站擁有者需要了解的事

目錄

• 你可能想知道
• PHP2Shell 代表什麼？網路是否安全？
• 重點摘要表
• 後續……

你可能想知道

• PHP 發布安全更新，是否代表所有有漏洞的網站現在都受到保護？
• 一般使用者是否應該更改密碼，或因為 PHP2Shell 避免使用加密貨幣網站？

PHP2Shell 代表什麼？網路是否安全？

PHP 安全危機已從緊急揭露階段，進入艱難的更新安裝與入侵檢查工作。兩個漏洞合稱 PHP2Shell，攻擊者可利用它們在不登入的情況下控制有漏洞的伺服器。PHP 已發布安全更新，各組織也開始修補系統，或暫時讓部分網站下線。然而，修補程式一經發布，並不代表所有伺服器就會自動受到保護：負責這些系統的人員與組織必須安裝相應版本，並重新啟動 PHP，修補程式才會生效。

對一般網路使用者來說，這不代表網際網路本身停止運作，也不代表個人手機和筆電會自動受到影響。主要風險在於伺服器尚未完成防護的網站與線上服務。這項區別很重要：有漏洞的伺服器可能託管民眾造訪的網站，但訪客自己的裝置不一定會受到漏洞影響。這令人稍感安心，但不表示這起事件無關緊要。遭入侵的網站可能誤導訪客、洩露資訊，或提供有害內容。

PHP 是網站在幕後使用的程式語言與執行環境。來源指出，在已知伺服器端語言的網站中，約有 70% 使用 PHP。由於 PHP 使用廣泛，其弱點可能影響各式各樣的組織，從私人網站到政府服務皆然。PHP2Shell 指的是兩個不同的漏洞，編號為 CVE-2026-109618 和 CVE-2026-109619。據報導，這些漏洞造成的影響尤其嚴重，因為攻擊者可能不必先通過身分驗證，就能控制受影響的伺服器。

來源所述，PHP 於 October 21 發布的版本仍是唯一完整的修補方案。根據其版本說明，該專案於 Wednesday 發布了 8.5.12、8.4.27、8.3.36 和 8.2.35 版本。該專案的指引十分明確：「沒有完整的緩解措施，更新是唯一安全的選擇。」截至 Thursday，PHP 尚未發布後續修補程式。安裝更新並重新啟動 PHP 是必要步驟；僅僅知道有修補程式存在，並不會改變伺服器上的軟體。

在本文所述的情況下，更新不會自動套用。託管公司、企業 IT 團隊、公部門技術部門，以及個別網站擁有者，都必須更新自己管理的系統。有些組織可能管理多台伺服器，或必須先完成測試程序才能部署變更，這可能拖慢更新進度。因此，即使修補程式已經公布，網站仍可能存在漏洞。PHP 8.1 和更早版本已不再獲得官方發布，讓舊系統面臨額外挑戰。PHP 安全團隊確實為自行編譯軟體的使用者發布了 7.4、8.0 和 8.1 的基本修補程式，但這些修補程式不等同於目前版本所享有的正常官方發布支援。

攻擊活動的規模令人震驚，但攻擊嘗試不等於成功入侵。Cloudflare 執行長 Matthew Prince 表示，在公開公告前的 10 hours，該公司的網路上出現數千次漏洞利用嘗試。公告後的 45 minutes 內，活動攀升至數萬次；兩小時內達到數十萬次，之後累計達數百萬次。這些數字顯示攻擊者迅速開始測試這項弱點，但光憑這些數字，無法確定有多少伺服器成功遭到控制。

Amazon 報告指出，活動跡象出現得更早。該公司表示，其誘餌伺服器於 October 17 記錄到一次嘗試，比漏洞公開早了四天。Amazon 資訊安全長 CJ Moses 表示，目前仍不清楚攻擊者如何在漏洞揭露前取得漏洞利用資訊，並形容 PHP2Shell「目前正在野外遭到廣泛利用」。這個時間點意味著，防禦者不應假設公開公告就是所有漏洞利用活動的起點。在揭露前執行過有漏洞版本的伺服器，除了更新之外，也可能需要檢查是否有更早遭存取的跡象。

德國與日本政府的說法提供了較令人安心、但範圍謹慎的情況。德國聯邦資訊安全局 BSI 副局長 Thomas Caspers 表示，該機構觀察到攻擊，但尚未發現成功利用漏洞的案例。他補充說，利用漏洞似乎「比預期稍微複雜一些」。日本內閣官房長官 Minoru Kihara 也表示，尚未確認有攻擊利用這些漏洞。這些說法並不能證明全球沒有任何組織遭到入侵，只能說明在這些官員發言時，相關機構尚未確認成功攻擊。

一個理解兩者差異的簡單方式，是想像有人在轉動門把。漏洞利用嘗試就像搖晃門把；入侵則代表真的進了屋。即使發生數百萬次嘗試，也可能沒有任何一起經確認的闖入，因此上述數字不一定互相矛盾。同時，入侵也不一定會立即被發現。某個時間點尚無已確認事件，固然令人鼓舞，但不能取代對受影響系統的檢查與長期監控。

PHP 基金會的說明也讓人開始關注漏洞的處理過程。基金會在 Wednesday 發布的部落格文章中表示，2024 年的安全工作發現了 CVE-2026-109618 背後記憶體耗盡問題的初步跡象。團隊考慮了「幾種互相競爭的解決方案」，但難以從中抉擇，也擔心選錯修補方式所帶來的後果。基金會表示，其資金使多位人員能全職處理這項問題，同時承認整體回應仍花了太久時間。

基金會將這段延誤稱為「結構性失敗」，並歸因於安全團隊的決策流程以及資源不足。過去安全團隊必須達成共識；基金會表示，未來將改採多數決。這點很重要，因為 PHP 支援了網路上相當大的一部分，而安全工作仰賴少數由基金會資助的開發人員與部分志工協助。這起事件說明，廣泛使用的基礎設施安全，不只取決於修補程式的技術品質，也可能受限於開發能力與治理流程。

有些網站下線，是因為當組織無法立即修補時，暫時讓有漏洞的服務離開公眾可存取的範圍，可以作為保護措施。英國國家網路安全中心建議組織考慮「讓系統下線，直到漏洞能完全緩解」。據報導，Wednesday 無法使用的網站包括 Wikimedia 服務、Orange 在數十個國家的網站與應用程式、32 個英國政府服務、荷蘭醫院，以及德國聯邦 IT 服務供應商 ITZBund。英國預算責任辦公室與愛丁堡市議會網站已於 Thursday 恢復。根據 DutchNews 報導，荷蘭匿名犯罪舉報網站 Meld Misdaad Anoniem 在 Thursday morning 仍未恢復。這些例子顯示，服務中斷可能是刻意採取的風險應對措施，不代表每個下線的服務都已成功遭到攻擊。

對一般大眾而言，目前資訊不足以支持僅因 PHP2Shell 就更改所有密碼。根據本文所述，截至當時尚無已確認的資料外洩事件與這些漏洞有關。如果服務的伺服器仍未修補，更改密碼無法保護帳戶，也無法確認攻擊者是否曾存取資訊。更實用的基本做法仍然重要：每個帳戶使用不同的密碼、啟用雙重驗證，並留意公司通知。如果服務通報資料外洩，請更改該帳戶的密碼，以及任何重複使用相同密碼的其他帳戶。

網站營運者還有額外責任。套用修補程式可以關閉已知弱點，但無法證明攻擊者是否曾在更新前入侵。資安公司 Tag1 建議檢查是否有組織未曾上傳的 PHP 檔案、新建立的排程工作，以及不熟悉的帳戶。對於曾執行有漏洞版本、且可從網際網路存取的伺服器，該公司也建議輪替資料庫密碼與 API 金鑰。這些檢查是為了確認是否存在持續存取或憑證遭竊的情況，而不是把軟體更新當成系統已乾淨的證明。

加密貨幣使用者面臨的相關風險，來自造訪的網站，而不一定是底層區塊鏈網路。Binance 創辦人 Changpeng Zhao 在 X 上提醒使用者，接下來幾天造訪網站時要格外小心，因為部分管理員可能無法及時套用安全修補程式。遭入侵的網頁伺服器可能顯示仿真的合法網站。在加密貨幣情境中，假網頁可能要求使用者連接錢包並核准一筆會轉走資金的交易。區塊鏈本身可能仍正常運作，但用來與區塊鏈互動的網站可能已遭入侵。

接下來幾天，使用者可以透過書籤進入熟悉的網站，而不要點擊意料之外的連結；仔細確認網站網址；並在簽署前檢查每筆交易或錢包授權，以降低可避免的風險。對於已經擁有硬體錢包的使用者，它或許能提供額外保護，但不能因此就安全地核准陌生或可疑的交易。來源報導指出，截至當時，尚無加密貨幣交易所公開通報與 PHP2Shell 有關的資料外洩事件。這只是公開通報的情況，並不保證所有相關服務都未受影響。

整體風險仍集中在尚未修補的伺服器。資安公司 Mallory 統計，約有 884,000 個可從網際網路存取的主機，仍在執行沒有官方修補程式的 PHP 版本。這項數字凸顯舊系統仍持續存在，以及全面完成修補有多困難。Amazon 提醒防禦者，不要假設公開揭露日就是漏洞利用活動最早開始的日期。實際上，至少自 October 17 起執行過有漏洞版本的組織，應調查這些系統，而不只是安裝更新後就置之不理。

整體而言，本文並未指出瀏覽網路絕對不安全，也不代表所有網站或個人裝置都已遭到入侵。更恰當的理解是，這是一場仍在進行中的安全應變：支援中的版本已有修補程式，攻擊者已大規模嘗試利用漏洞，而部分組織尚未完成補救。個人使用者應保持警覺，但不要做出缺乏根據的推測；伺服器營運者則應優先處理更新、調查，以及在適當情況下輪替憑證。

重點摘要表

後續……

接下來的發展取決於各組織更新暴露於網路的系統有多快，以及調查是否發現修補前遭存取的證據。網站營運者應將修補程式發布視為補救工作的起點，而非終點：安裝適當更新、重新啟動 PHP、檢查可能受影響的伺服器，並在發現可疑跡象時遵循事件應變程序。使用者仍可保持一般程度的謹慎繼續瀏覽，尤其是造訪處理敏感資訊或加密貨幣交易的服務時。

這起事件也帶出一個更長遠的問題：如何維護關鍵的開放原始碼軟體。PHP 基金會的說明凸顯，充足的安全經費、明確的決策方式，以及開發人員發現警訊時能及時升級處理，都十分重要。由於舊版 PHP 不再獲得官方發布，許多可從網際網路存取的主機仍在使用這些版本，各組織需要制定升級舊系統的計畫，而不是無限期依賴臨時措施。修補程式的存在，不代表網際網路就「再度安全」；只有隨著修補程式逐步安裝、系統完成檢查，並讓維護關鍵軟體的人員獲得足夠資源與有效流程，風險才會逐漸降低。