AI-assisted research has exposed critical weaknesses in PHP, software used to run websites worldwide, prompting emergency updates and protective shutdowns while showing how faster vulnerability discovery can leave businesses with less time to respond.
What Has Been Discovered?
The vulnerabilities, collectively known as PHP2Shell, affect PHP itself, rather than a particular website or plug-in. PHP runs on web servers, handling tasks such as retrieving database information and generating pages for systems including WordPress, Drupal and Joomla.
Researchers demonstrated that the weaknesses could allow attackers to run commands on affected servers or read sensitive information from memory. Some attacks require no login, although their success depends on the server’s configuration and the particular weakness involved.
That makes the problem relevant even to businesses whose websites appear well maintained. Updating content, themes and plug-ins doesn’t necessarily update the underlying software supplied by a hosting company.
How Did AI Help?
Researchers at cybersecurity firm Calif and cloud security company Wiz used AI to investigate how PHP handles memory and errors, helping turn weaknesses into working demonstrations. Calif began its investigation on 30 July and reports its first significant finding on 1 August, while Wiz records discoveries later that month.
The speed is striking, but human expertise remained important. Calif explains that knowledge of earlier PHP vulnerabilities helped guide the investigation towards promising areas. AI helped researchers examine those possibilities rather than independently deciding everything that needed checking.
The development is therefore more significant than simply finding bugs faster. AI can help establish how seemingly difficult weaknesses might be combined into practical attacks, giving defenders useful evidence while potentially lowering the same barriers for criminals.
Why Were These Problems Still There?
Related memory-handling concerns have a long history, but that does not mean the current vulnerabilities were fully understood decades ago. The PHP Foundation says signs of one problem emerged during work following a 2024 security audit, when a practical attack had not been demonstrated.
Repairing it also involved some difficult choices. For example, proposed changes risked breaking compatibility, creating other security problems or requiring alterations across third-party extensions. Also, limited specialist resources and difficulty reaching decisions delayed progress.
The Foundation describes that delay as “a structural failure”, acknowledging weaknesses in both its decision-making and resources. This explains why discovering a problem is only part of securing software: someone must also develop, test and deliver a repair that users can safely install.
What Has Happened Since?
Thankfully, emergency PHP updates arrived on 21 October, triggering urgent work across hosting providers and website operators. For some organisations, reducing exposure meant temporarily withdrawing services while repairs were arranged.
Wikimedia said it deliberately took supporting services offline, including tools maintained by volunteer developers. Restoration depended partly on reaching individual service owners and updating installations that central staff could not change themselves. These shutdowns demonstrate the disruption caused by emergency maintenance, without establishing that the affected services were hacked.
Attack activity has also been reported. For example, AWS says its monitoring systems detected exploitation attempts from 17 October, before public disclosure, although it could not establish whether those attempts would succeed against real systems.
Separately, Unit 42’s updated threat brief reports attackers obtaining password hashes and multi-factor authentication secrets from a European government entity during post-exploitation activity. Such reports warrant attention, but neither attack attempts nor estimates of exposed systems establish that millions of websites have been compromised.
What Needs Updating?
The releases addressing the original two vulnerabilities are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Providers maintaining their own supported packages may supply equivalent fixes, so businesses should seek confirmation that their particular installation is protected.
A further related vulnerability was announced on 23 October. It requires an unusual combination of settings and is scheduled for a regular release. Its discovery reinforces the need to follow subsequent guidance, rather than showing that the original emergency repairs were ineffective.
As far as WordPress is concerned, it says no WordPress update is required for these issues. The PHP installation underneath it needs attention, usually through the hosting provider.
What Does This Mean For Your Business?
Businesses should establish which websites and applications depend on PHP, who maintains them and whether the relevant fixes are running. Asking whether the website is updated may produce reassurance about plug-ins while leaving the underlying problem unanswered.
Where protection cannot be applied promptly, the NCSC recommends considering taking affected systems offline. Suspected compromise also requires investigation, because installing an update does not remove access an attacker may already have established.
The next challenge will be completing updates, restoring services and checking for intrusions while researchers examine further weaknesses. Businesses should expect guidance to develop and ensure someone follows it through.
The wider lesson is that AI can make longstanding software safer, but finding vulnerabilities faster also increases pressure on those responsible for repairs. Clear ownership, responsive suppliers and confirmation that fixes are working will determine whether that faster discovery improves protection or leaves businesses struggling to catch up.
