Security Incidents

PHP2Shell: A Decade of Vulnerable Code Puts 70 Per Cent of Websites at Risk

Two memory-safety flaws in PHP core—affecting every version back to 5.4—have triggered emergency patches, exploitation attempts, and a broader reckoning with the internet’s ageing foundations.

AI-generated illustration depicting incident for the story: PHP2Shell: A Decade of Vulnerable Code Puts 70 Per Cent of Websites at Risk

Summary

  • Two memory-corruption vulnerabilities in PHP core, collectively known as PHP2Shell, affect an estimated 70 per cent of websites and every PHP version released over the past decade, back to approximately version 5.4.
  • The PHP Foundation released emergency patches on Wednesday following coordinated disclosure that broke down over the weekend; AWS reported exploitation attempts at least four days before patches were available.
  • As of Friday, no successful exploitation had been confirmed, though the attack chain is complex and researchers—including AI-assisted teams from Calif and Wiz—continue to develop proof-of-concept exploits.
  • A third vulnerability has since been disclosed by the PHP Foundation; it will not receive an emergency patch but can be mitigated via configuration changes, and it requires an unlikely combination of settings to exploit.
  • Legacy PHP installations—particularly in government and smaller organisations—have no straightforward patch path and remain exposed indefinitely.

What happened

An independent researcher first identified the vulnerabilities in August. A coordinated disclosure process with the PHP Foundation followed, but that process broke down over the weekend when a video purporting to demonstrate exploitation was leaked. The Foundation issued an emergency warning late Monday and released patches by Wednesday. The two flaws are memory-corruption vulnerabilities in PHP core; by manipulating memory that PHP trusts, an attacker can hijack execution and achieve remote code execution, data theft, or malware delivery to site visitors.

Scale of exposure

The PHP Foundation and security researchers place the affected share of all websites at roughly 70 per cent—every version released over the approximately ten years prior, starting around version 5.4, is affected by one or both flaws. That figure includes not just purpose-built PHP applications but the vast ecosystem of content-management systems, most prominently WordPress, that run on PHP underneath. Services ranging from online games to government portals were taken offline or degraded while operators scrambled to apply patches.

The legacy problem

Not every operator can patch. Sites running significantly older PHP versions have no direct upgrade path; remediation requires taking the service down and rebuilding. The Register’s reporting makes clear that local governments, smaller agencies, and organisations without dedicated security staff are the most likely to remain exposed for months or years. AWS disclosed that exploitation attempts began at least four days before patches were released, meaning unpatched systems have already been probed. As of Friday, no successful attack had been confirmed, but researchers noted the complexity of the attack chain is slowing—not preventing—successful exploitation.

A third vulnerability emerges

While patching was still under way, the PHP Foundation disclosed a third related vulnerability. The Foundation characterised it as requiring a very unlikely combination of configuration and specific application code, and said it does not expect the conditions to arise in practical use. It will be addressed in the next regular release cycle rather than via an emergency patch. However, researchers at Vulncheck separately demonstrated that even the ASLR mitigation can be bypassed on x86 machines when exploiting the original two flaws, a reminder that configuration-based mitigations carry their own limits.

AI found what humans missed

Two organisations independently used AI-assisted analysis to identify these vulnerabilities: Calif, an AI penetration-testing startup working with OpenAI models, and Wiz, which is owned by Google. Both have stated the vulnerabilities would likely not have been discovered by human researchers working alone, and appear to have existed undetected for years. The same AI capability that surfaced these flaws is now being applied by threat actors attempting to build working exploits—a dynamic that compresses the window between discovery and weaponisation. The patch for the current PHP version alone runs to approximately 13,000 lines of C, according to commentary cited in The Register’s reporting.

A structural question

PHP was not originally designed as a production programming language. Its creator, Rasmus Lerdorf, has described building it as a personal tool in the early 1990s to reduce his own coding workload, without formal language-design expertise. The language grew through necessity and adoption rather than architectural planning, and its reach today is largely a function of Facebook’s decades of investment and WordPress’s dominance of the CMS market. The Register’s reporting describes the codebase as something no single person fully understands, and notes that AI tooling is now being pointed at it systematically—making further vulnerability discovery likely.

Why it matters

For CISOs, PHP2Shell is less a single incident than a stress test of your organisation’s PHP inventory, patch velocity, and legacy system governance. If you do not have a current and accurate picture of every PHP-dependent application in your environment—including third-party platforms, government portals you depend on, and vendor-supplied CMSes—this is the moment to get one. The exploitation attempts are real, the attack chain is being refined with AI assistance, and a subset of your estate may have no patch available at all. Beyond the immediate response, this episode illustrates the structural risk of critical services built on decades-old code that is poorly understood even by its maintainers.

What to do now

  • Audit all PHP-dependent applications and services in your environment, including third-party and vendor-supplied platforms, and record their current PHP version.
  • Apply the PHP Foundation’s emergency patches immediately to any instances running affected versions; prioritise internet-facing and data-handling systems.
  • For legacy PHP versions with no direct patch path, assess whether those services can be taken offline, isolated, or placed behind additional controls while a rebuild is planned.
  • Apply the configuration-based mitigation for the third disclosed vulnerability on any systems where the relevant configuration cannot yet be updated.
  • Monitor threat intelligence feeds for indicators of successful exploitation, given that exploitation attempts preceded patch availability by at least four days.
  • Brief stakeholders on the likelihood of a long tail of exposure, particularly for systems operated by third-party government agencies or suppliers whose patching timelines you do not control.

Sources

Related Posts