PHP 8.3 end of life on 31 Dec 2027: the upgrade path to PHP 8.5

Summary. PHP 8.3 gets its last security fixes on 31 December 2027, and its bug-fix phase already ended on 31 December 2025. For most teams the target is PHP 8.5: released on 20 November 2025, it has security support until 31 December 2029. PHP 8.4, supported to 31 December 2028, is the fallback when a dependency blocks 8.5. PHP 8.6 is not ready: RC5 shipped on 5 November 2026, general availability is planned for 19 November 2026, and php.net has not published its support dates. October 2026 showed what is at stake: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fixed two unauthenticated remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, both scored 9.2 under CVSS v4.0. From 2028 the PHP project will not ship a fix like that for 8.3. Frameworks point the same way. Laravel 13 supports PHP 8.3 to 8.5, but the branch where Laravel 14 is being built requires 8.4, and every Symfony 8 release needs 8.4. WordPress supports PHP 8.5 from version 6.9. The main exception is Ubuntu 24.04, whose php8.3 package sits in Main and gets Canonical's security patches until May 2029.

About this article. This guide is for developers, tech leads, agencies and hosting owners who run PHP 8.3. On 7 November 2026 we checked every date, version and requirement against php.net's supported versions page, release announcements and migration guides, PHP's GitHub security advisories, the Laravel, Symfony and WordPress support pages, Ubuntu's package archive and release cycle page, and Microsoft Learn. For the regional notes we read the DPDP Rules, 2025 (G.S.R. 846(E), dated 13 November 2025) and Article 32 of the GDPR as published on EUR-Lex; those notes are not legal advice. PHP 8.6 was a release candidate on the check date, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

This guide covers the runtime decision. For the framework calendar, read our Laravel 12 end-of-life guide, and for patching the October flaws, our PHP2Shell fix guide.

What stops on 31 December 2027, and what does not

Each PHP branch gets two years of active support, with bugs and security issues fixed in regular point releases, then two years of critical security fixes only, released as needed, which can mean none. After four years it reaches end of life, and php.net advises users to upgrade quickly because they may be exposed to unpatched vulnerabilities. Since a 2024 process change, end dates fall on 31 December.

What stops. New 8.3.x releases from the PHP project. The latest on 7 November 2026 is 8.3.36, a security release.

What does not stop. Your applications. Nothing switches off on 1 January 2028, and code keeps running on whatever PHP build the server has.

What becomes your problem. Every vulnerability disclosed after that date. In October 2026, given the severity of the two RCE flaws, PHP's security team did publish minimal source backports for the unsupported 7.4, 8.0 and 8.1 branches, as git branches rather than releases. That was a one-off, so do not plan on it.

Who might still patch it. Linux distributions and commercial vendors, for their own packages; see the hosting section.

PHP support dates side by side

The dates below come from php.net's supported versions page and its release branches feed, with the latest releases as listed on 7 November 2026. The PHP 8.6 row uses the project's published timetable.

Two points are easy to miss. PHP 8.5 leaves active support on the day 8.3 reaches end of life, so from January 2028 it gets security fixes only. And if PHP 8.6 follows the same pattern, its security support would run to 31 December 2030; that is our projection, not a php.net date.

PHP ships a new branch each year in late November or early December: 8.2 on 8 December 2022, 8.3 on 23 November 2023, 8.4 on 21 November 2024 and 8.5 on 20 November 2025. If that holds, another branch will arrive just before 8.3 ends, so pick targets by security date, not by newest version.

Pick a target: PHP 8.4, 8.5 or 8.6

For most production estates we recommend PHP 8.5, tested through 8.4 in CI: fix the 8.4 step first, while 8.3 still gets patches, then take the smaller 8.5 step. Treat 8.6 as a target once your framework lists it.

Framework and CMS compatibility

Sources: Laravel's support policy and master branch, symfony.com's release pages, which give minimum PHP versions only, and WordPress's compatibility table, updated on 4 November 2026.

Laravel. Laravel 13 runs on PHP 8.5 today, and its security window ends about 11 weeks after PHP 8.3's: 17 March 2028 against 31 December 2027. The stronger signal is the master branch, which requires PHP 8.4 or later. An app still on 8.3 when Laravel 14 ships cannot take it.

