A threat actor attempted to exploit two critical PHP vulnerabilities four days before those flaws were publicly disclosed and patched, Amazon Threat Intelligence reported.
The activity began on October 17, 2026, while the vulnerabilities were under coordinated disclosure. Tracked as CVE-2026-109618 and CVE-2026-109619 and collectively called “PHP2Shell,” the flaws can allow remote code execution on affected web servers.
Amazon recorded the early attempt using MadPot, its network of honeypots designed to attract and observe suspicious activity. The request originated from an IP address tied to a commercial anonymization service. AWS said it is not clear how the actor obtained information about the vulnerabilities before disclosure, nor whether the attempt would have succeeded against a real server.
AWS analysts observed additional PHP2Shell activity on October 21, prior to the public release of fixes. The first proof-of-concept activity that day appeared around 02:00 UTC — roughly 12 hours before the disclosure window opened at 14:00 UTC. The activity used different payloads and anonymized infrastructure, which may indicate multiple actors. More proof-of-concept exploits appeared after disclosure, and AWS reported widespread exploitation of PHP2Shell.
About the vulnerabilities
The flaws affect PHP’s handling of memory and request data. CVE-2026-109618 is associated with an out-of-memory condition that can leave internal data in an incomplete state. CVE-2026-109619 involves stale state that may persist in a long-running PHP worker and be used during a subsequent request. In some cases, these issues can be chained to achieve remote code execution without prior authentication.
The PHP security team released fixes on October 21. Patched releases include PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older PHP branches may require vendor-provided updates or an upgrade to a supported release. Teams should check the specific package or distribution they use, because some vendors may backport a fix without changing the upstream version number.
Why the early activity matters
The presence of exploitation attempts before public disclosure shows that a patch release is not the start of risk. Attackers may learn of a weakness prior to public disclosure, and after a fix is published other actors can quickly study the changes and develop working tools. AWS reported proof-of-concept exploits appearing within hours of disclosure and warned defenders not to treat the announcement date as the earliest possible exploitation date.
Defenders should review activity from before the patch date as well as after. AWS recommends beginning investigations from at least October 17. Useful checks include web server logs, signs of unusual process launches, and unexpected file changes on PHP hosts. Administrators should also search for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in multipart form uploads.
Organizations should update PHP runtimes as soon as possible and confirm production workers are running the fixed code. This includes web servers, containers and managed hosting environments — not only the PHP version used on the command line. A restart or redeployment may be required so long-running workers stop using the old runtime.
If an immediate update is not possible, consider restricting multipart file uploads as a temporary mitigation; assess the impact first because this may affect normal application behavior. AWS cautions that configuration-only changes do not fully remediate both vulnerabilities — upgrading to a fixed PHP version is the complete remediation.
Indicators of compromise (IoCs)
| IP address | Observed date |
|---|---|
| 103.216.220.92 | October 17, 2026 |
| 31.223.184.166 | October 21, 2026 |
| 37.19.200.5 | October 21, 2026 |
| 134.209.159.64 | October 21, 2026 |
| 103.114.163.188 | October 21, 2026 |
| 95.217.98.37 | October 21, 2026 |
Note: IP addresses and domains are often intentionally defanged (for example, using “[.]”) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat-intelligence platforms such as MISP, VirusTotal, or your SIEM.
Update defenses against new malware as soon as it appears. Integrate threat intelligence feeds with data from security operations centers for faster detection and response.

