PHP 8.2 security support ends on December 31, 2026

PHP 8.2 receives security fixes from the PHP project through December 31, 2026. From 2027 onward, the project will no longer publish security fixes for this branch. Your application will still run, but newly reported vulnerabilities may remain unpatched. If a business application still runs PHP 8.2, plan the move before the end of the year.

What the deadline means

The date describes support from the PHP project. A hosting provider may offer its own security fixes or extended support. Ask which PHP versions are covered, how long fixes will be available and who installs them. A general promise to "maintain the server" does not answer those questions.

As of October 1, 2026, the official schedule is:

• PHP 8.2 receives security fixes only, through December 31, 2026.
• PHP 8.3 receives security fixes only, through December 31, 2027.
• PHP 8.4 is in active support, with security fixes planned through December 31, 2028.
• PHP 8.5 is in active support, with security fixes planned through December 31, 2029.

The longest support window does not make PHP 8.5 the right target by default. Your framework, Composer packages, extensions and hosting must support it. Pick the newest branch your application can run reliably without an unreasonable amount of change.

Find every PHP 8.2 runtime

Do not check only the home page. List every place PHP runs: the web server or PHP-FPM, containers, background workers, scheduled jobs, imports and CI pipelines. An application can use a different PHP version in the browser than in a cron job.

php -v reports the version for the command line you invoked. Compare it with the version used by the web process and production containers. Record who can update each environment.

Check the target version

Read the PHP requirement in composer.json and check the installed package versions in composer.lock. Ask Composer which packages block your chosen target, for example with composer why-not php 8.5. Also check whether your framework and required extensions such as intl, gd or imagick are available in the target environment.

Run Composer and your tests with the exact PHP version planned for production. composer check-platform-reqs can find missing extensions and platform requirements. A local setup with a different PHP version does not prove the production server is ready.

Upgrade in controlled steps

Start with a staging environment that matches production in PHP version, configuration and extensions. Check workflows where a failure would have real consequences: sign-in and permissions, payment or invoicing logic, integrations, background workers and scheduled jobs. Review the logs for new warnings too.

Plan the rollback before release. Keep the previous deployment available and check whether database changes remain compatible with the old PHP version. Changing PHP, the framework and the database schema at the same time makes failures harder to diagnose.

Use the remaining weeks for a fixed sequence. Inventory runtimes and dependencies in October. Resolve incompatible packages and test the target in November. Leave time to monitor and correct the production rollout instead of waiting until December 31.

If nobody can say which PHP version the application uses in production, start with that inventory. PHP modernization explains how to prepare a version upgrade for an established application.

Source: PHP Supported Versions.