```
PHP2Shell exploited four days before patches shipped, Amazon threat intel warns
Researchers at Amazon Threat Intelligence say attackers began exploiting flaws in PHP2Shell four days before the security patches were released on Wednesday, 21 October. Writing on 22 October, BleepingComputer described the four-day window as turning a routine advisory into an incident signal that warrants immediate attention.
For teams running PHP sites, the gap matters for a simple reason: patch day was not the start of the attack, but the latest point at which a compromise could have occurred. Attackers had four full days to scan, implant and establish persistence before fixes arrived. Installing the patch closes the door — it does not evict an intruder already inside.
Why the four-day window changes the response tempo
That Amazon was able to trace exploitation back to four days before the patches points to telemetry on scanners and attack payloads — a sensing capability most small and mid-sized organisations do not have. Vendor threat intelligence reports of this kind effectively act as an early-warning layer, filling a gap where private detection coverage is absent. BleepingComputer quoted Amazon Threat Intelligence as confirming that exploitation of the PHP2Shell flaws predates the patch release.
The retrospective log review scope highlighted in the report
The BleepingComputer report also notes that defenders must reach backwards across the entire pre-patch window rather than only checking records from after the fixes shipped:
- Scanning and probing artefacts: abnormal HTTP requests during the window, bulk attempts against PHP endpoints.
- Web shells and file integrity: newly added or recently modified files in writable directories (upload folders, tmp, plugin paths).
- Persistence mechanisms: changes to crontab entries, system services, plugins or backdoor accounts.
- Outbound connections: connections to unfamiliar addresses made during the window.
Patch sequencing and compensating controls
The security guidance cited by the report argues that, across large estates, internet-facing and shared-hosting PHP instances should be prioritised first, since they face the widest exposure and are most likely to be hit by scanners. Teams should also verify that automatic updates are genuinely applying — many Linux distributions pin the PHP version in their own package repositories, and updates often lag upstream, so "auto-updates enabled" does not equal "patch applied." Where patching cannot be completed in the short term, compensating controls such as WAF virtual patching or restricting the relevant endpoints at the proxy layer can hold the line in the meantime. Sites that depend on a hosting or managed-service provider should check with the supplier on relevant security advisories to confirm whether PHP in shared environments has been updated.
In the end, the patch closes the door, but only a log review confirms whether anyone had already walked through it. The intelligence carries equal weight for Hong Kong's PHP development and operations teams: the four-day window is a reminder that waiting for patches is not, on its own, a complete strategy.
PHP2Shell 在修補程式發布前四天已遭利用，Amazon 威脅情報示警
Amazon Threat Intelligence 研究人員指出，攻擊者早在安全修補程式於 10 月 21 日（週三）發布前四天，就已開始利用 PHP2Shell 的相關漏洞。BleepingComputer 於 10 月 22 日的報導形容，這段四天窗口把一則例行安全通告轉化為必須立即處理的事件訊號。
對營運 PHP 網站的團隊而言，這個時間差意義重大，原因很簡單：修補程式發布日並非攻擊的起點，而是妥協可能發生的最晚時點。在修補程式到達之前，攻擊者有整整四天時間進行掃描、植入及建立持久性機制。安裝修補程式只是關上大門，並不會把已經在內的入侵者請走。
為何四天窗口改變了應對節奏
Amazon 能夠把利用起點回溯到修補程式發布前四天，反映出其擁有針對掃描器與攻擊載荷的遙測數據——這是多數中小型機構並不具備的感測能力。此類廠商威脅情報報告實質上充當了早期預警層，在私人偵測覆蓋不足之處填補空缺。BleepingComputer 引述 Amazon Threat Intelligence 的說法，證實 PHP2Shell 漏洞的利用活動早於修補程式發布。
報道點出的回溯日誌審查範圍
BleepingComputer 的報導同時指出，防守方必須把審查範圍回溯至修補程式發布前的整段窗口，而非只檢查修補程式發布後的記錄：
- 掃描與探測痕跡：窗口期間的異常 HTTP 請求、針對 PHP 端點的批量嘗試。
- Web shell 與檔案完整性：可寫目錄（上傳目錄、tmp、外掛路徑）是否出現新增或近期修改的檔案。
- 持久性機制：crontab 條目、系統服務、外掛或後門帳號的異動。
- 出站連線：窗口期間連往陌生位址的對外連線。
修補次序與補償性控制
報導援引的安全指引認為，在大規模環境之中，應優先處理對外開放（internet-facing）及共享主機（shared hosting）環境下的 PHP 執行實例，因為它們暴露面最廣，亦最易被掃描器命中。團隊同時應確認自動更新確在實際執行——不少 Linux 發行版會在自家套件庫中鎖定 PHP 版本，更新往往落後上游，「已啟用自動更新」並不等於「已套用修補」。短期內無法完成修補者，可先以 WAF 虛擬修補（virtual patching）或在 proxy 層限制相關端點等補償性控制穩住陣腳。依賴主機商或託管服務的網站，則應向供應商核對相關安全公告，確認共享環境中的 PHP 是否已更新。
最終，修補程式關上了門，但只有日誌審查才能確認是否早已有人走過那道門。這則情報對香港的 PHP 開發與營運團隊同樣重要：四天窗口提醒我們，單靠「等修補程式」並不是一個完備的策略。