PHP2Shell was probed 4 days before disclosure. Is anyone doing a look-back hunt, not just patching?

Amazon Threat Intelligence identified exploitation attempts targeting the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) in MadPot honeypots on October 17, 2026, predating the public disclosure and patch release on October 21, 2026. These attempts originated from IP addresses associated with commercial anonymization networks, indicating multiple threat actors. After the embargo lifted, proof-of-concept exploits rapidly appeared and were used against sensors. The vulnerabilities affect PHP versions prior to 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with source backports for 7.4 to 8.1. AWS recommends immediate upgrading to fixed versions as the only complete remediation. The incident underscores that exploitation can precede public disclosure and that patching alone is insufficient without retrospective investigation and detection strategies.

The PHP2Shell vulnerabilities were actively probed and exploited before public disclosure, increasing the risk of compromise for unpatched PHP installations. Exploitation attempts came from multiple anonymized sources, suggesting widespread interest and capability among threat actors. The rapid emergence of proof-of-concept exploits after the patch release shortens the window for defenders to respond. Systems running affected PHP versions are at risk of remote code execution if unpatched. The event demonstrates that attackers may exploit zero-day vulnerabilities during embargo periods, leading to potential undetected compromises.

A fix is available: upgrade immediately to PHP versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply source backports for versions 7.4 through 8.1. There are no configuration-only workarounds that fully mitigate both vulnerabilities. Organizations should conduct retrospective investigations starting from October 17, 2026, reviewing web and PHP-FPM logs for suspicious multipart and session upload-progress requests. Rotate secrets that may reside in PHP process memory due to potential memory disclosure. Identify and patch all PHP instances, including forgotten or legacy environments. Consider blocking multipart file uploads temporarily if patching is delayed, but evaluate application impact before doing so. Use threat intelligence and tools like AWS WAF to help reduce exposure during patching.