If you run PHP 8.1 or older, you are on a version that got no official fix for the critical remote code execution bugs patched on 21 October 2026. PHP 8.2 reaches end of life on 31 December 2026. The case to upgrade your PHP version is now mostly about security, and the target I recommend is 8.4 or 8.5.
I lead engineering for products built on Laravel and PHP, so this post is about how I think about a minor-version jump, such as 8.2 to 8.4 or 8.3 to 8.5. It covers why you should do it, how to check you’re ready, and how to switch without betting production on it.
Why upgrade your PHP version now
Security: end-of-life versions missed the October 2026 fixes
On 21 October 2026, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code execution, and php.net rates them CVSS v4.0 9.2 (php.net release archive). Teams on 8.2 through 8.5 got a normal package update.
Teams on 8.1, 8.0 and 7.4 got no official release. The security team published only minimal source backports. That is what end of life costs in practice. When the next serious bug lands, you are compiling patches yourself or hoping your host does it for you.
If you want the details of what those two bugs do and who is exposed, I covered them in the October 2026 PHP vulnerability.
If you want the details of what those two bugs do and who is exposed, I covered them in the October 2026 PHP vulnerability.
One more trap: a version number doesn’t tell you everything. Ubuntu 24.04 ships PHP 8.3.6 with security fixes backported into its package (packages.ubuntu.com), so php -v can look old on a patched server. Ondřej Surý’s PPA also builds EOL branches like 7.x, 8.0 and 8.1 (Launchpad). Being able to install a package doesn’t mean PHP still supports that branch.
If you can’t upgrade today, this Forge Recipe applies PHP’s temporary mitigation while you plan the move.
Performance and language features
I won’t sell you this upgrade on speed. Tideways benchmarked Laravel, Symfony and WordPress across PHP versions and found performance “does not move much” between 8.2 and 8.5, with no visible difference for Laravel between 8.4 and 8.5 (Tideways). Kinsta’s WordPress runs show 146.09 requests per second on 8.2 and 148.30 on 8.5 (Kinsta).
The bigger gains come from leaving 7.x behind and from new language features and APIs. To get those, you have to change your code. Plan for that work instead of expecting a free speed boost.
Dependencies drop old PHP
Your framework sets the pace. Laravel 13 requires PHP 8.3 or newer, and Laravel 12’s bug fixes ended on 13 August 2026 (Laravel 13 release notes). A team on Laravel 12 and PHP 8.2 is stuck on both sides: the framework gets security fixes only, and the runtime loses those at the end of the year. You can’t move to Laravel 13 until PHP moves first.
PHP end of life dates (2026 table)
Each PHP branch gets two years of active support, then two years of security fixes only, then reaches end of life. These dates come from php.net/supported-versions.php and php.net/eol.php, checked 23 October 2026.
| Branch | Active support until | Security support until | Status today |
|---|---|---|---|
| 7.4 | — | 28 Nov 2022 | End of life |
| 8.0 | — | 26 Nov 2023 | End of life |
| 8.1 | — | 31 Dec 2025 | End of life |
| 8.2 | 31 Dec 2024 | 31 Dec 2026 | Security only, about two months left |
| 8.3 | 31 Dec 2025 | 31 Dec 2027 | Security only |
| 8.4 | 31 Dec 2026 | 31 Dec 2028 | Active |
| 8.5 | 31 Dec 2027 | 31 Dec 2029 | Active, current stable |
You’ll see different EOL dates on other sites. Kinsta says 8.1 reached end of support at the end of November 2025, but php.net says 31 December 2025. When sources disagree, go with php.net. The 8.2.35 release note says plainly that 8.2 “will receive no further security fixes after” 31 December 2026 (php.net).
Two things change on 31 December 2026: 8.2 reaches end of life, and 8.4 leaves active support. PHP 8.6 is also in release candidates (RC4 came out on 21 October 2026), but php.net hasn’t confirmed its final release date yet. If you are on 8.2, that leaves you about ten weeks.
Upgrading vs patching: what’s the difference?
Patching stays within a branch, for example 8.3.35 to 8.3.36. Nothing should break, and you do it as soon as a security release ships. Upgrading changes the branch, for example 8.3 to 8.4. It can bring deprecations, removed behaviour and new extension packages, so it needs a planned project.
Don’t mix the two. During a security rollout, patch first and upgrade later. I covered the patch rollout in detail, including inventory, Docker rebuilds, CI and restarting workers, in how to patch PHP in Laravel production. This post covers the planned branch change, and I’ll point you to that post instead of repeating those steps.
Before you upgrade: compatibility checklist
Check your current PHP version
Check every place PHP runs, because they often differ. Run php -v on the command line. For the web server, check phpinfo() on a private, temporary page, since FPM can run a different version from the CLI. On shared hosting, your control panel shows the version per site. On Linux, update-alternatives --display php lists the installed CLI versions.
Scan your code and read the migration guides
Run a static scan against the target version before you touch a server. PHPCompatibility (a PHP_CodeSniffer standard) flags removed and deprecated features, and Rector can automate many of the code changes. Then read the php.net migration guide for every branch you’re crossing. Going from 8.2 to 8.5 means reading three guides, not one.
Check Composer constraints
Composer tells you who is blocking the upgrade:
composer why-not php 8.4
composer check-platform-reqsThe first command lists packages that won’t allow the target version. The second checks the real runtime and extensions against your lock file. Also look at config.platform.php in composer.json. If it’s pinned to the old version, Composer keeps resolving packages for old PHP even after the server moves (Composer docs).
Laravel version and PHP compatibility table
| Laravel | Supported PHP | Bug fixes until | Security fixes until |
|---|---|---|---|
| 10 | 8.1–8.3 | 6 Aug 2024 | 4 Feb 2025 (EOL) |
| 11 | 8.2–8.4 | 3 Sep 2025 | 12 Mar 2026 (EOL) |
| 12 | 8.2–8.5 | 13 Aug 2026 | 24 Feb 2027 |
| 13 | 8.3–8.5 | Q3 2027 | 17 Mar 2028 |
Sources: Laravel 13 and Laravel 12 release notes. My rule is to pick a PHP branch whose security support lasts longer than your Laravel version’s. Laravel 13 is supported until March 2028, so PHP 8.4 (to December 2028) or 8.5 (to December 2029) covers it. PHP 8.3 runs out first, in December 2027.
How to upgrade your PHP version (step by step)
On shared hosting (cPanel or your host’s PHP selector)
Most panels let you choose the PHP version per domain. Which versions you can pick depends on your host. Before you switch, take a full backup of files and database, and note the extensions and PHP settings enabled on the current version, because a new version may start with different defaults. Switch a staging subdomain first, click through the site, check the error log, then switch the live domain. Some hosts handle expired versions their own way. one.com, for example, turns on paid “PHP Extended Support” automatically (one.com). Don’t let that hide the fact that you need to upgrade.
On an Ubuntu VPS: install side by side, then switch the FPM pool
Install the new version next to the old one. Don’t remove anything yet. Extensions come packaged per version, so you need to reinstall each one for the new branch (php.watch):
# list what the old version uses
php8.2 -m
# install the new branch with matching extensions
sudo apt install php8.4-fpm php8.4-cli php8.4-mbstring php8.4-xml \
php8.4-curl php8.4-mysql php8.4-intl php8.4-redis
# point the CLI at the new version
sudo update-alternatives --set php /usr/bin/php8.4Copy your pool settings and any php.ini changes into /etc/php/8.4/. Then point the Nginx or Apache vhost at the 8.4 FPM socket and reload. If you use Ondřej Surý’s PPA, note that it says it’s moving to packages.sury.org (Launchpad), so check where your repository points.
In a Laravel project
Make the code changes on a branch, separately from the server change:
- Raise
require.phpincomposer.jsonto the new minimum, for example^8.4. - Raise
config.platform.phpto match, then runcomposer updateso the lock file is rebuilt for the new platform. A lock file resolved for old PHP can contain packages whose ownrequire.phpdoesn’t match. - Add the new version to your CI matrix and run the full test suite on both versions until you switch.
Test, roll out, and roll back safely
Staging comes first and should mirror production: the same extensions, the same FPM settings, and real queue jobs and scheduled tasks. Watch the logs for deprecation notices, not only fatal errors. Today’s deprecation notice is a fatal error in a later version.
For production, I keep rollback cheap. The old FPM version stays installed and its pool config stays untouched. Rolling back means pointing the vhost back at the old socket, setting the CLI back with update-alternatives, and redeploying the previous commit with its lock file. On shared hosting, it means choosing the old version in the panel again. Remove the old branch only after a few clean weeks. The restart and verification steps are the same as for a patch, and they’re covered in the companion post.
FAQ
Why should I upgrade my PHP version?
For security first, then package support. End-of-life versions like 8.1 got no official release for the critical October 2026 remote code execution fixes. Between 8.2 and 8.5, benchmarks show little speed difference, so think of the upgrade as staying patched and keeping your framework supported.
When does PHP 8.2 reach end of life?
PHP 8.2 reaches end of life on 31 December 2026, according to php.net. After that date it gets no security fixes, even for critical bugs. If you are on 8.2 today, plan the move to 8.4 or 8.5 before year end.
Which PHP version should I use in 2026?
Use PHP 8.4 or 8.5 if your dependencies allow it. 8.4 gets security fixes until 31 December 2028, and 8.5 until 31 December 2029. Both also outlast Laravel 13’s security support, which ends in March 2028.
How do I check my PHP version?
Run php -v on the command line, use phpinfo() on a private page to see the web server’s version, or look in your hosting panel. Check both CLI and web, because they can differ. Distro packages may also include backported fixes the version number doesn’t show.
Will upgrading PHP break my Laravel app?
It can, which is why you check first. Confirm your Laravel version supports the target PHP, run composer why-not php 8.4, update the platform setting and lock file, and run your full test suite on the new version in CI and staging before production.
What’s the difference between patching and upgrading PHP?
Patching stays within a branch, for example 8.3.35 to 8.3.36, and is a routine security update. Upgrading changes the branch, for example 8.3 to 8.4, and can include breaking changes and new extension packages. For the patch process, see how to patch PHP in Laravel production.
How do I roll back a PHP upgrade?
Keep the old version installed alongside the new one. Point the FPM pool or vhost back to the old socket, reset the CLI with update-alternatives, or choose the old version in your panel. Keep a backup and the previous commit with its pinned composer.lock so the code matches.
The deadline is 31 December
Upgrading your PHP version isn’t urgent because of speed. It’s urgent because of dates. If you’re on 8.1 or older, you’re already exposed. If you’re on 8.2, you have until the end of the year. Check your versions this week, run the Composer and compatibility checks, and schedule the move to 8.4 or 8.5. If you still have servers on an old patch level, start with how to patch PHP in Laravel production, then come back to plan the upgrade.
