Attackers began exploiting the PHP2Shell flaws roughly four days before the issues were publicly disclosed, researcher Pierluigi Paganini says in a Q&A published by Security Affairs. Any team that treats the advisory's publication date as the starting point of its assessment is already four days behind.
The practical consequence, on Paganini's reading, is that patch service-level agreements measured in weeks no longer match the tempo of real-world exploitation. His account describes activity that began while the flaw was still unknown to the wider public, and he attributes the compressed timeline in part to AI-assisted offensive tooling that shortens the interval between a weakness becoming known to attackers and its use against live targets. Paganini treats that tooling as an accelerant rather than a new threat class. The operational response that follows is straightforward: shorter internal patch SLAs, staged virtual patching or WAF rules while a fix rolls out, and patch runbooks prepared in advance rather than assembled under pressure.
PHP remains widely deployed across mature web markets, including many SME and legacy deployments, so the guidance below applies broadly to IT teams running PHP in production. The risk profile is structural rather than exotic. A flaw sitting at the interpreter or request-handling layer ripples outward across thousands of otherwise unrelated sites, and the estates most exposed are typically those that have not migrated stacks — small shared-hosting deployments and long-lived internal applications where a single interpreter serves many virtual hosts. In a shared-hosting configuration, one vulnerable runtime can be the common denominator behind dozens of customer domains, which is why remediation at the platform layer tends to outrank per-site patching in priority.
For teams running PHP in production, a workable checklist looks like this:
- Confirm runtime versions across production, staging, container images and any managed or shared hosting accounts, including pre-built images in CI pipelines.
- Apply the vendor fix through the normal change process, prioritising internet-facing interpreters and shared-hosting platforms ahead of internal tooling.
- Deploy interim mitigation — WAF or virtual patching rules — where a full upgrade cannot be completed in the first hours after disclosure.
- Compress the patch SLA for internet-facing PHP from scheduled cycles to a matter of hours, with a named owner and an escalation path agreed in advance.
- Review logs covering the pre-disclosure window retroactively, so that compromise attempts that preceded the advisory are not missed; this becomes more actionable once indicators of compromise are published.
- Verify that no orphaned or legacy interpreters remain reachable — outdated packages on forgotten hosts are a common residue of long-running PHP estates.
Two caveats attach to this reporting. No verifiable CVE or advisory identifier has been confirmed for the issue, so this article refers to it by its reported name, PHP2Shell, rather than attaching an unconfirmed number; readers should confirm the official identifier against the vendor advisory before citing it in their own risk registers. The source's publication date should likewise be checked against the live Security Affairs page before any timeline built on it is treated as precise.
The broader point stands regardless of identifier: an advisory marks when defenders are told, not when attackers learned of the weakness. In this instance it appears to have arrived several days after exploitation had already begun. Incident-response timelines should therefore be redrawn around earliest observed activity rather than the disclosure date.
研究員 Pierluigi Paganini 在 Security Affairs 刊出的一篇問答中表示，攻擊者大約在相關漏洞公開披露前四日，就已開始利用 PHP2Shell 的缺陷。任何以安全公告發布日作為風險評估起點的團隊，實際上已落後四日。
按 Paganini 的理解，實際後果是以星期計算的補丁服務水平協議（SLA），已跟不上現實世界攻擊的節奏。他描述的攻擊活動，在漏洞仍不為公眾所知時就已經展開，並認為時間表被壓縮，部分原因是 AI 輔助的攻擊工具縮短了漏洞由攻擊者知悉到用於實際目標之間的間隔。Paganini 將此類工具視為助長因素，而非新的威脅類別。隨之而來的應對措施相當直接：縮短內部補丁 SLA、在修補程式推出期間部署階段性的虛擬補丁或 WAF 規則，以及事先預備好的補丁執行手冊，而非臨急拼湊。
PHP 在成熟網絡市場中仍被廣泛部署，包括為數眾多的中小型企業及舊有系統，因此下述指引普遍適用於在生產環境運行 PHP 的 IT 團隊。相關風險屬結構性質，而非罕見個案。位於直譯器或請求處理層的漏洞，會向外波及數以千計表面上互不相關的網站；而最受影響的系統，通常是尚未遷移技術架構的部分——包括小型共享託管部署，以及由單一直譯器服務多個虛擬主機的長年運行內部應用程式。在共享託管配置下，一個有漏洞的執行環境可能就是數十個客戶域名背後的共同源頭，這正是平台層面的修補在優先次序上往往高於逐站修補的原因。
對在生產環境運行 PHP 的團隊而言，可行的檢查清單如下：
- 確認執行環境版本，涵蓋生產、預備（staging）環境、container image，以及所有託管或共享託管帳戶，包括 CI pipeline 中的預製鏡像。
- 套用廠商修補程式，循正常變更流程處理，優先處理面向互聯網的直譯器及共享託管平台，其次才是內部工具。
- 部署臨時緩解措施——WAF 或虛擬補丁規則——適用於披露後最初數小時內無法完成全面升級的情況。
- 將面向互聯網的 PHP 補丁 SLA 由例行周期壓縮至數小時內，並事先指明負責人及訂明通報升級機制。
- 回顧披露前時間窗的日誌，以免遺漏早於安全公告的入侵嘗試；一旦各方發布入侵指標（indicators of compromise），此項工作將更具可操作性。
- 核查是否仍有孤立或舊版本直譯器可被接達——被遺忘主機上的過時套件，往往是長期運行 PHP 環境的常見殘留。
此篇報導有兩點須予註明。目前尚無已確認的 CVE 或安全公告編號，因此本文按報導所用名稱稱之為 PHP2Shell，而不附上未經確認的編號；讀者在將其列入自家風險登記冊前，應先對照廠商安全公告核實官方編號。同樣地，來源的發布日期亦應先與 Security Affairs 現行頁面核對，任何據此建立的時間線方可視為準確。
無論編號如何，核心觀點依然成立：安全公告標示的是防禦方何時獲悉，而非攻擊者何時知悉漏洞。在本次事件中，公告看來是在攻擊已經展開數日後才發出。因此，事件應變的時間線應以最早觀察到的活動為基準重新劃定，而非以披露日期為準。