PHP2Shell 漏洞曝光：網安專家提供即時對策

來源：zennie 透過 Getty Images

新的資料顯示，組織在修補 PHP2Shell 的速度不及攻擊者利用它的速度。網路安全專家表示，這是可以理解的，因為此案的更新尤其複雜。

資料於 Oct. 21 開始逐步湧入，描繪了全球對新 PHP 漏洞 的初步回應。畫面並不美好。

一些位置優越的專家注意到大量威脅活動。Cloudflare 執行長 Matthew Prince 表示，在漏洞於週三公開前的 10 小時內，他們公司觀察到數千次利用嘗試。"在公告後 45 分鐘內跳升至數萬次，兩小時內達數十萬次，現在已達數百萬次，"他於 Oct. 21 晚間於 X 上 寫道。

第二天，Check Point Research 宣稱，利用嘗試已經達到 10% 的全球組織。另一方面，只有少數易受攻擊的組織明顯在更新至新版 PHP。

相關：'PHP2Shell' Bugs Signal Red Alert for Security Industry

以 Shodan 上可探測的部署為樣本，Ox Security 研究人員發現，超過 99% 的例項在修復版本發布 24 小時後仍未宣告新修補版本。Flare 的研究人員進一步指出，73% 的例項宣告的 PHP 分支已不再由 PHP 基金會更新。（他們亦說明這些數字有其侷限性，因基本網路掃描忽略了某些關鍵細節。）

同時，Cisco Talos 根據開源情報（OSINT）估計，約 一半的 PHP 系統 將無法收到修補。

在 Oct. 23 東部時間上午，Ox 通知 Dark Reading，其 99% 的數值已降至 97.5%。Flare 亦告知 Dark Reading，對於 27% 的公開記錄顯示上游支援分支，約 5% 已更新。

實務工作者承認，解決 PHP2Shell 並非僅按下「更新」即可。仍有多項步驟，組織可立即採取以自保，例如徹底搜尋整體系統中的 PHP 部署，偵測妥協跡象，並限制或下線無法即時修補的系統。

步驟 1：尋找 PHP，無所不在

原則上，防禦 PHP2Shell 應該很簡單。可更新至新版本，涵蓋 CVE-2026-109618 與 CVE-2026-109619 兩項漏洞。實際上，解決 PHP2Shell 的方式因組織而異，且所需努力程度取決於他們使用 PHP 的方式、位置與方式。

相關：Close Identity Gaps in Software Development Before Unleashing AI

所有網路安全專家一致指出的首要步驟是，組織應該 發現與盤點 其所有執行 PHP 的資產。說得容易做起來難。正如 Cybersecurity and Infrastructure Security Agency（CISA）在 Oct. 21 的安全警報 中指出，PHP 不僅是執行網站的程式，它「往往是其他軟體的元件，且其普及程度可能並非直接可觀察。」

Flare 研究人員親眼見證了這一點，當他們檢視攻擊面時。『在研究過程中，令我印象最深刻的是我們在傳統網頁託管之外還發現了大量 PHP，』Flare 的資深網路犯罪研究員 Adrian Cheek 這樣說。『我們在儲存裝置、實體存取控制系統、相機以及遠端存取介面中都發現了它。若你只關注主網站或把外部評估限制於 80 和 443 埠，你就會錯過其中一部分。』

對於這類暴露的組織，他繼續說：『你通常無法登入儲存裝置或實體存取控制單元，並獨立升級其 PHP 安裝。你需要製造商提供更新的韌體；若製造商已停止支援該產品，組織可能就無法取得修補程式。』

Related:假 Claude、ChatGPT 攻擊激增，開發者面臨風險

點選『更新』並非那麼簡單

把邊緣情況放一邊，我們假設某個組織已經成功找出並列出其所有 PHP 部署。從那裡開始，令人驚訝的是情況只會變得更複雜。

公開可得的資料似乎顯示，全球大多數 PHP 仍在使用舊版分支。"如果你正在使用以 PHP 5 或 PHP 7 為基礎的應用程式，升級到最新的 PHP 版本可能需要重寫部分程式、替換相依套件，並測試所有可能失效的功能。組織之所以不輕易採取此舉，尤其是當應用程式支援重要營運功能時，背後有充分的理由，" Cheek 解釋。

在這種情況下，修復將是一個緩慢的過程，若組織選擇追求此舉。幸運且令人困惑的是，舊版 PHP 並非永遠無法修復。

