PHP Site AuditPHP maintenance
How PHP support dates should shape your upgrade plan
PHP branches receive a defined support period and eventually stop receiving fixes from the PHP project. As of October 23, 2026, PHP lists 8.2 security support through December 31, 2026, 8.3 through December 31, 2027, 8.4 through December 31, 2028, and 8.5 through December 31, 2029. Vendors may provide separate backports, so check both PHP and your supplier.
Support is a lifecycle, not a single newest-version rule
PHP's supported-versions page describes two years of active support followed by two years of security fixes for each branch. Once support ends, the branch no longer receives fixes from the PHP project. The page lists branch-specific dates and should be checked when making upgrade plans because schedules can change.
A branch that is still supported can receive security releases even when a newer major or minor branch exists. At the same time, software compatibility, hosting support, and application dependencies can affect which branch a site can run.
Plan for testing before end of support
Inventory the PHP branch used by each public service and the applications, extensions, and vendor packages it depends on. Track the date security support ends, select a target branch, and test the application while there is time to resolve incompatibilities. Schedule routine patch deployment separately from the larger version migration.
The PHP2Shell release provides an example: upstream fixes were released for PHP 8.2 to 8.5 on October 21, while PHP advises users on older branches to consult their distributions or upgrade. If a vendor maintains a legacy branch, ask which advisory and package backport it supplies; do not assume support from one supplier applies to another.
Document ownership and evidence
Keep the host, technical owner, branch, support end date, update route, and tested upgrade target in a small inventory. Revisit it when renewing a hosting plan or changing deployment providers. A hidden version banner is not a substitute for knowing which maintained runtime serves the site.
A runtime upgrade can require testing extensions, build tooling, background jobs and third-party integrations. Start compatibility work before the support deadline, maintain a rollback path, and ask the vendor whether the current backport service has a stated end date.
Common questions
Does a vendor backport make an old branch supported by PHP?
Not necessarily. It may address named fixes under a vendor policy after PHP project updates have ended.
When should I plan an upgrade?
Review PHP and vendor support dates, application compatibility, extension support and migration testing time.
Can I wait for the next application release?
Keep the immediate CVE fix separate from the longer migration and ask the host about a supported vendor patch.