PHP2Shell: What Happens Behind the Scenes When a Critical Vulnerability Is Announced

On 21 October 2026, two critical vulnerabilities in PHP, collectively referred to as PHP2Shell, made headlines around the world.

Both vulnerabilities could potentially allow an attacker to execute code remotely on affected servers without authentication. With severity ratings of 9.2 out of 10, they were being taken seriously by security organisations and hosting providers.

PHP is no stranger to security vulnerabilities. Over the years, it has become something of a poster child for web security issues, although it’s worth remembering that many of those vulnerabilities relate to applications written in PHP rather than PHP itself.

What made PHP2Shell unusual was the level of attention it attracted outside the usual technology and security communities.

We saw coverage from the BBC and Sky News . National cybersecurity agencies issued warnings, and several government organisations took websites offline as a precaution while waiting for the security patches.

Most customers following the incident would have seen the warnings and updates published on our status page .

What they wouldn’t necessarily have seen was the work going on in the background.

We thought this would be a good opportunity to explain how we monitor emerging security threats, how we responded to PHP2Shell and how the work we’ve done on infrastructure management and automation helps us protect our customers’ services.

Security Monitoring Goes Beyond Vendor Advisories

We have a security team whose responsibilities include monitoring the wider cybersecurity threat landscape, identifying emerging threats and assessing how they might affect our infrastructure.

We use a combination of security monitoring tools, vulnerability intelligence services and other sources to keep track of what is happening.

Official vendor security advisories are obviously important, but they are only part of the picture.

We also follow independent security researchers, specialist forums and cybersecurity communities where vulnerabilities, potential exploits and mitigation techniques are discussed.

These communities can sometimes provide information before detailed technical advisories are published. They can also be useful after a vulnerability has been disclosed, particularly when researchers start examining how it might be exploited or whether the recommended mitigations are effective.

Of course, not everything published online is reliable. There is often speculation, incomplete research and occasionally information that is simply wrong.

Our security team has to assess the credibility of that information, understand its relevance to our environment and decide whether any action is necessary.

This is an ongoing process, not something that starts when a critical vulnerability makes the news.

The Initial PHP2Shell Warning

Ahead of the security release on 21 October, the PHP development team announced that two critical vulnerabilities had been identified and that emergency security updates would be released.

At this stage, the technical information available publicly was limited.

We knew the vulnerabilities could potentially allow remote code execution, but the official patches were not yet available and the full technical details had not been disclosed.

Our initial customer advisory was published on the morning of 21 October, advising that we were monitoring the situation and preparing for the security release.

In the background, our security and technical teams were reviewing the available information and considering what could be done to reduce the risk before the patches became available.

Waiting for the official security release was one option, but we also needed to consider whether there were measures we could take in the meantime.

Acting on the PHP Security Team’s Mitigation Guidance

One of the more useful developments was that the PHP project itself published recommended mitigation measures for systems that could not immediately be patched.

These included changes to PHP configuration and restrictions on certain types of requests, intended to reduce the risk of exploitation through known attack methods.

Our team assessed the recommendations immediately, including their possible impact on the different PHP versions and server configurations in use across our infrastructure.

Once we had established which measures were appropriate, we used our existing in-house server intelligence, infrastructure management and automation tools to identify the relevant systems and deploy the changes across our shared hosting platform and managed server infrastructure.

Additional Protection Through Web Application Firewalls

Alongside the PHP project’s recommended mitigations, additional protections were made available through Web Application Firewall (WAF) technology.

A WAF examines web traffic before it reaches a website or application, looking for requests that match known attack patterns. Where a request is identified as malicious, the firewall can block it before it reaches the application.

Our shared hosting infrastructure already uses WAF technology, providing an additional layer of security against common web-based attacks.

Cloudflare and Imunify360 also released updated WAF rules designed to detect and block known PHP2Shell exploitation techniques.

Our security and technical teams reviewed these protections and deployed the appropriate rules across the relevant systems as they became available.

These provided another layer of protection alongside the mitigation measures recommended by the PHP project.

The important point is that we were able to take action before the official security patches were available, rather than simply waiting for the vendors to release their updates.

It’s worth stressing that these measures were not a complete fix. The PHP security team made this clear in its own advisory. The mitigations were intended to reduce exposure to particular methods of exploitation while the underlying vulnerabilities remained unpatched.

WAF protections can also help prevent known attacks, but they are not a substitute for patching the underlying vulnerability.

How Server Intelligence and Automation Helped Us Respond

Applying a configuration change to a single server is generally straightforward.

Applying that same change across thousands of servers, running different operating systems, PHP versions, control panels and configurations, requires a different approach.

We host tens of thousands of websites across thousands of servers, so understanding the configuration of each system is an important part of managing our infrastructure.

Over the years, we’ve developed our own server intelligence and infrastructure management tools to help us do this.

These tools allow us to collect detailed information about individual server configurations, including operating systems, installed software, PHP versions and relevant settings.

That information is particularly useful when responding to a security vulnerability.

A recommended mitigation might be suitable for one PHP version or server configuration but not another. Before deploying changes, we need to understand which systems are affected and determine whether the proposed measures are appropriate.

