Upgrading PHP: the risk of running an unsupported system

Since October 21, 2026, any system running PHP below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is exposed to a critical flaw that allows an attacker to take control of the server, and an unsupported PHP version (8.1 or earlier) no longer receives the official fix. The solution isn’t necessarily rebuilding everything: first you need to know which version is running, what depends on it and what the shortest path back to a supported version is.

At DCisGlobal we find this in almost every assessment. A CRM installed in 2016, an online store from 2017, a management system that “works perfectly.” Underneath, a PHP version that stopped receiving patches years ago.

To put it in perspective: PHP 7.4, one of the most widely used versions on company servers, received its last security patch in November 2022. PHP 5.6 received its last one in December 2018. Even PHP 8.1 lost support at the end of 2025.

Need to catch up and have nobody to do it? At DCisGlobal we handle PHP upgrades, including the PHP2Shell emergency, and put together a plan for systems that can’t be upgraded overnight. Message us on WhatsApp

What is PHP and why does it matter to your company?

PHP is the language that powers a large share of the web systems used by small and mid-sized businesses (SMBs): CRMs such as Vtiger or SuiteCRM, stores such as PrestaShop or Magento, sites built on WordPress, Joomla or Drupal, and many custom-built management systems.

Nobody in management chooses “which PHP version to use.” You choose a system, and that system is tied to a version. When the system isn’t updated for years, neither is the PHP version.

That’s why the problem is invisible until it surfaces: the system works, but what’s underneath it has been frozen.

What does it mean when a PHP version is unsupported?

Each PHP version receives fixes for a limited time. After that it reaches “end of life” (EOL): nobody publishes patches for it anymore.

In practice, that means three things for your operations:

• Known vulnerabilities that don’t get fixed. When a security flaw appears, it’s fixed in the current versions and the old ones are left exposed.
• Your hosting provider pushes you to upgrade. Many managed servers stop offering old versions, and the system may stop working the day they change the configuration.
• Integrations break. Payment gateways, e-invoicing or email services stop accepting connections from old software.

It isn’t an overnight emergency. It’s a risk that grows every month.

October 2026: upgrading is no longer optional

On October 21, 2026, the PHP team released a security update for all supported versions. It fixes two critical flaws (CVE-2026-109618 and CVE-2026-109619), known as PHP2Shell and rated 9.2 out of 10. Their details leaked a day before the patch and there are already reports of real-world attacks: we cover it in PHP2Shell: what the critical PHP flaw is and what to do now.

In business termsAn attacker can end up running code on the server without a username or password, just by sending requests to the site. According to PHP’s own advisory, the risk extends to any installation that serves web traffic, and there is no complete mitigation: the only safe fix is to upgrade.

We won’t go into how the flaws work. What matters for your decision is which version you need, at a minimum, from now on:

By version: PHP 8.1 end of life, PHP 8.0 vulnerabilities and end of life and PHP 7.4 end of life and how to upgrade.

How to read the table:

• Any version below the minimum for its branch is vulnerable. A server running PHP 8.3.30, for example, is as exposed as an old one: it has to be brought to 8.3.36 or later.
• PHP 8.1 and earlier don’t receive the official fix. PHP published patches for 7.4, 8.0 and 8.1 that some Linux and extended-support vendors apply on their own. If the system depends on one of those versions, confirm with the vendor that the patch has been applied or, better, move off that version.
• PHP 8.2 reaches end of support on December 31, 2026. Upgrading to 8.2.35 today solves the emergency, but in two months it will be unpatched again. If you’re doing the work anyway, go straight to 8.3 or later.

The practical conclusion: every system that isn’t running on PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later is exposed today to a known critical flaw. And those that need PHP 8.1 or earlier won’t receive any more fixes either.

Is your version unsupported or below the minimum for its branch? Send us the version number and we’ll tell you the risk it carries and the shortest way out. Chat on WhatsApp

Which systems tend to get stuck on old PHP?

In our experience, these are the most common cases:

System by system: Vtiger, PrestaShop 1.6, Magento 1 and Dolibarr.

Then there’s the server: many of these systems run on CentOS 7, unsupported since June 2024, or on Windows Server 2012, unsupported since October 2023.

PHP 5.6.40: the last PHP 5 release

