AWS detected PHP2Shell exploit attempts four days before disclosure, highlighting the risk of attackers exploiting critical flaws before patches arrive.
Attackers attempted to exploit two critical PHP vulnerabilities four days before the flaws became public, according to Amazon Threat Intelligence.
“Amazon Threat Intelligence identified a PHP2Shell exploitation attempt dating to Oct. 17, 2026, in MadPot telemetry, four days before public disclosure of CVE-2026-109618 and CVE-2026-109619.” reads the report published by Amazon team.”The exploit attempt originated from an IP address associated with a commercial anonymization network. While the vulnerability was under embargo, the targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure.”
The activity began on October 17, 2026, and appeared in telemetry from MadPot, AWS’s network of honeypots designed to attract and study malicious activity. The company said the first attempt targeted a honeypot from an IP address linked to a commercial anonymization network. The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, were still under embargo at the time.
AWS believes the use of anonymized infrastructure suggests a threat actor was behind the activity. However, the company hasn’t established how the attacker obtained information about the vulnerabilities before their public disclosure, nor has it confirmed that the early attempts would have succeeded against real-world systems.
The first attempt wasn’t an isolated event. AWS detected multiple proof-of-concept exploits on October 21, with the earliest appearing at around 02:00 UTC, roughly 12 hours before the scheduled public release and patch at 14:00 UTC.
Between 02:00 and 08:00 UTC that day, AWS observed further attempts against MadPot from additional anonymized infrastructure. The payloads and anonymization services varied, leading the company to suspect that multiple actors were involved.
After the embargo ended and PHP released the fixes, more proof-of-concept exploits appeared within hours. AWS reported that attackers used them against its sensors almost immediately, describing PHP2Shell as being broadly exploited in the wild.
The findings show why the date of a public security advisory can’t always serve as the starting point for an incident investigation. In this case, defenders had to account for activity that began before they could publicly identify the vulnerabilities.
“The actual payloads and choices in anonymization infrastructure varied, suggesting these were multiple actors.” continues the report. “Technical analysis is ongoing, and it’s unclear if any of these attempts would have succeeded in real-world systems.”
PHP2Shell refers to two critical flaws in the PHP runtime that can allow unauthenticated remote code execution. An attacker may be able to send a specially crafted web request and run commands on a vulnerable server without first logging in.
PHP published fixes on October 21. The corrected releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, according to the official PHP security notice.
The vulnerabilities affect PHP itself, rather than a specific website application. As a result, updating WordPress, Drupal or another application won’t fix the underlying problem if the server continues to run a vulnerable PHP runtime.
AWS says there is no configuration-only workaround that fully addresses both flaws. Organizations should install the fixed PHP version as soon as possible and check whether their hosting provider, operating system vendor or container image has supplied the necessary update.
For systems that can’t be patched immediately, AWS suggests considering whether blocking multipart file uploads is practical. Administrators should assess the impact on their applications before applying that restriction, and they shouldn’t treat it as a replacement for installing the fixes.
AWS recommends reviewing web server logs for suspicious requests, particularly POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string in multipart form data. Security teams should also look for unexpected processes launched by PHP and unexplained changes to files on web application servers.
These checks matter because an attack may leave evidence beyond the original HTTP request. Unexpected command interpreters, newly created files or unusual process activity can help investigators determine whether an attacker progressed beyond probing a vulnerable endpoint.
AWS also published six IP addresses associated with observed activity:
103.216.220.92, observed on October 1731.223.184.166, observed on October 2137.19.200.5, observed on October 21134.209.159.64, observed on October 21103.114.163.188, observed on October 2195.217.98.37, observed on October 21
These addresses require careful handling. AWS warns that some belong to shared anonymization infrastructure and aren’t exclusive to PHP2Shell activity, so organizations should investigate matching events rather than automatically blocking every address.
The Cloudflare analysis of PHP2Shell provides additional context. Cloudflare said it had deployed web application firewall protections before public disclosure and had already observed attack traffic targeting its customers, including attempts to change payloads to evade those protections.
A web application firewall can help reduce exposure, but it doesn’t replace patching. Defenders should combine updated software with log analysis, process monitoring and checks for suspicious file changes.
AWS draws a broader lesson from the incident: organizations shouldn’t assume that exploitation begins only after a vulnerability becomes public. The October 17 activity shows that attackers may obtain or develop exploit information while a flaw is still under coordinated disclosure.
Attackers are using AI to develop exploits faster, sometimes within hours of a patch being released. Security teams need to patch critical systems quickly and investigate attacks from the earliest known date. For PHP2Shell, AWS recommends checking logs and activity from October 17 onward, including suspicious behavior that detection tools may not yet recognize.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, PHP)
Source: SecurityAffairs
Source Link: https://securityaffairs.com/201479/hacking/php2shell-attacks-started-four-days-before-public-disclosure-aws-reports.html