Hackers Were Targeting Critical PHP Vulnerabilities Days Before They Were Patched

A threat actor tried to exploit two critical PHP vulnerabilities four days before the flaws were publicly disclosed and patched, according to Amazon Threat Intelligence.

The activity began on October 17, 2026, while the vulnerabilities were still under coordinated disclosure. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and known together as PHP2Shell, can allow remote code execution on affected web servers.

The early attempt was recorded by MadPot, Amazon’s network of honeypots—systems designed to attract and observe suspicious activity. It came from an IP address linked to a commercial anonymization service.

AWS said it is not clear how the actor obtained information about the vulnerabilities before disclosure, or whether the attempt would have succeeded against a real server.

Analysts from AWS also observed several more PHP2Shell attempts on October 21, before the public release of the fixes. The first proof-of-concept activity appeared around 02:00 UTC, about 12 hours before the disclosure window opened at 14:00 UTC.

The activity used different payloads and anonymized infrastructure, which AWS said may indicate several actors. Additional proof-of-concept exploits appeared after disclosure, and AWS reported that PHP2Shell was being widely exploited.

Hackers Were Targeting Critical PHP Vulnerabilities Days

The vulnerabilities affect PHP’s handling of memory and request data. CVE-2026-109618 is tied to an out-of-memory condition that can leave internal data in an incomplete state.

CVE-2026-109619 involves stale state that may remain in a long-running PHP worker and be used during a later request. In some cases, attackers may be able to use these flaws to run code remotely, without first logging in.

The PHP security team released fixes on October 21. Patched versions include PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older PHP branches may also need vendor-provided updates or an upgrade to a supported release.

Teams should check the specific package or distribution they use, as some vendors may backport a fix without changing the version number shown by the upstream PHP project.

Cybersecurity News previously covered the PHP team’s emergency patch warning, which urged administrators to prepare for the release.

A later report detailed the emergency PHP2Shell security updates. The reports describe separate stages of the same story: the advance warning, followed by the patches for the two flaws.

Why the early activity matters

A patch release does not mark the start of risk. Attackers may learn about a weakness before public disclosure, as AWS’s October 17 observation suggests.

After a fix is published, other attackers can also study the changes and develop working tools quickly. AWS said proof-of-concept exploits appeared within hours of disclosure and urged defenders not to treat the public announcement date as the earliest possible date of exploitation.

That means teams should review activity from before the patch date, not just investigate alerts generated afterward. AWS recommends starting the review from at least October 17.

Relevant checks include web server logs, unusual process launches and unexpected file changes on PHP hosts. Administrators should also look for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in form uploads.

Organizations should update PHP runtimes as soon as possible and confirm that production workers are running the fixed code.

This includes checking web servers, containers and managed hosting environments, rather than relying only on the PHP version installed for command-line use. A restart or redeployment may be needed so long-running workers stop using the old runtime.

If an immediate update is not possible, AWS suggests considering restrictions on multi-part file uploads. Such a change may affect normal application functions, so teams should assess the impact before applying it.

AWS says configuration-only changes do not fully fix both vulnerabilities; upgrading to a fixed version is the complete remediation.

For more context on reports of activity before the patch, see Cybersecurity News’ coverage of early PHP2Shell exploitation attempts.

Another report covers the public PHP2Shell testing tool. Together, these reports underline why defenders should use multiple signals and avoid depending on a single CVE-specific detection rule.

Indicators of comproise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) 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 TI Feeds with data from 16K SOCs.