Symfony. Symfony 6.4 LTS stops getting bug fixes in November 2026 and security fixes in November 2027, a month before PHP 8.3. An estate on Symfony 6.4 and PHP 8.3 therefore hits two deadlines within weeks. Symfony 8 requires PHP 8.4, so PHP 8.3 cannot run it at all, and Symfony 8.2 was still in beta on 7 November. The practical route is Symfony 7.4 LTS, supported to November 2029, on PHP 8.4 or 8.5, after checking your bundles' own test matrices.

WordPress. Core supports PHP 8.5 from WordPress 6.9, and WordPress 7.0 dropped PHP 7.2 and 7.3. WordPress.org recommends PHP 8.3 or newer with MariaDB 10.11 or MySQL 8.0 or newer, and warns that the end-of-life versions it still runs on can leave a site open to security flaws. WordPress 7.2, the last major release of 2026, is planned for 10 December 2026, so watch whether it adds PHP 8.6 to the table. Plugins and themes are the usual constraint, so test the full plugin set on staging.

Hosting: who patches your PHP after 2027

Where PHP comes from decides whether 1 January 2028 changes anything. Default versions are from Ubuntu's package archive and dates from its release cycle page.

Ubuntu 24.04. Canonical says LTS releases get five years of standard security maintenance, with CVE patches for packages in the Main repository, and php8.3 sits in Main. Canonical backports fixes into 8.3.6 rather than shipping php.net's releases: the noble-updates build is 8.3.6-0ubuntu0.24.04.13, and its changelog shows the October RCE fixes landing on 19 October 2026. Three problems remain. Scanners that compare version strings with php.net may flag 8.3.6. Laravel 14 and Symfony 8 will not run on 8.3, whoever patches it. And the coverage applies to the distribution's package, not to third-party PPA builds. Ubuntu Pro's Expanded Security Maintenance runs to May 2034. Our Ubuntu 24.04, 26.04 and RHEL 10 server comparison helps pick the next base.

Managed platforms. Azure App Service follows each language community's support timeline. After end of support, apps keep running, but App Service provides no security patches or support for that runtime and will not support the app until it moves to a supported version; it sends reminder notifications to subscription owners. Check each host's policy rather than assuming it matches Azure's.

Shared hosting and control panels. On cPanel or Plesk, PHP is often a per-site dropdown: quick to switch, easy to break. Ask your host which builds it offers, who patches them, and whether IMAP, OCI8, PDO_OCI and PSpell are available for PHP 8.4 and later.

Containers. Pin a supported PHP minor version in the base image, rebuild on every patch release, and fail builds whose PHP falls out of support.

Breaking changes from PHP 8.3 to 8.4

This hop is the one most likely to touch application code. The PHP manual also warns that any new function, class, interface, enum or constant can cause a redeclaration error in code that already uses the name.

Breaking changes from PHP 8.4 to 8.5

The 8.5 hop is smaller, but several items touch configuration files rather than code, so they surface at deploy time.

PHP 8.5 also soft-deprecates the __sleep() and __wakeup() magic methods; move classes to __serialize() and __unserialize() as you touch them.

The upgrade runbook

            # 1. Inventory: version, extensions and loaded ini files per environment
php -v
php -m
php --ini

# 2. Dependency readiness for the target version
composer check-platform-reqs
composer why-not php 8.5
composer audit

# 3. Run the suite with every deprecation visible
php -d error_reporting=E_ALL -d display_errors=1 vendor/bin/phpunit
          

1. Patch now. Be on 8.3.36 or your distribution's patched build, which carry the October 2026 fixes. On Windows, use the 8.3.36-1 rebuild from 26 October, which bundles a fixed Brotli library. Until the next regular release, php.net also suggests setting session.upload_progress.enabled=0 to close an unlikely remote code execution path.

1. Inventory every environment. Record the PHP version, SAPI (PHP-FPM, Apache mod_php or LiteSpeed), extensions, php.ini overrides, OS image and who supplies the build. Flag any use of IMAP, OCI8, PDO_OCI or PSpell.

1. Set the target in Composer. Update require.php and any config.platform.php pin, then use composer why-not php 8.5 to list blocking packages.

1. Add a CI matrix. Test on 8.3, 8.4 and 8.5. Add 8.6 as an allowed failure once it is out.

1. Fix the 8.4 hop first. Clear implicitly nullable parameters, CSV escape arguments and removed-extension calls while production stays on a patched 8.3.

