PHP2Shell: The Critical PHP Security Crisis — and What AI Just Changed

PHP runs behind a large share of the public web, including many installations of WordPress, Drupal and Joomla. The issue sits below the application layer, so an application can be carefully maintained and still run on an affected PHP version.

The scale is sometimes shortened to '70% of the internet.' A more accurate reading of W3Techs data from October 21 is that PHP was detected on about 69% of websites whose server-side language could be identified. That is an enormous footprint, but it does not mean 69% of all websites were successfully attacked, or that every website uses PHP.

Businesses may also use PHP indirectly through a hosted portal, content management system or third-party product. An inventory of web-facing systems matters more than assumptions based on what the front end looks like.

According to Wiz Research, its team identified the vulnerabilities in August 2026 using a combination of security research tools and frontier AI models, including Google's Gemini and OpenAI's GPT family. OpenAI separately described work involving Calif and its Patch the Planet coordination effort. The researchers, PHP maintainers and infrastructure providers then worked toward a coordinated fix.

The responsible disclosure process culminated on October 21, when PHP released patches and European and UK cybersecurity agencies urged organizations to act immediately. Some operators temporarily removed services from public access while assessing or updating affected environments.

There is an important complication in the timeline: Amazon Threat Intelligence reported seeing an exploitation attempt in its MadPot telemetry on October 17, four days before public disclosure. Subsequent attack attempts were observed after the fixes became available. Observed attempts are not, by themselves, proof that any particular business has been breached.

The lesson is not that AI guaranteed the world a safe head start. It is that discovery, coordinated fixes and attacker activity can now unfold within an exceptionally compressed window.

Some software defects are obvious once discovered. Others have existed for years because proving their real-world impact requires deep expertise, many experiments and a great deal of time. The PHP2Shell research demonstrates how AI-assisted analysis can help security specialists navigate that complexity.

That advantage works in two directions. Defenders can use AI to examine old code, test assumptions and validate fixes more quickly. Attackers can also use increasingly capable tools to lower the cost of finding and adapting exploit paths. The same acceleration that helps expose weaknesses can make the response window shorter.

The credible takeaway is neither that AI makes software automatically secure nor that AI has made every system unsafe. It is that organizations need faster, more disciplined vulnerability management as research capabilities advance.

A critical vulnerability describes what may be possible on an affected system. It does not establish that every vulnerable server has been taken over. Risk depends on the running version, deployment configuration, exposure and whether an attacker reached the relevant conditions.

At the same time, the danger is not hypothetical. Researchers demonstrated serious exploitation paths, and threat intelligence teams reported attempts around the disclosure period. Site owners should therefore avoid both extremes: assuming compromise without evidence and assuming safety because a website still loads normally.

An update closes the known vulnerable path in the software, but it does not automatically remove malicious changes if a server was compromised before patching. That is why authorities also recommend reviewing suspicious activity and seeking incident-response help where appropriate.

First, identify every internet-facing service that runs PHP, whether it is maintained internally, hosted by an agency or included in a third-party product. Check the actual PHP runtime version with the administrator or provider rather than relying only on the website's CMS version.

Second, apply the vendor-approved fix. The PHP project lists fixed upstream releases as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older releases, including PHP 8.1 and earlier, no longer receive regular PHP-project support; where a distribution maintains backported fixes, confirm the vendor's security status rather than assuming a lower-looking package number is unpatched.

Third, ensure that a WordPress, Drupal or Joomla update is not mistaken for a PHP runtime update. Ask the host specifically whether the underlying PHP service has been patched and restarted as needed.

Fourth, review monitoring and server logs for relevant suspicious activity, especially if the site was exposed before the patch. If compromise is suspected, involve qualified incident responders; patching alone is not a substitute for containment and investigation.

Finally, where immediate patching is impossible, follow the PHP project's temporary mitigation guidance and your security provider's recommendations. Network restrictions or web application firewall protections can reduce exposure, but they are not a full replacement for a corrected runtime. For high-risk exposed systems that cannot be protected, temporarily removing access may be the safer option.

A website can be the front door to a company's bookings, payments, enquiries, customer conversations and reputation. When its underlying software becomes unsafe, the effect is not limited to a technical team: the business may need to interrupt a customer journey to protect it.

The practical questions for leadership are straightforward. Who knows which technologies power critical services? Who can approve an urgent change? Is there a tested route to apply and verify updates? Does the team know how to operate when a service must be taken offline? And can it reconstruct what happened if a problem is detected?

Businesses do not need to build a security research laboratory to act responsibly. They do need clear ownership, dependable maintenance arrangements, visibility into their critical systems and an incident-response plan proportionate to their risk.

At Orbiis, we focus on how AI and connected systems support the real operations of service businesses. The PHP incident is a reminder that automation is only as dependable as the infrastructure, permissions and processes beneath it.

Adding intelligent features to a fragile operating environment does not remove the fragility. It can create more dependencies unless the organization also defines ownership, access boundaries, human intervention, monitoring and recovery procedures.

The useful question is not how much AI a business can deploy. It is whether the systems around that AI remain understandable, accountable and resilient when something unexpected happens. Cybersecurity specialists must handle the technical security work; business leaders still own the operational consequences.

The immediate priority remains patching exposed PHP systems and reviewing signs of abuse. The longer-term issue is broader: widely used software can contain deep flaws for years, and AI is changing how quickly both researchers and attackers may bring them into view.

PHP2Shell should not be reduced to a panic headline or a simplistic debate about whether AI is good or bad for security. It is an example of why software maintenance, responsible disclosure, independent verification and operational readiness are becoming more important—not less—as AI capabilities grow.