PHP 5.6.40 was the last release of the entire 5 branch, and PHP 5.6 reached end of life on December 31, 2018. Since then it has received no official fixes: every vulnerability found in almost eight years, PHP2Shell included, remains open on a server running 5.6.40. No configuration makes it safe.

It is also the longest jump. Between PHP 5.6 and PHP 8, functions that old systems use every day disappeared, such as the mysql_* database functions or the ereg expressions, both removed in PHP 7.0. That is why changing the PHP version is rarely enough: the system has to be upgraded or adapted, and isolated in the meantime.

CentOS 7 and PHP 8.2.35

CentOS 7 reached end of life on June 30, 2024, and its official repository ships PHP 5.4. Getting PHP 8.2.35 or a newer version on CentOS 7 means relying on third-party repositories or compiling it by hand, and every future patch depends on that, on an operating system that no longer gets fixes either. If the server already runs PHP 8.2 on CentOS 7, make sure it is on 8.2.35 or later, and keep in mind that 8.2 loses support on December 31, 2026.

The solid way out is moving the system to a server with a supported operating system, such as AlmaLinux or Rocky Linux, the most direct successors to CentOS, and installing PHP 8.3 or later there. That solves both problems in a single project.

The hidden cost of not upgrading

Staying put seems free, because there’s no invoice. In practice, the cost shows up elsewhere:

Security and customer data. A CRM or a store holds personal data. A breach damages trust and, in Spain, can lead to data protection penalties.

Manual work. Every integration that breaks is replaced with a spreadsheet or with someone copying data by hand.

Dependence on one person. These systems were often customized by a developer who is no longer around. Every change becomes slow and expensive.

Forced changes. The worst case is upgrading because you have to: the day the hosting provider retires the old version, the system goes down and has to be fixed in a rush.

Signs it’s time to act

• Nobody knows for sure which PHP version the server uses.
• The hosting provider has sent notices about “obsolete” or “unsupported” versions.
• There are plugins, modules or integrations that stopped working and were replaced by manual work.
• To change anything you always have to call the same person.
• The system shows deprecated warnings or errors after server changes.

With two or more of these signs, it’s worth running an assessment before the change is forced on you.

What are your options for moving off unsupported PHP?

1. Upgrade the system to a current version. If the system still fits the business, you upgrade it to a version that supports PHP 8.2 or later. The work lies in migrating customizations and data without losing anything.

2. Adapt the code to PHP 8. In custom systems, sometimes it’s enough to fix the code so it runs on a new PHP version. It’s the fastest option when the system is well built.

3. Hardening while you plan. If you can’t upgrade right away, you reduce exposure: restrict access, take the system off the open internet, update the server as much as you can and make sure you have verified backups. It buys time; it isn’t a long-term solution.

4. Migrate or redesign. If the system no longer fits the way you work, it’s better to move to another platform or build something custom, migrating the data and processes.

To decide, we look at three things: how much in-house code the system has, which integrations are critical and what operations will need in the coming years.

What to do now

1. Take inventory: which systems the company has, which exact PHP version each one runs on (with its full number, for example 8.3.36) and on which server. Anything below the minimum version for its branch gets upgraded first.
2. Secure the basics: tested backups and reviewed access.
3. Measure the impact: which processes depend on each system and what it would cost if they failed.
4. Choose a path and set dates: upgrade, adapt, harden or migrate, without stopping operations.

Our service: PHP upgrades

For companies that need to catch up, we offer a one-off PHP upgrade service, delivered remotely, for companies in Spain and Latin America. It works the same whether you use shared hosting, virtual private servers (VPS) or your own servers.

What it includes:

1. Version review. We list every server and every web system in the company with its exact PHP version, and flag what is exposed (including PHP2Shell).
2. Upgrade to a supported version. We bring PHP to 8.3 or later (at a minimum, to the fixed version of its branch). First on a test copy, checking that the system keeps working, and then in production.
3. System adaptation. If the CRM, the store or the custom system doesn’t work on the new version, we upgrade it or fix its code so it does.
4. A plan for what can’t be moved yet. If a system depends on PHP 8.1 or earlier, we isolate it immediately and put together a plan to upgrade or migrate it, with dates.
5. Credential rotation and intrusion review. We rotate passwords and keys for the systems that were exposed and check the server for signs of attack.
6. Final report. What was upgraded, what is still pending and what should be done next, in business language.

Estimated turnaround: 72 hours.