Our server intelligence tools allow us to retrieve and assess this information on a server-by-server basis without engineers having to log in and manually investigate thousands of individual machines.

With that information available, our technical team can determine which mitigations should be applied, identify systems requiring a different approach and use our automation tools to deploy the appropriate changes.

This was particularly useful during the PHP2Shell response.

Once the PHP project’s mitigation guidance had been assessed, we were able to identify the relevant systems and roll out the necessary configuration changes across the vast majority of our managed infrastructure.

Without these tools, the same work would have involved considerably more manual effort and taken significantly longer.

It also meant the team could concentrate on systems requiring individual attention, checking deployment results and dealing with exceptions rather than repeating the same tasks across thousands of servers.

There’s an important relationship between server intelligence and automation.

Our server intelligence tools provide the information needed to assess which changes are appropriate for each system. Our automation tools then allow us to apply those changes consistently across the relevant infrastructure.

Our engineers still need to evaluate the security recommendations, understand their potential impact and decide how they should be implemented. The technology gives them the information and tools needed to carry out those decisions at scale.

It also helps reduce the possibility of human error. Making changes manually across large numbers of servers, particularly when time is important, increases the risk of something being missed or configured incorrectly.

The other point worth making is that none of these tools were developed specifically for PHP2Shell.

They were already in place as part of our normal infrastructure management processes, following years of development and improvement.

When the vulnerabilities were announced, we already had the information and tools needed to assess our infrastructure and implement the appropriate changes.

From Mitigation to Patching

On 21 October, the PHP development team released the official security patches.

These were followed by updates from the various control panel vendors, operating system providers and companies supplying extended security support for older PHP versions.

The vast majority of our customers received the relevant security patches as soon as they became available through the normal update mechanisms.

Automatic security updates are enabled by default on our managed servers unless customers have changed or disabled these settings.

Our technical team actively monitored the deployment to verify that updates had been installed successfully.

Over the following 24 hours, much of our attention was focused on a relatively small number of exceptions. These included servers where automatic patching had failed, updates required manual intervention or suitable vendor packages were not yet available.

Our team worked through these individually, resolving update failures and applying the necessary patches wherever possible.

One particular consideration was older PHP versions.

Although PHP 8.1 and earlier are no longer officially supported by the PHP project, some vendors provide extended security maintenance.

CloudLinux, cPanel and Plesk have all made backported fixes available for certain older PHP versions affected by PHP2Shell.

This is important because an older PHP version doesn’t automatically mean an installation is vulnerable. It may have received the relevant security fixes through vendor-maintained packages.

However, that depends on the version, operating system and software packages installed.

Where we’ve identified customers on managed servers running older PHP versions for which a suitable patch is not available, we’re contacting them directly.

We continue to recommend upgrading to officially supported PHP versions wherever possible. While extended security maintenance is useful, there is no guarantee that every future vulnerability will receive a backported fix.

Patching Isn’t the End of the Investigation

Once the security patches have been installed, there is still work to do.

In particular, we need to understand whether there have been attempts to exploit the vulnerabilities and whether there is any evidence that requires further investigation.

Since the initial announcement, security researchers have continued publishing information about PHP2Shell, including possible exploitation methods, proof-of-concept code and analysis of the available mitigations.

Some of the early exploits circulating online have been found to be unreliable or to depend on configurations that aren’t typical of production environments.

Other researchers have demonstrated that exploitation is possible under more realistic conditions.

This is why we continue following the research after the initial security release.

We’re also reviewing potential indicators of compromise that could help identify exploitation attempts or evidence of a successful attack.

There is an important difference between confirming that a server has been patched and establishing whether it was compromised before the patch was installed.

The first can usually be verified through package and configuration checks. The second may require additional investigation, including reviewing logs, monitoring data and other evidence.

Security incidents don’t necessarily end when the vendor releases a fix.

Why the Work Behind the Scenes Matters

There is quite a lot involved in keeping hosting infrastructure secure that customers will never normally see.

Monitoring emerging threats, reviewing vulnerability disclosures, maintaining accurate information about systems, developing automation, applying security updates and checking the results are all part of the ongoing work.

Most of the time, this happens without any disruption to customers or the need for a public announcement.

PHP2Shell is a useful example of how those different activities come together.

Our security monitoring helped us follow the developing situation. Our server intelligence tools helped us establish which systems required attention, while our automation allowed the appropriate changes to be deployed across much of our infrastructure.

When the official patches became available, the vast majority of systems received their updates promptly, allowing our team to concentrate on the small number requiring additional attention.

None of this means that every risk can be eliminated. New vulnerabilities will continue to emerge, and there will always be situations where a patch isn’t immediately available.

What matters is having the people, information and tools available to respond when that happens.

For me, one of the most important aspects of this incident was the value of work completed long before PHP2Shell was announced.

The investment in server intelligence, infrastructure management and automation wasn’t particularly visible to customers at the time. Much of it formed part of the routine work of improving how we operate and maintain our systems.

But when the PHP2Shell vulnerabilities were announced, those capabilities were already there.

And that made a significant difference to how we were able to respond.

We will continue to monitor developments and publish any further information relevant to customers through our service status page .