PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure
PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure
Someone tried to exploit two critical vulnerabilities in the PHP programming language four days before the vulnerabilities were published and the flaws are now being exploited in the wild at scale, according to Amazon. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively known as ‘ PHP2Shell ,’ could allow unauthenticated remote code execution (RCE) and server takeover on…
Vulnerabilities mentionedAll →
- CVE-2026-1096199.26%PHP has various global state that temporarily points into request memorypublished · php php PoC ×7+1 related
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-109619 |
Full article805 words · extracted from infosecurity-magazine.com · click to collapse
Someone tried to exploit two critical vulnerabilities in the PHP programming language four days before the vulnerabilities were published and the flaws are now being exploited in the wild at scale, according to Amazon.
The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively known as ‘PHP2Shell,’ could allow unauthenticated remote code execution (RCE) and server takeover on any websites relying on any PHP version released in the last decade – going back to version 5.4.
PHP is used by approximately 69.7% of websites whose server-side programming language is known, according to recent W3Techs data. These include many content management systems (CMS) like WordPress, Drupal, Joomla and Magento as well as e-commerce and web services platforms.
The bugs were discovered by security researchers at California-based security firm Calif and Google Cloud’s Wiz, with collaboration from OpenAI’s Patch the Planet project, in August. Public disclosure was scheduled for October 21, when the PHP Foundation planned to release the security patches.
However, on October 20, a pseudonymous user of the Hacker News forum leaked some information about the flaws before the patches were ready.
This led to many organizations across the world, including French public administrations, the Dutch National Cyber Security Centre and the University of Vienna taking their websites offline to prepare for and then apply the patches.
Now the patches have been released, the Amazon Threat Intelligence team has publically confirmed they observed a PHP2Shell exploitation attempt dating October 17. The attempt occurred in MadPot, an internal honeypot system created by Amazon Web Services (AWS) to monitor, study and disrupt global cybercrime.
Early Exploitation Attempt Likely From A “Threat Actor”
The exploit attempt originated from an IP address associated with a commercial anonymization network. According to the Amazon researchers, this suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure.
In addition, they said they identified multiple proof-of-concept (PoC) exploits for PHP2Shell on October 21, around 12 hours before the vulnerability’s scheduled disclosure at 2pm GMT.
The earliest exploit was detected at approximately 2am GMT, with further attempts targeting the company’s MadPot sensors between 2am and 8am GMT from additional infrastructure.
According to the researchers, variations in the payloads and anonymization infrastructure suggested that multiple threat actors were involved. However, it was unclear whether the attempts would have succeeded against real-world systems.
Further PoC exploits emerged within hours of the release of the PHP2Shell patches, which were used against Amazon’s sensors almost immediately.
The researchers warned that PHP2Shell is now being broadly exploited in the wild.
Emerging Evidence of PHP2Shell Exploitation Attempts
Other security and threat intelligence teams have started to report active exploitation attempts of CVE-2026-109618 and CVE-2026-109619 in the wild.
Matthew Prince, co-founder and CEO of Cloudflare, said on X his company saw “thousands of attempts to exploit” the vulnerabilities within the 10 hours that preceded the disclosure.
“That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within two hours, and millions now,” he added.
Other security firms, including Beelzebub, Ellio, Recorded Future, VulnCheck, WatchTowr and Wiz have also observed evidence of exploitation attempts in the wild for both vulnerabilities.

However, whether these exploitation attempts have been successful in a real-world cyber-attack remains to be seen.
Several security experts, including independent researchers, also released PoC exploits for the research community. These can equally be used by attackers to target unpatched and vulnerable PHP versions.
PHP2Shell: Patching and Mitigation Recommendations
Organizations running affected versions of PHP are urged to apply available security patches immediately. The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP states that updating is the only complete fix for the two vulnerabilities.
However, official patches are available only for supported PHP branches, meaning versions 8.2 and later.
Organizations running PHP 8.1 or earlier, including all PHP 7 and PHP 5 releases, will not receive official fixes and are advised to migrate to a supported version as a matter of urgency.
For organizations unable to patch immediately, additional security measures can help reduce exposure.
These include:
- Disabling vulnerable functionality where applicable
- Restarting PHP workers after configuration changes
- Strengthening perimeter defenses by restricting unnecessary multipart/form-data requests and enforcing limits on request body sizes, multipart sections and headers
These mitigations can reduce risk but do not replace patching. Organizations should also maintain appropriate resource limits to help prevent memory exhaustion.
Some vendors have introduced security hardening measures to protect customers against PHP2Shell. Cloudflare, for example, said customers using its free or paid web application firewall (WAF) were protected by default against the vulnerability.
Nevertheless, organizations should verify their own security controls and prioritize upgrading to a fixed PHP release wherever possible.
Image credit: ODE.Studio / Shutterstock.com