Blog details
PHP 8.2 security support ends 31 Dec 2026 (php.net). What it means for Laravel apps in Egypt and the Gulf, the risks, and a safe upgrade plan.
Short answer: PHP 8.2 stops receiving security fixes on 31 December 2026, according to the official PHP supported versions page. After that date, any new vulnerability in PHP 8.2 stays unpatched by the PHP project. If your Laravel app runs on PHP 8.2, plan to move to PHP 8.3 at minimum, and ideally 8.4, before the end of the year. Test it on a copy first, upgrade dependencies, and only then switch production.
By Mohamed Samy, senior Laravel/PHP backend developer (7 years). Published: 26 October 2026. Last updated: 26 October 2026.
Last week I wrote about PHP2Shell, the critical PHP vulnerabilities fixed on 21 October 2026. The fix for PHP 8.2 was version 8.2.35. That patch existed because PHP 8.2 is still in its security-only period. In about two months, it won't be. The next time something like PHP2Shell appears, there will be no official 8.2 fix.
This guide is for business owners and technical managers in Egypt first, and then Saudi Arabia, the UAE, Kuwait, Qatar, Bahrain and Oman, who run a custom Laravel or PHP application and want a calm, practical plan instead of a last-minute panic in late December.
The official dates
These are taken directly from php.net and the Laravel documentation, both checked on 26 October 2026.
| PHP version | Active support until | Security support until |
|---|---|---|
| 8.2 | 31 Dec 2024 (ended) | 31 Dec 2026 |
| 8.3 | 31 Dec 2025 (ended) | 31 Dec 2027 |
| 8.4 | 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | 31 Dec 2027 | 31 Dec 2029 |
Source: php.net supported versions.
| Laravel version | Supported PHP | Bug fixes until | Security fixes until |
|---|---|---|---|
| 10 | 8.1 to 8.3 | 6 Aug 2024 | 4 Feb 2025 (ended) |
| 11 | 8.2 to 8.4 | 3 Sep 2025 | 12 Mar 2026 (ended) |
| 12 | 8.2 to 8.5 | 13 Aug 2026 | 24 Feb 2027 |
| 13 | 8.3 to 8.5 | Q3 2027 | 17 Mar 2028 |
Source: Laravel 13 release notes, support policy.
Reading the two tables together tells you a lot. If you are on Laravel 10 or 11, your framework is already out of security support, and the PHP 8.2 deadline makes it urgent. If you are on Laravel 12, you can move to PHP 8.3 or 8.4 without changing the framework, but Laravel 12 itself loses security fixes in February 2027. Laravel 13 requires PHP 8.3 or newer.
What "end of life" actually means for your business
End of life does not mean your site switches off on 1 January. It keeps running. What changes is risk:
- No security patches from the PHP project. New vulnerabilities in 8.2 will not be fixed upstream. Some Linux distributions and paid vendors backport fixes for a while, but that depends on your exact server and contract, so check it, don't assume it.
- Packages move on. Composer packages gradually drop old PHP versions, so you get stuck on old versions of libraries too.
- Hosting pressure. Hosting providers and control panels often remove old PHP versions or push upgrades on their own timeline.
- Compliance questions. If you handle payments or personal data, running unsupported software becomes hard to justify to a payment provider, an auditor or a large client.
Why upgrades break, and why that is manageable
In my experience, a PHP upgrade rarely breaks the parts of the app you wrote recently. It breaks the old corners: a package nobody updated in years, a helper that relied on deprecated behaviour, or a server extension that was never installed on the new version. PHP publishes migration guides for each version (linked from the supported versions page), and they list the deprecations and backward-incompatible changes. The work is finding where your code touches them.
Common things I check:
- Dynamic properties on classes, which PHP 8.2 already deprecated. If your logs are full of deprecation warnings today, they are a to-do list for the upgrade.
- Abandoned Composer packages with no release that supports PHP 8.3 or newer.
- Custom code that depends on specific extensions (image processing, PDF, payment SDKs).
- Cron jobs, queue workers and CLI scripts that run on a different PHP binary than the website.
A safe upgrade plan for a Laravel app
Step 1: Take inventory
Write down the exact PHP version on every server (web, queue workers, cron), the Laravel version, and the list of Composer packages. Run php -v on each server and composer show in the project.
Step 2: Choose your target versions
For most Laravel 12 apps, PHP 8.4 is a sensible target because it has security support until the end of 2028. If you are on Laravel 10 or 11, plan the framework upgrade too, since both are already out of security support.
Step 3: Create a staging copy
Clone the app and a recent, anonymised copy of the database onto a staging server running the target PHP version. Never test an upgrade on production.
Step 4: Upgrade dependencies and fix deprecations
Run composer outdated, update packages to versions that support your target PHP, replace abandoned ones, and fix the deprecation warnings from the logs. Follow the official Laravel upgrade guide for each framework version you cross, one major version at a time.
Step 5: Test what makes you money
Run the automated tests if you have them, then test the critical paths by hand: login, checkout or payment, bookings, invoices, emails, queues, scheduled jobs and any external integration.
Step 6: Roll out with a way back
Take a full backup, schedule the switch at a low-traffic time, keep the old PHP version available for a quick rollback, and watch the error logs closely for the first days.
How long does it take?
Honestly, it depends on the app. A well-maintained Laravel 12 app with tests may only need a PHP version change and a day of checking. A Laravel 8 or 9 app with old packages may need several framework upgrades in a row, and that is real project work. The worst case is discovering this in the last week of December, when hosting companies are busy and your team is on holiday. Starting in November gives you room to test properly.
A note for the Gulf and Egypt
Many custom systems in Egypt and the Gulf were built a few years ago by a team that is no longer around, and the business only knows that "the system works". If that is you, the first step is not the upgrade itself, it is an audit: which PHP and Laravel versions are you on, who has server access, and is the code in your hands? In Saudi Arabia and the UAE, where many systems connect to payment gateways and e-invoicing, check those integrations specifically, because their SDKs often have their own PHP requirements.
FAQ
When does PHP 8.2 reach end of life?
On 31 December 2026, according to php.net. After that date the PHP project no longer releases security fixes for 8.2.
Will my website stop working after PHP 8.2 end of life?
No. It will keep running, but new vulnerabilities in PHP 8.2 will not be patched by the PHP project, so the risk grows over time.
Which PHP version should I upgrade to?
PHP 8.4 is a good target for most Laravel 12 and 13 apps because it has security support until 31 December 2028. PHP 8.3 is the minimum for Laravel 13 and is supported until the end of 2027.
Do I have to upgrade Laravel as well?
If you are on Laravel 10 or 11, yes, because they are already out of security support. Laravel 12 supports PHP 8.2 to 8.5, so you can change PHP first and plan the move to Laravel 13 afterwards.
Can my hosting company just switch the PHP version for me?
They can switch the version, but they cannot guarantee your code and packages will work on it. Test on a staging copy first.
Is this related to PHP2Shell?
Indirectly. PHP2Shell was fixed for PHP 8.2 in version 8.2.35 because 8.2 was still in security support. After 31 December 2026, a similar issue would get no official 8.2 fix.
Sources
- PHP Group, Supported Versions: php.net/supported-versions.php
- Laravel 13 Release Notes, Support Policy: laravel.com/docs/13.x/releases
- Laravel 13 Upgrade Guide: laravel.com/framework/docs/13.x/upgrade
- All dates checked on 26 October 2026.
Need a second pair of eyes?
If you're not sure what your system is running or how big the upgrade is, send us a short note. We can start with an audit of your Laravel app and give you a clear upgrade plan before you commit to anything. For reference, our proposed Laravel Audit package is EGP 17,500 (16 hours, 5 working days), and a Laravel version upgrade is a separate proposed add-on starting from EGP 10,000 depending on the size of the app. Both are proposed prices, and the final figure is confirmed after we see the code. Everything we build or upgrade is done custom, on your own codebase. Reach the Golden Code team through the contact page.
About the author: Mohamed Samy is a senior backend developer at Golden Code with 7 years of experience building, maintaining and upgrading custom Laravel and PHP systems.
