PHP2Shell and the End of Legacy PHP at VO

On October 21, 2026, the PHP development team released emergency security updates for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both allow remote code execution: an attacker can run their own code on a web server without logging in or having any account on it.

What makes PHP2Shell (the name for this pair of exploits) unusually dangerous is the timing: Exploitation attempts were already being observed at the moment the vulnerabilities became public, and working attack techniques were circulating shortly after.

There was no window in which a server could be considered safe while waiting for a convenient maintenance slot.

The response from the security community reflected that urgency. CERT-EU published Security Advisory 2026-018 recommending immediate patching or isolation of exposed systems. ENISA, together with the European Commission, CERT-EU, Europol and the European CSIRTs Network, issued a joint statement calling for immediate action. Luxembourg’s CIRCL published advisory TR-102 confirming the critical rating. The NSA issued its own advisory the same day. Links to all of these are at the end of this article.

Most security advisories that reach website owners concern a specific application: a WordPress plugin, a Joomla extension, a shop system. The fix is usually to update that one component. PHP2Shell sits deeper. The flaw is in the PHP runtime itself, the engine that executes every PHP application on our servers.

A website can therefore be fully up to date at the application level and still be vulnerable. A WordPress site with every plugin patched, a Drupal site on the latest release, a custom-built application that has never had a security issue: all of them are exposed if the PHP version underneath has not been fixed.

Because we provide the PHP versions on our servers, this was ours to fix, and it could not wait for individual website owners. So we had to act.

Within hours of the disclosure, we patched every supported PHP version on all of our Plesk servers to the fixed releases. For customers on a current PHP version, that was the end of the story: nothing changed and nothing needed to be done.

For PHP versions that have already reached their end of life, there was no patch to apply. The PHP team no longer maintains those branches, and no fix for PHP2Shell exists for them. Every one of the affected versions had been end of life for at least ten months. Our only options were to leave known, actively exploited vulnerabilities running on our infrastructure, or to switch those versions off. We switched them off.

We did this without advance notice, and that was a deliberate choice. Attacks were already underway. Announcing a deactivation a week ahead would have meant a week in which every outdated site on our platform was an open target, and in which the announcement itself would have told attackers exactly where to look.

Since the deactivation, we have received requests to re-enable an older PHP version for a single account, often with good reasons: a legacy application that cannot be updated quickly, an agency that has gone out of business, a migration already planned for next quarter. We understand every one of these, and we are declining all of them.

The reason is that on shared hosting, a vulnerability is never contained to one website. A single compromised PHP process on a server is a foothold from which an attacker can probe everything else that runs there. Keeping one outdated version alive for one customer would put every other customer on that server at risk, including those who did everything right.

We also want to be clear about what we are weighing. A website that is temporarily down because it needs a PHP update is an inconvenience with a known fix. A website that has been compromised can mean stolen customer data, defaced pages, malware served to visitors, blacklisting by search engines and, under GDPR, a reportable data breach. Between the two, we will choose the inconvenience every time.

This also applies going forward. We will no longer keep end-of-life PHP versions available on our platform. Extended security maintenance from third parties does exist for some old branches, but it does not carry the same guarantees as an officially supported release, and PHP2Shell has shown how quickly an unpatched runtime becomes a liability.

If your website stopped working on or after October 21, it is most likely running on a deactivated PHP version. The fix is to switch it to a supported one. In Plesk, go to Websites & Domains, open PHP Settings for the domain, and select a version from the list below.

• PHP 8.5 (8.5.12 or newer): supported, recommended
• PHP 8.4 (8.4.27 or newer): supported, recommended
• PHP 8.3 (8.3.36 or newer): supported, recommended
• PHP 8.2 (8.2.35 or newer): supported until December 2026
• PHP 8.1 and older: deactivated, no secure version exists

Two things to keep in mind:

• PHP 8.2 is a short-term option only. Its official security support ends in December 2026, at which point it will go the same way as 8.1. If 8.2 is the only version your site currently runs on, treat it as a stepping stone and plan the move to 8.3 or newer now.
• Switching the version may not be enough on its own. If your site breaks on a newer PHP version, the cause is usually an outdated CMS core, theme or plugin, or custom code that uses functions removed in PHP 8. In that case the application itself needs to be updated. For WordPress, Joomla and Drupal, that typically means updating the core and all extensions; for custom applications, a developer will need to review the code.

PHP2Shell will not be the last vulnerability of its kind. The PHP project publishes a clear support schedule for each release, and the pattern is consistent: a branch gets active support for two years and security fixes for two more, then nothing. Websites that stay inside that window get fixes within hours of a disclosure. Websites outside it do not, and the gap between the two has never been as visible as it was this week.

Our recommendation is simple. Keep your website on a PHP version that is still receiving security updates, treat the upgrade to the next version as routine maintenance rather than a project, and keep your CMS, themes and plugins current so that the upgrade stays painless. We will keep offering every currently supported PHP branch, but no more versions which are considered officials end-on-life.

• PHP – Security announcement of October 21, 2026
• CERT-EU – Security Advisory 2026-018
• ENISA – Joint statement on critical PHP vulnerabilities
• CIRCL Luxembourg – TR-102
• NSA – Advisory on PHP updates