Amazon's Threat Intelligence team detected the activity and described the finding to The Hacker News: its MadPot honeypot service logged an attempt to exploit the newly disclosed PHP2Shell vulnerabilities on 17 October 2026 — four days before the flaws were publicly disclosed on 21 October. Since the patches were released, exploitation of the vulnerabilities has spread widely in the wild.
The pre-disclosure timing is the substance of the story. Scanning after an advisory drops is routine; an exploit attempt landing before anyone outside the vendor and the researchers knows the flaws exist implies either advance knowledge of the weaknesses or independent reverse-engineering of the underlying code. Either way, whoever was probing had something most defenders did not.
"The exploit attempt originated from an IP address associated with a commercial anonymization network," CJ Moses of Amazon said, according to The Hacker News. Amazon declined to name the network.
That detail cuts in two directions at once. Leasing a commercial proxy or VPN service suggests a deliberate actor who took steps to obscure origin — not an opportunistic scanner stumbling on a leaked credential. But shared subscriber pools in such services make source-level attribution effectively impossible: the address in the logs may belong to anyone renting from the same provider. Amazon has not linked the source to any named group, and this report does not either.
Why the window matters
For four days, before any patch existed, defenders had no CVE identifier, no detection signatures, and no vendor guidance. That gap is where defenders are structurally least prepared: the vulnerabilities are known to someone, but not to the people who would need to respond. Amazon's disclosure implies that at that point the only parties aware of the flaws were the attacker and the honeypot.
Honeypot telemetry surfaces this class of activity first precisely because the sensors have no legitimate users — every connection is suspicious by definition. Production environments lack that luxury, which is why activity observed in a honeypot should be treated as a floor, not a measure, of real-world exposure.
What remains unconfirmed
Amazon's disclosure does not state a CVE identifier or the affected PHP versions; both must be confirmed against the official vendor advisory, which readers should treat as the authoritative source. It is also unconfirmed which specific PHP2Shell weakness was probed on 17 October, whether any stage of the exploit chain succeeded against the honeypot, whether other Amazon customers observed related activity, and whether the anonymized source has been connected to the broader wave of exploitation that followed the patch release. Any of those details, if released, would materially change the picture.
Patching checklist for SME and LAMP/cPanel deployments
The following is general operational guidance for small and medium operators running PHP-based stacks — it is not drawn from Amazon's disclosure:
- Patch every PHP runtime across all instances and shared-hosting accounts, not just internet-facing ones; confirm version numbers rather than trusting auto-update flags.
- Reduce PHP endpoint exposure: disable execution in upload directories, remove sample and test scripts, and retire unused applications.
- Audit cPanel/WHM and control-panel PHP handler settings, including per-account version overrides that frequently lag behind.
- Review reverse-proxy and WAF rules for known post-disclosure scanning patterns, and prioritise behavioural detection — anomalous request sequences, unexpected file writes — over IP blocking, since anonymized source addresses cannot be reliably filtered; retain web-server access logs long enough to compare against post-disclosure indicators.
The bottom line
The PHP2Shell patches mark the start of remediation, not the end of exposure, and the pre-advisory window shows how much activity can occur before defenders are told what to look for. Amazon's honeypot caught one attempt four days early. How many it did not catch is unknown.
Amazon 威脅情報團隊偵測到相關活動，並將發現告訴 The Hacker News：其 MadPot 蜜罐服務於 2026 年 10 月 17 日記錄到一次利用新披露 PHP2Shell 漏洞的嘗試——較漏洞於 10 月 21 日公開披露，早了四日。自補丁發布以來，相關漏洞在野外的利用已廣泛蔓延。
披露前的時間點正是這則報道的核心。在安全公告發出後進行掃描屬常態；但在廠方與研究人員以外無人知悉漏洞存在之時便已出現利用嘗試，意味著攻擊者不是事先知悉該弱點，就是自行對底層代碼進行逆向工程。無論如何，進行探測的一方擁有大多數防禦者所沒有的資訊。
據 The Hacker News 報道，Amazon 的 CJ Moses 表示：「該利用嘗試源自一個與商業匿名網絡相關聯的 IP 地址。」Amazon 拒絕透露該網絡的名稱。
這細節同時指向兩個方向。租用商業 proxy 或 VPN 服務，顯示是有行動者刻意隱藏來源——而非 opportunistic scanner 偶然發現外洩憑據。但此類服務的共享用戶池令來源層面的歸因實際上不可能：日誌中的地址可能屬於任何向同一供應商租用服務的用戶。Amazon 未有將來源連結至任何具名組織，本報道亦然。
為何該時間窗口重要
在四日期間，任何補丁尚未推出，防禦者沒有 CVE 編號、沒有偵測特徵，亦沒有廠方指引。這正是防禦者在結構上最無準備的空檔：漏洞確實有人知悉，但知悉者並非需要作出回應的人。Amazon 的披露顯示，在該時刻知悉漏洞的只有攻擊者與蜜罐。
蜜罐遙測之所以最先浮現這類活動，正因其 sensor 沒有合法用戶——每一個連線按定義而言都屬可疑。生產環境並無此奢侈條件，這正是為何蜜罐觀察到的活動應被視為實際暴露面的下限，而非量度。
尚未確認的事項
Amazon 的披露並未列明 CVE 編號或受影響的 PHP 版本；兩者均須對照官方廠方公告確認，讀者應視其為權威來源。另外仍未確認：10 月 17 日探測的究竟是哪一項 PHP2Shell 弱點、利用鏈的任何階段是否成功攻破蜜罐、是否有其他 Amazon 客戶觀察到相關活動，以及該匿名化來源是否與補丁發布後蔓延的更大規模利用浪潮有關。上述任何細節一旦公布，都會實質改變整體形勢。
中小企及 LAMP/cPanel 部署的修補清單
以下為營運 PHP 技術堆疊的中小企的一般操作指引——並非取自 Amazon 的披露：
- 為所有實例及共享主機帳戶的 PHP runtime 逐一安裝修補程式，不限於對外開放者；須核實版本號碼，而非依賴自動更新標記。
- 減低 PHP endpoint 暴露面：在上載目錄停用執行功能、移除範例及測試腳本、淘汰未使用的應用程式。
- 審核 cPanel/WHM 及控制面板的 PHP handler 設定，包括經常滯後的各帳戶版本覆蓋設定。
- 檢視 reverse proxy 及 WAF 規則是否涵蓋已知的披露後掃描模式，並優先採用行為偵測——異常請求序列、預期以外的文件寫入——而非 IP 封鎖，因為匿名化來源地址無法可靠過濾；保留 web server 存取日誌足夠長時間，以便與披露後指標比對。
總結
PHP2Shell 補丁標誌著補救工作的開始，而非暴露的終結；披露前的時間窗口顯示，在防禦者獲告知應搜尋什麼之前，可以發生多少活動。Amazon 的蜜罐提早四日截獲一次嘗試。它沒有截獲多少次，則無人知曉。