Attackers began targeting critical PHP vulnerabilities days before their public disclosure, and the number of attempts surged after security updates became available. The incident shows how quickly a vulnerability in widely used software can turn into a security emergency, leaving website operators racing to protect their servers.
Amazon Threat Intelligence found an attempted PHP2Shell exploit against one of its honeypots on October 17, four days before PHP released patches for the flaws. The activity came from an IP address associated with a commercial anonymisation network. Amazon said it was unclear how the attacker learned about the vulnerabilities or whether the attempt would have succeeded against a real server.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, were publicly disclosed on October 21 under the name PHP2Shell. Both have a critical CVSS score of 9.2 and could allow attackers to execute code on vulnerable servers without authentication.
The disclosure was originally planned for October 22, but details leaked online a day earlier. Screenshots spread on social media, and security researchers subsequently confirmed that the vulnerabilities were real. PHP moved its security release forward to October 21.
The early warning did not give every administrator enough time to prepare. Cloudflare said it had already deployed protective firewall rules before the public disclosure and had observed attack traffic while the vulnerability information was leaking. Its security team also saw attackers modifying their payloads in attempts to bypass those protections.
The scale of the activity became clearer after the disclosure. Cloudflare CEO Matthew Prince said the company observed thousands of attempts during the 10 hours before the vulnerabilities were publicly announced. That figure rose to tens of thousands within 45 minutes of the announcement, hundreds of thousands within two hours, and millions by 9:25 pm New York time on October 22.
These numbers represent attempts observed across Cloudflare’s network, not millions of confirmed successful attacks. Still, the rapid increase shows how quickly attackers can turn newly available vulnerability information into automated scanning and exploitation attempts.
PHP is used by nearly 70% of websites, which makes these flaws a concern well beyond WordPress. They affect the PHP runtime itself, so applications built with frameworks such as Laravel and Symfony, along with custom-coded websites and other PHP-based systems, may also be exposed.
The two vulnerabilities involve problems with memory handling inside PHP. Under specific conditions, crafted HTTP requests can trigger memory corruption or use-after-free behaviour that may lead to remote code execution or exposure of sensitive memory. The risk is especially serious because an attacker does not need a valid account before attempting exploitation.
The PHP team has released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Administrators should upgrade to the appropriate fixed release or install a security update provided by their Linux distribution or hosting vendor. PHP 8.1 and older are no longer supported upstream, although some vendors may provide backported fixes. Anyone running these older versions needs to check the status of their specific package and plan a move to a supported release.
My biggest concern is that many website owners may assume updating their application code is enough. It is not. PHP2Shell affects the runtime, so updating a plugin, framework or custom application will not fix the underlying vulnerability. The PHP installation itself must be patched, including runtimes managed through hosting panels, containers and third-party software packages.
There is another problem after patching. Updating a vulnerable server does not automatically remove malware if an attacker has already compromised it. Organisations that remained exposed during the early exploitation window should review their logs, check for unexpected changes and investigate suspicious activity rather than treating a successful update as proof that everything is safe.
The speed of this incident is also a warning about vulnerability disclosure. Coordinated disclosure gives developers and vendors time to prepare fixes, but a leak can quickly destroy that advantage. Once technical details and patches become public, attackers can study the changes and build tools to target systems that have not yet been updated.
AI tools may further shorten the time required to understand vulnerabilities and develop working exploits, although the PHP2Shell timeline alone does not prove that AI was responsible for the observed attacks. What it does prove is that administrators cannot rely on the public disclosure date as the start of the threat.
If you are the website owner, identify every PHP installation, apply the appropriate security update, and investigate possible compromise where exposure occurred. For anyone still running an unsupported PHP version, this is a good reason to stop postponing that upgrade.
If your business relies on a PHP application, now is a good time to review its security and maintenance. We at Techlomedia help businesses with PHP development, legacy application upgrades, security audits, and fixing vulnerabilities in existing web applications. If your application needs a security review or a PHP upgrade, you can get in touch with me.
