Still on PHP 7 or 8.1? Why You Should Upgrade to PHP 8.5

If your website or internal app runs on PHP 7.4, 8.0 or 8.1, it's time to upgrade to PHP 8.5. That was true last year. It got a lot more urgent on October 21, 2026, when the PHP team shipped fixes for two critical remote code execution bugs and those versions didn't get an official release.

I wrote up what PHP2Shell is and what to patch the day it dropped. This post is the follow-up for the people who read that and thought, "We're on 7.4. Now what?" It's written for business owners, not just developers: what the version numbers mean, what you get for the work, and how I run an upgrade without breaking the site.

Rather hand the upgrade to someone else? That's work I do. Get a free quote, or read on and I'll walk you through how I'd run it.

PHP gives each version two years of active support (bug and security fixes), then two years of security fixes only. After that, it's end of life, and nobody at the PHP project patches it.

Here's where things stand today, from php.net:

• PHP 8.5: active support, security fixes until Dec 31, 2029
• PHP 8.4: active support, security fixes until Dec 31, 2028
• PHP 8.3: security fixes only, until Dec 31, 2027
• PHP 8.2: security fixes only, until Dec 31, 2026
• PHP 8.1: end of life since Dec 31, 2025
• PHP 8.0: end of life since Nov 26, 2023
• PHP 7.4: end of life since Nov 28, 2022

If you're on 8.2, you have about ten weeks. If you're on 8.1 or anything in the 7 series, you're already past the date.

It means new security holes don't get fixed. Your site doesn't stop working on January 1. It keeps running, and it keeps running with every bug found after the cutoff.

PHP2Shell is the clearest example I've seen. The two bugs, CVE-2026-109618 and CVE-2026-109619, can let an unauthenticated visitor run code on the server, and the researchers trace affected code back to PHP 5.4. The PHP team released fixed versions for 8.2 through 8.5. For 8.1 and older, php.net says plainly that they no longer get updates. Because the bugs were so serious, the security team also put out minimal source patches for 7.4, 8.0 and 8.1. Those only help if you compile PHP yourself, which almost nobody on shared or cPanel hosting does.

Some Linux distributions and paid long-term-support vendors backport fixes to old versions. If you're paying for that, great, check with them. If you aren't sure, you probably aren't covered.

Because if you're doing the work anyway, take the longest runway.

PHP 8.5 came out November 20, 2025. It gets active support through the end of 2027 and security fixes through the end of 2029. Going from 7.4 to 8.4 is about the same amount of work as going to 8.5, and you'd give up a year of support.

PHP 8.6 is scheduled for November 19, 2026. I wouldn't move a business site to a brand-new major release on day one. My plan for most sites is 8.5 now, then 8.6 once it has a few patch releases behind it and the frameworks and plugins you rely on say they support it.

Security is the reason to upgrade. But you get more than that for the money.

Code that's easier to maintain. PHP 8.5 adds the pipe operator (|>), which lets a developer write a chain of steps top to bottom instead of nesting function calls inside each other. It adds "clone with" for updating copies of read-only objects, plus array_first() and array_last(). Those sound small. They add up to fewer lines and fewer places for bugs to hide, which means future changes cost less.

Safer handling of URLs. A new built-in URI extension parses and normalizes URLs to the RFC 3986 and WHATWG standards. Anything that validates redirects, webhooks or user-supplied links gets a more reliable tool than the old parse_url().

Fewer silent mistakes. The #[\NoDiscard] attribute warns when code ignores a return value that matters, and fatal errors now include a backtrace. When something does break, finding it takes less time.

Better performance for API-heavy apps. Persistent cURL share handles let an app reuse connection setup across requests. If your site talks to Salesforce, a payment gateway or a shipping API on every page, that's the kind of change that shows up.

Jumping from 7.4 also picks up everything from 8.0 through 8.4: named arguments, enums, readonly properties, match expressions and a long list of type-safety improvements. For a developer, that's a much nicer codebase to work in.

Usually less than people fear, but not nothing.

From 7.4, the big jump is 8.0. It changed how some comparisons and errors behave, and older code that leaned on warnings being quiet tends to throw errors instead. The 8.x releases since then mostly deprecate things before removing them. PHP 8.5 deprecates the backtick operator as a shortcut for shell_exec(), the old cast names like (integer) and (boolean), and using null as an array key. It also removes the disable_classes setting.

The bigger risk is usually your dependencies, not your code. An old WordPress plugin, an abandoned Composer package or a framework two major versions behind may simply not run on 8.5. That's where most of the work in an upgrade goes.

My process is the same whether it's a small brochure site or an integration-heavy app:

1. Inventory. Every site, server and cron job, and the PHP version each one actually runs. php -v on the command line and the web server don't always agree.
2. Scan. Static analysis tools like PHPStan and Rector, plus the PHPCompatibility rules for PHP_CodeSniffer, find most version problems before anything runs.
3. Update dependencies. Bring Composer packages, plugins and the framework up to versions that support 8.5. I check the lock file diff while I'm there, which matters more after this year's Composer supply chain attacks.
4. Stage and test. Copy the site to a staging environment on 8.5, then click through the real workflows: checkout, forms, logins, imports, and every integration that talks to an outside API.
5. Cut over with a rollback. On cPanel, the MultiPHP Manager can switch PHP versions per domain, so rolling back is a setting, not a rebuild. On AWS, Azure or GCP, I keep the old image or container ready until the new one has run clean for a while.
6. Watch the logs. Deprecation notices and errors show up in the first few days. I fix them before they turn into tickets.

Old plugins may have no upgrade path. Sometimes the honest answer is to replace a component, not patch it.

Hosting can be the blocker. Some cheap hosts lag on new PHP versions. That's a reason to move hosts, not to stay on an unsupported PHP.

An upgrade isn't a rewrite. Don't let "while we're in there" turn a two-week job into a six-month one. Upgrade first, then improve.

None of these are reasons to wait. They're reasons to plan it properly.

The cheapest PHP upgrade is the one you schedule. The most expensive is the one you do in a hurry after a security advisory, or after someone else finds the hole first.

PHP2Shell is the live example. CISA added both PHP2Shell CVEs to its Known Exploited Vulnerabilities catalog on October 26, and PHP's October 21 fixes only went to 8.2 through 8.5. On 8.1 or older there's no patch to install. Here's what PHP2Shell is and how to check your server.

Is PHP 7.4 still supported?

No. PHP 7.4 reached end of life on November 28, 2022, and the PHP project doesn't release fixes for it anymore. PHP 8.0 ended November 26, 2023, and PHP 8.1 ended December 31, 2025.

When does PHP 8.2 reach end of life?

PHP 8.2 gets security fixes until December 31, 2026. After that it's end of life, so plan to move to 8.4 or 8.5 before then.

How long will PHP 8.5 be supported?

PHP 8.5 has active support until December 31, 2027 and security support until December 31, 2029, according to php.net.

Should I wait for PHP 8.6?

Not if you're on an unsupported version. PHP 8.6 is scheduled for November 19, 2026. Move to 8.5 now and plan the 8.6 upgrade once it has a few patch releases and your frameworks and plugins support it.

• PHP.net, "Supported Versions"
• PHP.net, "Unsupported Branches"
• PHP.net, "PHP 8.5 Release Announcement"
• PHP.net, "News Archive 2026" (PHP2Shell security advisory, Oct 21, 2026)
• PHP Wiki, "PHP 8.6 Preparation Tasks" (release timetable)