1. Diff the configuration. Remove disable_classes, zend_extension=opcache.so and E_STRICT masks; set opcache.jit explicitly if you use JIT; review session settings.

1. Stage with production-like data. Run queues, cron jobs and imports with error_reporting=E_ALL and read the deprecation log.

1. Roll out gradually. Move one PHP-FPM pool or host at a time and keep the 8.3 build installed for rollback until error rates settle.

1. Close the loop. Remove 8.3 packages, update the asset register and diary the next date: 31 December 2029 for PHP 8.5.

Worked example: a 20-site agency estate

Assume an agency maintains 20 sites: 12 WordPress, 5 Laravel 13 and 3 Symfony 6.4. As illustrative assumptions, a WordPress site needs half an engineer-day for plugin checks and staging, a Laravel 13 app needs 2 days because the framework already supports PHP 8.5, and a Symfony 6.4 app needs 5 days because it must also move to Symfony 7.4 LTS.

Total effort. (12 × 0.5) + (5 × 2) + (3 × 5) = 6 + 10 + 15 = 31 engineer-days.

The cost of waiting. Started in January 2027, with about 50 working weeks to 31 December, that is 31 ÷ 50 ≈ 0.6 engineer-days a week. Started with 12 weeks to go, it is 31 ÷ 12 ≈ 2.6 engineer-days a week, landing during year-end change freezes.

Order of work. Do the three Symfony apps first: Symfony 6.4's bug fixes end in November 2026 and its security fixes in November 2027, a month before PHP 8.3's. Then the Laravel apps, then batch the WordPress sites by shared plugin sets.

India and EU notes

India. Rule 6 of the DPDP Rules, 2025 requires reasonable security safeguards, and it comes into force eighteen months after the rules' publication on 13 November 2025, which computes to 13 May 2027. That is more than seven months before PHP 8.3 reaches end of life. An unsupported runtime under an app that handles personal data would be hard to defend as a reasonable safeguard; our DPDP Rules checklist covers the wider controls.

EU. GDPR Article 32 asks for security appropriate to the risk, taking account of the state of the art, without naming software versions. A dated runtime plan also answers customer questionnaires that ask whether your stack is supported.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our PHP development team runs PHP estate inventories, PHP 8.4 and 8.5 runtime moves with CI version matrices, Laravel and Symfony upgrades, WordPress plugin compatibility testing and hosting migrations. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Supported Versions — PHP

1. Release branches feed (JSON) — PHP

1. PHP 8.6.0 RC5 available for testing, 5 November 2026 — PHP

1. Security advisory: critical remote code execution vulnerabilities, update now, 21 October 2026 — PHP

1. RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — PHP on GitHub

1. RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — PHP on GitHub

1. Release notes and support policy, Laravel 13.x — Laravel

1. laravel/framework composer.json, master branch — GitHub

1. Symfony releases data (JSON) — Symfony

1. PHP Compatibility and WordPress Versions, updated 4 November 2026 — WordPress Core Handbook

1. Ubuntu release cycle — Canonical

1. PHP RFC: Release cycle update — PHP Wiki

1. PHP 8.3.36 release announcement — PHP

1. PHP 8.6 preparation tasks and timetable — PHP Wiki

1. Symfony releases — Symfony

1. Symfony 6.4 release — Symfony

1. Symfony 7.4 release — Symfony

1. Requirements — WordPress.org

1. Roadmap — WordPress.org

1. Package search results for php in all suites — Ubuntu Packages

1. Package php8.3 in noble-updates — Ubuntu Packages

1. php8.3 8.3.6-0ubuntu0.24.04.13 changelog — Ubuntu

1. Language runtime support policy for Azure App Service — Microsoft Learn

1. Migrating from PHP 8.3.x to PHP 8.4.x: backward incompatible changes — PHP Manual

1. Migrating from PHP 8.3.x to PHP 8.4.x: deprecated features — PHP Manual

1. Migrating from PHP 8.3.x to PHP 8.4.x: removed extensions — PHP Manual

1. Migrating from PHP 8.4.x to PHP 8.5.x: backward incompatible changes — PHP Manual

1. Migrating from PHP 8.4.x to PHP 8.5.x: deprecated features — PHP Manual

1. Updated PHP Windows builds for Brotli security fix, 26 October 2026 — PHP

1. Informational advisory: session upload progress, 23 October 2026 — PHP

1. Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025 — Ministry of Electronics and Information Technology

1. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 32 — EUR-Lex