PHP2Shell: What Website Owners Should Patch First

A flaw in PHP can turn a routine patch notice into a race across millions of websites. But the headline that the vulnerability could affect 70% of the web describes PHP's reach, not a count of confirmed compromises.

Reports from Wiz and coverage by PBS and Cybersecurity Dive describe AI-assisted discovery of critical PHP vulnerabilities under the name PHP2Shell. For site owners, the useful question is narrower: does your stack run an affected component, and can an attacker reach the vulnerable code?

What the 70% figure does and does not say

Fact: PHP is widely used to build and run websites, including through content management systems and application frameworks. W3Techs tracks server-side language usage, but a site's use of PHP alone does not establish that it runs an affected version or configuration. The PHP2Shell reporting uses a broad web-footprint estimate to describe potential reach.

That distinction matters. A vulnerability's potential scope can include websites whose owners have not yet checked their software, while the number of exploitable installations may be much smaller. Exposure depends on the affected code, the PHP release or package in use, configuration, and whether an attacker can reach the relevant functionality.

The public reporting identifies the issue as a remote-code-execution risk, a category in which an attacker may be able to make a server run unauthorized commands. That is serious, but it is not a claim that every PHP site is remotely exploitable. The precise affected versions and remediation steps should come from the PHP security announcement and the advisory for the operating system or hosting provider supplying the package.

AI found the bug; humans still have to establish the risk

Fact: The coverage attributes discovery to AI-assisted research. That is evidence that AI tools can help researchers find software defects. It does not, on its own, show that the model discovered the flaw without human direction, verified every exploit condition, or measured the number of vulnerable public servers.

Interpretation: The security consequence is less about a machine producing a clever finding than about how quickly that finding moves through the repair system. A bug report must be confirmed, affected releases identified, a fix prepared, packages built, hosting platforms updated, and site operators prompted to act. The slowest link can be a forgotten plugin or an old server image, not the discovery process.

This is why reports of AI-discovered bugs belong in the same conversation as the mechanics of software maintenance. Our earlier examination of what published evidence says about AI and security research makes a similar distinction between demonstrated capabilities and the more dramatic claims attached to them.

How to check a PHP site without guessing

Start with an inventory, not a panic-driven search for a version string. Identify every production environment that runs PHP, including staging servers, containers, managed hosting accounts, and older applications that are not part of the main deployment pipeline. Ask the hosting provider or platform team which PHP package and build are installed on each one.

Then compare that information with the official PHP security advisory and your vendor's notice. A server can report one upstream version while receiving security fixes through a distribution package, so the version label alone may not tell the whole story. If a provider manages PHP for you, ask for written confirmation of the fix and the date it was deployed.

Prioritize internet-facing systems and applications that handle logins, payments, or sensitive records. Apply the vendor's supported update, test the application, and confirm the running service has actually restarted onto the patched package. Updating a code repository without updating the live server is a familiar way to achieve the appearance of progress.

If a system cannot be patched immediately, follow the vendor's specific mitigation guidance and restrict exposure where possible. Avoid copying generic configuration changes from social media: disabling a feature or changing PHP-FPM settings without understanding the application can cause outages, and may not address the vulnerable path.

What to do if patching came late

A patch closes a route for future attacks; it does not establish whether that route was used before the fix. For a server that was exposed while vulnerable, review web-server and application logs around the relevant period, look for unexpected processes or files, and check for unusual account creation or outbound connections. Preserve logs before rotation removes them.

Escalate suspicious activity to your hosting provider or incident-response team. If there is evidence of unauthorized access, treat the server as potentially compromised rather than assuming an update has cleaned it. That may mean isolating it, preserving forensic evidence, rebuilding from a known-good image, and rotating credentials that the server could access. The response depends on the evidence and the system's role.

There is precedent for the consequences of underestimating dependencies: our reporting on supermarket cyberattacks and disrupted store operations shows how technical incidents can spill into ordinary business. A PHP issue will not automatically produce that kind of disruption, but a vulnerable server can be part of a much larger chain.

What may change after PHP2Shell

Prediction: AI-assisted vulnerability discovery will likely increase pressure on software maintainers to shorten the gap between disclosure and installed fixes. It will also increase the volume of findings that need human triage. More alerts do not equal more confirmed emergencies, and teams that treat every headline as an incident will eventually miss the one that deserves immediate attention.

For website owners, the practical response is to make PHP inventory and patch ownership routine rather than improvised. Know who can confirm the runtime version, who applies updates, and who checks that production is running them. For providers, the test is whether customers can get a clear answer about their exposure without needing to decode package-management details themselves.

The headline's 70% figure signals how much of the web could require attention if a flaw spans common PHP deployments. It does not tell any particular owner whether their site is vulnerable. That answer comes from the advisory, the actual software stack, and a verified update, a less dramatic sequence than the headline, and a more useful one.