Status as at 22 October 2026, 13:30 CEST

The first day following the disclosure of the critical PHP vulnerabilities, collectively known as PHP2Shell, has been relatively calm in terms of confirmed security incidents.

That does not mean it has been quiet. The vulnerabilities have received considerable media attention, and we have seen a large number of questions and concerns from organisations trying to understand their exposure.

For some, the situation has also highlighted a more fundamental challenge: insufficient visibility into their own infrastructure. Organisations that lack a clear overview of where PHP is running, and which versions are deployed, have found themselves scrambling to establish whether they are affected.

Meanwhile, the volume of traffic associated with exploitation attempts has started to increase.

What do we know about the PHP2Shell vulnerabilities?

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affect the PHP runtime itself and can allow unauthenticated remote code execution. Security updates were released on 21 October.

Successful exploitation has been demonstrated by security researchers, establishing that these are genuine and serious vulnerabilities.

However, there is an important distinction between demonstrating that a vulnerability can be exploited and developing reliable exploit code that works across a broad range of real-world deployments.

PHP is deployed in many different environments, with varying configurations, extensions and application behaviour. These differences can have a significant impact on exploitability.

Although successful exploitation has been demonstrated against certain configurations, we still do not know how easily or reliably threat actors will be able to exploit typical PHP installations at scale.

There has also been considerable discussion about the scale of the potential exposure, including claims that 70% of the internet is affected. This is an oversimplification of statistics describing PHP's prevalence among websites with identifiable server-side programming languages. It should not be interpreted as a measurement of the proportion of internet-facing services that can be compromised.

Have PHP2Shell exploitation attempts been observed?

We are observing confirmed attempts to exploit the vulnerabilities against organisations within our customer base.

So far, we have not identified evidence of successful compromise associated with these attempts. There is also uncertainty as to whether the methods used in the observed attempts would have been capable of succeeding, and under which conditions.

The activity is not limited to the period following public disclosure. Other security researchers have reported exploitation attempts dating back to 17 October, several days before the vulnerabilities were publicly disclosed. Differences in the observed techniques and infrastructure suggest that multiple threat actors are involved.

The volume of apparent exploitation attempts is increasing, but it remains important to distinguish between three things: attempts to exploit a vulnerability, technically successful exploitation, and confirmed compromise of a system.

These are not interchangeable, and a high volume of attack traffic does not necessarily translate into a corresponding number of successful compromises.

How is mnemonic detecting PHP2Shell exploitation attempts?

We have deployed detections across multiple security platforms to identify exploitation attempts and potential signs of compromise.

From a detection perspective, the strongest approach remains a combination of endpoint detection for post-exploitation activity, network detection and response (NDR) with TLS inspection, and next-generation firewalls (NGFWs) and web application firewalls (WAFs).

These provide complementary visibility into suspicious web requests, network activity and actions performed on affected systems. Given the uncertainty surrounding the reliability of current exploits, monitoring for post-exploitation activity remains particularly important.

No single detection mechanism should be relied upon in isolation, and detection is not a substitute for patching vulnerable systems.

What happens next with PHP2Shell?

Given the enormous publicity surrounding these vulnerabilities, we expect the number of exploitation attempts to continue increasing.

More threat actors will attempt to develop or adapt exploit code, and automated scanning and exploitation attempts are likely to become increasingly widespread.

What remains uncertain is how quickly these efforts will translate into reliable exploitation across different PHP deployments.

Some vulnerable services can already be compromised. Others may prove considerably more difficult to exploit, depending on their configuration and runtime environment.

We do not yet know how large the practically exploitable portion of the affected population will become, either in the coming days or over the longer term.

This is perhaps the most important development to watch: not simply whether exploitation attempts become widespread, as that is already happening, but how quickly threat actors develop methods that consistently result in successful compromise.

For organisations operating vulnerable, internet-facing PHP services, this uncertainty should not be interpreted as reassurance. Where reliable exploitation is possible, leaving services vulnerable and exposed over time creates a substantial risk of compromise.

mnemonic's recommendations

Organisations should identify affected PHP installations, apply the available security updates as soon as possible, and verify that the updated runtimes are actually in use. Where immediate patching is not possible, exposure should be restricted until the vulnerabilities can be addressed.