公開紀錄中最常見的版本 7.4.3 是隨 Ubuntu 20.04 一起釋出的。正如 Cheek 所指出的，"Linux 發行版 經常保留較舊的 PHP 版本號，並回移安全修補。因而舊版本號並不代表軟體未被修補。" 除了作業系統之外，應用程式也可以為其所捆綁的 PHP 回移修補。

因此，使用過時 PHP 的組織實際上可分為幾類：有些組織需要進行重大的遷移或替換工作，將其應用程式或產品更新。與此同時，專家表示，他們應該考慮將脆弱的系統完全下線。Cheek 還提供一個專業技巧，以降低 CVE-2026-109619 的風險，適用於能夠存取 PHP 設定的情況。

"報告中的攻擊透過 PHP session 上傳進度執行，該功能預設為開啟，且不需要在應用程式中呼叫 session_start。停用 session.upload_progress.enabled 並重啟 PHP 工作者即可阻斷已確認的 session-upload-progress 攻擊路徑，而不必升級 PHP 版本，" 他解釋，並補充說這並未解決另一個 PHP2Shell 漏洞 CVE-2026-109618，因此這只能算是暫時措施。

有些組織會有幸能透過供應商安裝回溯修正。10 月 21 日，Ubuntu 開發者 Canonical 為自 14.04 以來的所有版本發布了 修正，修正 PHP2Shell。即使是這些得到緩解的團體也還需要做更多的帳務工作，因為作業系統或應用程式更新並不一定包含完整的 PHP 版本升級。如果利用 Ubuntu 的更新，未來掃描仍可能顯示其表面上正在執行 PHP 7.4.3。

別忘了，Cheek 這麼說：『重啟很重要。安裝已修正的 PHP 套件並不一定會取代已載入執行中的工作程序的解譯器。』

每個 PHP2Shell 案件皆不同

除技術細節外，規模將決定組織如何回應 PHP2Shell 的許多方面。

與任何 緊急網路安全漏洞 相同，小型企業在意識與所需資源方面可能一開始就處於劣勢，難以自行清除問題。然而，在連續工作 48 小時協助超過 1,000 家企業處理 PHP2Shell 後，OX Security 執行長 Neatsun Ziv 更快指出小型化的優勢。

在小型組織中，你可以隨心所欲。你只需進去修補，等待五小時，沒有人抱怨破壞了什麼，"他說。"

但大型組織則不同，他說。『他們擁有金鑰映像——一個他們更新的伺服器基線，』Ziv 說。『這始終是一種下游模式：你部署新的金鑰映像，這個映像再被新軟體建構，這個新軟體投入生產，沒有人能改變生產環境。這是今天部署的常態。沒有人去伺服器實際修補。長期下來這變得無法維護。』

這更不說說在大型組織內，來自不同團隊需要參與重大更新的人數；或大型組織執行過度重要、無法容忍宕機的系統；或即使在組織內，PHP 的普及度與多樣性。正如 Ziv 所說，『我們合作的大多陣列織發現有數百臺執行 PHP 的伺服器。』

Check Point 的首席安全與信任官 Alex Spokoiny 補充說，即使在自身範圍之外，組織也面臨供應商處理 PHP2Shell 的風險。

『第一步是與相關供應商接觸，瞭解他們的回應方式。是否受到影響？他們已經採取哪些保護措施？他們預計何時完成修復？如果你無法得到明確或合理的答案，這本身就需要納入風險評估，並可能考慮替代方案，』他建議。

組織也可以團結合作，對所有人都有利。『例如，若技術上可行，他們可能將自己的 Web 應用防火牆（WAF）保護擴充套件到第三方運營的應用，協助降低風險，直至供應商完成永久修復，』Spokoiny 說。

關於作者

撰稿人

Nate Nelson 是一位記者及屢獲殊榮的劇本作家。除了 Dark Reading，他還為 Darknet Diaries 撰寫內容，這是跨媒體網路安全領域最受歡迎的節目。

他以自由撰稿人開始職涯，為科技與金融領域的高層寫 Forbes 與 CNBC 的社論稿。之後，他轉入 Threatpost 擔任記者，報導網路安全新聞與趨勢。在此期間，他與他人共同創作了網路安全播客《Malicious Life》，當時曾登上 Apple Podcasts 與 Spotify 的科技播客前 20 名排行榜。

他擁有紐約大學（New York University）和 Bard College 的學位。作為一名生長於紐約的紐約人，他有一種優越感，但足夠禮貌，將其藏在心裡。