PHP 8.1 no longer appears on php.net's list of supported versions, so treat it as end of life. PHP 8.2 receives security fixes only, until 31 December 2026, which is about ten weeks from this review. Record both now and plan the move to 8.3 or newer.
What php.net lists today
The php.net supported versions page, viewed on 19 October 2026, lists branches 8.2 through 8.5. For each it shows an active support date and a security support date:
| Branch | Active support until | Security support until |
|---|---|---|
| 8.2 | 31 December 2024 | 31 December 2026 |
| 8.3 | 31 December 2025 | 31 December 2027 |
| 8.4 | 31 December 2026 | 31 December 2028 |
| 8.5 | 31 December 2027 | 31 December 2029 |
PHP 8.1 is absent from that table. A widely used lifecycle tracker records its security support as ending on 31 December 2025, which matches what the official page implies.
The page defines the two phases. Active support means reported bugs and security issues are fixed and regular point releases ship. Security fixes only means critical security issues are handled, with releases made as needed. End of life means users should upgrade.
Why PHP version matters beyond the language
Your framework sets a floor. Laravel's release notes, for example, list the PHP versions each Laravel major supports, and the newest listed release there needs PHP 8.3 or higher. If your framework version pins you to an old PHP, the framework upgrade and the runtime upgrade are one project. For the framework side, see dependency audit checklist for Rails and Laravel teams for the wider audit.
Where PHP 8.1 hides
- Shared hosting and managed platforms where the PHP version is a dashboard setting.
- Docker images pinned to an old tag.
- Composer files with a platform setting that forces an older version in resolution.
- CI images used only for tests, which can differ from production.
The composer.json require field for php and the config platform block both tell you what the project claims to support. They do not tell you what runs in production, so check both the declared and the running version. Declared, built and running explains why those three can disagree.
A 10 week plan for PHP 8.2
- Week 1: list every service on 8.2 and every one still on 8.1 or older.
- Weeks 2 and 3: run your test suite on 8.3 in CI as a non-blocking job.
- Weeks 4 to 6: fix deprecations, upgrade the framework if it forces the issue.
- Weeks 7 to 9: roll out service by service, lowest risk first.
- Week 10: confirm nothing is left on 8.2, and record exceptions with an owner and date.
If a service cannot move in time, write an exception rather than leaving the gap silent. A vulnerability exception for end-of-life software shows the fields.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how each component carries a version, which is the field a support date attaches to.
Where Safeguard fits
Safeguard's SBOM and dependency scanning lists your Composer packages and their versions, and asset discovery helps find the services running them. The free scan at gold.safeguard.sh/scan is a quick way to see your current list.
Quick check
Is PHP 8.1 safe to keep running?
It no longer gets upstream fixes. Keep it only with a dated exception, extra isolation, and a plan to move.
Does security fixes only mean I can wait?
You can wait until the stated end date, not past it. Use the time to migrate.
Sources
Last reviewed: 19 October 2026.
