PHP 8.1 reached its end-of-life date on 31 December 2025. Five months on, the situation in shared hosting environments is in many cases roughly what informed administrators expected at the time, and in other cases more complicated than the migration guides predicted. This piece is an operational stocktake — what shared hosting providers should have done by now, what many still have not done, and what the next twelve months of EOL pressure look like for anyone running a control-panel-managed Apache and MySQL stack.

The headline numbers are unambiguous. The PHP development team has issued no further releases on the 8.1 branch since the EOL deadline. The final release was 8.1.32 in December 2025. Any CVE disclosed against PHP 8.1 after 31 December is, by definition, permanent unless addressed by a third-party extended-support service. PHP 8.0, 7.4, 7.3 and everything below have been unsupported for considerably longer. The remaining supported branches in May 2026 are PHP 8.2 (security-only support, EOL 31 December 2026), PHP 8.3 (security-only support, EOL 31 December 2027), and PHP 8.4 (full active support, EOL 31 December 2028). PHP 8.5 is scheduled for general availability in November 2026.

This is not a complicated picture in the abstract. The complication is in the field.

What the field actually looks like

The pattern across shared hosting providers in the first five months of 2026 has been broadly threefold.

A first group of providers — predominantly the larger managed WordPress platforms and several of the more disciplined VPS operators — completed forced migrations of all PHP 8.1 accounts to a supported version on or around 31 December. Most of those migrations were to PHP 8.4 directly, on the reasoning that pushing accounts to 8.2 or 8.3 would only repeat the migration exercise within twelve to twenty-four months. The first weeks of January saw the predictable spike in tickets — broken plugins, themes relying on deprecated functions, custom code touching dynamic properties or any of the other features that PHP 8.2 and later have removed or warned on. By February most of those incidents had been resolved, in some cases by the host rolling specific accounts back to PHP 8.3 where 8.4 caused unresolvable breakage.

A second group of providers issued advance notice through November and December 2025 but did not perform forced upgrades on the EOL date itself. These hosts left customers running PHP 8.1 with a series of escalating warnings, banners in the control panel, and outbound emails. As of late May 2026, a non-trivial fraction of those customer accounts are still on PHP 8.1, either because the customer never received or never read the notices, or because they did read them and have not yet been able to address the compatibility issues that an upgrade would cause. Those accounts are, technically, running unpatched PHP. The hosts in this group are, broadly, less exposed in compliance terms than they would be in a regulated industry, but they are exposed in security terms, and the longer the situation persists the larger the exposure becomes.

A third group of providers — typically smaller operators, including a meaningful slice of providers running open source control panels such as web-cp — did not perform forced upgrades, did not issue clear advance notice, and have continued to allow new account provisioning on PHP 8.1 in some cases. This third group is the operational concern. The accounts on these hosts are running unsupported PHP without the administrators of the underlying servers necessarily knowing how many there are or which sites are affected.

The migration arithmetic that was not done

One observation worth recording, because it explains a great deal of the current friction, is that the migration arithmetic that should have been done in mid-2025 was in many cases not done. The simplest version of the calculation runs as follows.

A provider with, say, three hundred shared hosting accounts on PHP 8.1 as of mid-2025 had roughly six months until the EOL date. The migration target was either PHP 8.2 (which itself has EOL in December 2026, requiring a second migration within twelve months of the first), PHP 8.3 (EOL December 2027, allowing eighteen to twenty-four months of stability), or PHP 8.4 (EOL December 2028, the genuinely long-term target). Each of those three targets carried different breakage risks. The 8.1 to 8.3 jump is shorter and breaks fewer plugins; the 8.1 to 8.4 jump is longer and breaks more, but defers the next migration considerably.

A rational provider would have built an internal map of which accounts could safely jump to 8.4 directly, which needed 8.3 as an intermediate step, and which legacy accounts required either extended support or active migration assistance. The providers that did this exercise reached December 2025 with a workable plan. The providers that did not are now, in May 2026, doing the same exercise reactively, one customer ticket at a time, against a backdrop of unpatched servers.

Where this is going for the next twelve months

The next significant EOL date is 31 December 2026, when PHP 8.2 reaches the end of its security-only window. That is now roughly seven months away as of this writing, and any account that was migrated from 8.1 to 8.2 in late 2025 is on a schedule to need to move again before the end of the year. This is the operational reason that most of the disciplined hosts skipped 8.2 entirely and went to 8.4 on the December 2025 migration cycle.

For control-panel administrators using web-cp, the practical implication is that the multi-version PHP configuration capability built into recent releases — the ability to run different PHP versions per virtual host, with each version handled cleanly by FPM pools — is now an operational necessity rather than a convenience. The single-version PHP installations that some shared hosts have run for years are no longer compatible with a customer base that includes legacy WordPress sites needing 7.4 or 8.0 (running on extended support or accepting the security exposure), modern WordPress sites on 8.3 or 8.4, and customer custom applications that may be on any of the supported versions for compatibility reasons.

Anyone running a web-cp deployment that has not configured per-vhost PHP-FPM pools by now should treat this as the priority operational task of the next quarter. The mechanism for doing so is documented in the control panel's Apache configuration section and involves defining FPM pool configurations under the system-level PHP installations directory, then assigning each virtual host to the appropriate pool through the control panel interface. Once configured, the per-vhost PHP version is editable from the domain control panel by the domain owner, removing most of the server administrator's involvement in routine version upgrades.

What providers should do in the next thirty days

The practical actions that providers still carrying PHP 8.1 accounts should take in the next thirty days are reasonably straightforward, and they are worth listing.

Inventory which accounts are still on PHP 8.1. The server-level reporting tools in web-cp expose this directly through the resellers and server control panels; a single query against the virtual host configuration database will produce the list.

For each affected account, identify the application stack. WordPress, Drupal, Magento, Laravel, custom PHP — each has a different upgrade risk profile, and the migration plan should be tailored. WordPress sites with modern themes and well-maintained plugins generally upgrade cleanly to 8.3 and often to 8.4. Legacy WordPress installations with abandoned plugins, older Drupal versions, and custom code touching dynamic properties are the cases that produce breakage and tickets.

Communicate clearly with the affected customers. Five months into the EOL window, customers who have not yet been told their PHP version is unsupported should be told now, in plain language, with a deadline. The deadline does not need to be aggressive — sixty to ninety days is reasonable — but it does need to be firm and it does need to be followed up.

Plan the forced migration for any accounts that do not respond. Quietly carrying unpatched PHP for unresponsive customers is a security posture that becomes progressively harder to defend the longer it continues, and the next EOL deadline — PHP 8.2 in December 2026 — is going to require the same exercise to be performed again.

Bring the per-vhost PHP version management into the standard operating posture of the control panel deployment, if it is not there already. The PHP release cycle is now stable, predictable, and unforgiving. Treating PHP versions as a routinely administered configuration variable, rather than a once-every-few-years migration event, is the only operational stance that scales.

PHP 8.1 has been end of life for five months. The accounts still running it are running on borrowed time, the providers still carrying them are running on borrowed credibility, and the next deadline is closer than it looks.