PHP 8.0 reached end of life and stopped receiving security patches on November 26, 2023; its last release was 8.0.30. Every flaw found since then, PHP2Shell included, remains open on those servers, and the way out is moving to PHP 8.3 or later.
Many companies find out by accident: a notice from the hosting provider, an audit, or a server header that reads “X-Powered-By: PHP/8.0.30”. At DCisGlobal we see that this discovery always raises the same two questions: how serious it is and how much it costs to move off 8.0.
What it means to see “PHP/8.0.30” in a server header
It means the system runs on the last release of the 8.0 branch. There is no 8.0.31: the PHP project closed that branch and will not ship any more fixes.
The header shows up because the expose_php directive is on by default and advertises the version in every response. Hiding it is good practice, but it fixes nothing: the unpatched code is still on the server.
For the business, the takeaway is simple. Anyone who looks at that header knows the system gets no fixes. It is like leaving a sign on the door with the lock model and a note that the manufacturer no longer repairs it.
Which vulnerabilities affect PHP 8.0.30 today
Version 8.0.30 was a security release and closed the flaws known at the time. The problem is everything that came after. Since 11/26/2023, the PHP team only fixes supported branches, and every new flaw that also affects 8.0 goes without an official fix.
The most recent case is PHP2Shell. On October 21, 2026, PHP released the fix for two critical flaws only for supported branches: the minimum safe versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.0 does not get that fix. For background, see what PHP2Shell is and what to do.
You do not need technical details to gauge the risk. An unsupported version piles up public flaws nobody will close, and the PHP site itself warns that users of such a version may be exposed to unpatched security vulnerabilities.
Is a patch from your hosting provider enough?
Some providers and distributions maintain old versions on their own, with their own fixes. That can work as a bridge, but it has two limits:
- It is not the official PHP fix, and its scope depends on each provider.
- It does not solve the rest of the system: libraries, frameworks and plugins gradually stop shipping 8.0-compatible versions, and the system gets stuck on old dependencies.
Our advice is to use it only to buy time while the upgrade is planned, never as the end state.
Which version to move to
| Version | Security support | What it means for the business |
|---|---|---|
| 8.0 | Ended 11/26/2023 | Unsupported: no PHP2Shell fix |
| 8.1 | Ended 12/31/2025 | Unsupported, same as 8.0 |
| 8.2 | Until 12/31/2026 | Ending soon: just over two months |
| 8.3 | Until 12/31/2027 | Supported: reasonable minimum target |
| 8.4 | Until 12/31/2028 | Supported: more runway |
| 8.5 | Until 12/31/2029 | Supported: the newest branch |
Is your PHP version safe?
Type the exact version your server runs and we’ll tell you right away whether it’s exposed and what to do.
Moving to 8.2 today would be like moving into an office whose lease ends in December. That is why we recommend 8.3 as a minimum and, if the system allows it, 8.4 or 8.5.
The good news is that the jump from 8.0 to 8.3 is much shorter than from 7.4. The big language changes arrived with 8.0 and are already behind you. What remains are functions deprecated in 8.1 and 8.2 plus minor adjustments, documented in the php.net migration guides.
If your company still has older systems, our article on PHP 7.4 end of life and how to upgrade covers that case; for 8.1, see PHP 8.1 end of life: why PHP 8.3 is the next step.
What to do now
- Confirm the real version. The header may come from another server or an old configuration. Your hosting panel or whoever manages the server can confirm it.
- Take stock of what runs on that PHP. Website, online store, CRM, integrations and scheduled tasks. There is often more than one system on the same server.
- Check compatibility. Framework, CMS and plugins: which PHP version each one supports and which must be updated first.
- Test on a copy. Run the system on PHP 8.3 or later in a staging environment and walk through the critical processes: sales, invoicing, new customer sign-ups.
- Migrate with a rollback plan. Backup, an agreed change window and a clear way back if something fails.
- Stop advertising the version. Once the system is upgraded, turn off expose_php.
The full process is in our guide on how to upgrade PHP on unsupported systems.
How we solve it at DCisGlobal
We start with a technology assessment: version, dependencies, custom code and risks. From there, we deliver a phased plan, with the cost and order of the changes, before touching production.
Then we run the migration in a staging environment, validate it with your team and go to production with a backup in place. If the code has reached its limit, we say so and propose alternatives.
