PHP2Shell Patches Put Cloudflare's Network Defense to a Live Test

Two critical flaws in PHP turned a routine software update into an urgent security event for website operators. The vulnerabilities can be triggered through specially crafted web requests and may allow an attacker to crash a PHP process, expose sensitive information or execute code on a vulnerable server.

The scale is large, but the headline needs care. Cloudflare says PHP is used by almost 70% of websites. That does not mean 70% of all websites were exploitable: exposure depends on the PHP version, how the software is configured and whether an attacker can reach the vulnerable code path. The flaws affect the PHP runtime itself, which is why widely used applications such as WordPress and Magento can sit on top of vulnerable infrastructure even when their own application code is not the root cause.

Emergency fixes were released in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Government cybersecurity agencies urged administrators to update promptly. Reuters reported that some government websites were taken offline as a precaution, while the U.S. Cybersecurity and Infrastructure Security Agency said it had not observed confirmed exploitation at the time of its advisory. Cloudflare separately reported attack activity against known exploit paths, which is evidence of attempts, not proof that every request succeeded or caused data loss.

Cloudflare automatically deployed web application firewall rules for customers with its WAF enabled, including users on the free plan. A WAF inspects incoming web traffic and can block request patterns associated with an exploit before they reach the application server. That gave Cloudflare a chance to demonstrate the value of applying a protective rule across a large network quickly.

The protection has a clear limit. Cloudflare calls the rules defense in depth and tells customers to patch their PHP installations. Firewall rules target known techniques, while an attacker may find another way to reach the underlying memory-safety bug. Systems that cannot be updated promptly may need to be isolated or taken offline until they can be fixed.

For Cloudflare investors, the incident is a product demonstration, not yet a revenue event. Protecting free and paid customers can strengthen trust and retention, but there is no evidence that the emergency produced material new sales. The stock's reported one-day rise therefore should not be treated as proof of a lasting earnings benefit.

The operational priority is straightforward: identify internet-facing PHP deployments, update to a fixed release, confirm that dependent applications still work and review logs for suspicious requests. Cloudflare's rapid response can reduce exposure during that process, but the durable fix sits on the server. The next useful evidence will be confirmed exploitation data, the pace of patch adoption and whether customers convert the security response into broader paid use of Cloudflare's platform.