About 70 percent of all websites on the internet are running PHP versions vulnerable to the PHP2Shell flaws, the Register's security editor Jessica Lyons said — a single statistic that explains why this week’s disclosure touched so many corners of the web.
PHP2Shell: two core memory-safety bugs that span a decade
The problem, as explained on The Register's Kettle podcast, is two related memory-corruption vulnerabilities in the PHP core now being called PHP2Shell. The flaws affect releases going back to around PHP 5.4 and, by one measure, “every version that's been released in the last decade” is impacted by one or both issues. Exploitation can allow an attacker to shape PHP’s memory and achieve remote code execution — control of a host running PHP — enabling website takeover, data theft or drive-by delivery of malware to visitors.
Discovery, coordinated disclosure, leaks, emergency patches
An independent researcher first spotted the flaws in August and entered a coordinated-disclosure process with the PHP Foundation. That process “broke a little” after public leaks over a weekend and a video purportedly showing the exploit appeared online, prompting the PHP Foundation to issue an emergency warning late Monday and to release emergency patches by Wednesday. According to speakers on the podcast, some sites run such old PHP builds that they lack a direct update path and must be rebuilt or reinstalled to be protected.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleAttempts, mitigations, and an additional flaw
AWS reported exploitation attempts at least four days before the patches were released. As of the podcast’s reporting, the Foundation and security experts had seen many attempts and numerous proof‑of‑concepts — “some work, some don't” — but no confirmed successful exploitation. The PHP Foundation also disclosed a third related issue that will not receive an emergency release; it will be published in the next regular release cycle and, the Foundation said, “requires a very unlikely combination of configuration and specific PHP application code, which we do not expect to occur in practical use.”
Mitigations proposed as short-term fixes include configuration settings, but researchers from Vulncheck demonstrated an exploit that can bypass ASLR on x86 machines, undercutting the notion that simple configuration changes are an assured defense.
AI-assisted discovery: Calif, OpenAI models, Wiz, and questions about origin
Multiple security firms reported using AI-assisted techniques to find these issues. Calif, a startup in OpenAI’s partner program, used OpenAI models to help locate a vulnerability and worked with the PHP Foundation on the patch. Wiz, owned by Google, independently reported similar findings and also cooperated with the Foundation. Both companies said the vulnerabilities likely would not have been found by humans alone and have existed for decades.
On the question of how patches were produced, observers disagree: some say the work looks handwritten; others believe bots contributed. One senior developer cited on the podcast said the patch to the current PHP version was roughly 13,000 lines of C — a substantial, complex change that underscores how difficult fixing the core has become.
Why PHP’s history matters: WordPress, Facebook, and legacy entrenchment
Speakers traced PHP’s ubiquity to its origins and to large platforms built on it. Rasmus Lerdorf created PHP in the early 1990s as a tool to “program less,” originally for Personal Home Page tasks; the language later adopted the recursive name “PHP: Hypertext Preprocessor.” Two widely used platforms — WordPress and Facebook — are cited on the podcast as major reasons PHP remains so pervasive: WordPress powers a huge share of sites, and Facebook invested heavily in performance and tooling for PHP. The result is a sprawling, interdependent web ecosystem where “legacy servers” and old deployments remain exposed.
What this means for security teams, local governments, and WordPress-hosted sites
- Security teams and technologists: expect a flurry of attempted exploits and many proof‑of‑concepts; emergency patching and audit of PHP deployments remain urgent because mitigation is nontrivial and some fixes require rebuilding or reinstalling older stacks.
- Local and state governments, small operators, and lone IT administrators: many public-facing servers run legacy PHP with no automatic update path; some administrators may be unaware of the advisory and will need guidance to apply emergency patches or rebuild vulnerable stacks.
- Sites built on WordPress and other common PHP frameworks: their large footprint means they are part of the exposed majority; operators should treat the PHP Foundation patches and mitigations as priority tasks, while noting that configuration mitigations may not be foolproof against advanced bypasses such as the ASLR technique shown by Vulncheck.
In short, this episode of discovery — a blend of decades-old code, AI-assisted research, and large emergency patches — has exposed a brittle web of legacy choices. The PHP Foundation’s emergency response and cooperation with multiple firms bought time; whether the patching pace, the complexity of fixes, and the persistence of legacy deployments will be enough to prevent successful widespread exploitation remains the practical question left by these facts.