DeveloperPHP 8.1 Security Support Ends
PHP 8.1 security support ends in November 2025. If you are running PHP 8.1 in production, upgrade to PHP 8.2 or 8.3 for continued security patches. Web applications on unsupported PHP versions accumulate risk quickly.
Editorially reviewed for factual accuracy
PHP 8.1 exits upstream security support on 25 November 2025, ending the patch stream that has covered vulnerabilities in the JIT compiler, OpenSSL bindings, XML parser, and standard library since the branch’s 2021 debut. Teams that still compile or deploy PHP 8.1 must treat the date as a hard stop for vendor fixes and transition to supported runtimes before public vulnerability disclosures expose unpatchable production systems.
What the security-support cutoff means
PHP’s supported-versions policy provides two years of active support with bug and security fixes followed by a final year of security-only maintenance. For PHP 8.1, the active support window closed on 25 November 2023; the security-only window concludes on 25 November 2025, at which point the upstream PHP Group halts release tarballs, CVE assignments, and Git branch maintenance. Extension maintainers who followed the upstream cadence will stop backporting patches to 8.1 after that date, so even community packages that still claim 8.1 compatibility will now focus on newer runtimes.
The cutoff matters because PHP underpins widely deployed frameworks (Laravel 9, Symfony 6) and content platforms (WordPress, Drupal) that inherited PHP 8.1 as a default runtime in long-lived LTS images published during 2022–2023. Security fixes released after November 2025 for these frameworks will assume the availability of PHP 8.2+ functions and will not be backported to legacy branches, leaving teams with dependency conflicts and vulnerable extensions if they remain on 8.1.
Risk posture, compliance, and dependency exposure
Staying on PHP 8.1 past the end-of-security date amplifies three risks. First, new remote code execution or deserialization flaws disclosed in PHP core or common extensions will remain unpatched upstream, and exploit kits targeting unmaintained versions historically appear within weeks.
Second, operating system vendors that repackage PHP (Debian, Ubuntu, Red Hat, Alpine) align their own maintenance schedules to the upstream lifecycle; once the upstream branch closes, vendors either drop the package or move it to extended support channels that require paid contracts, leaving default repositories without fixes. Third, compliance baselines such as PCI DSS and SOC 2 expect supported software with timely security updates; auditors frequently flag out-of-support runtimes as control failures regardless of compensating controls.
Developers also inherit dependency friction. Composer packages now declare PHP 8.2 or 8.3 as the minimum requirement because of new language features (readonly classes, intersection types, improved enums) and deprecation removals in PHP 8.1 (dynamic properties, ${} string interpolation). Build pipelines that stay pinned to 8.1 will find fewer updated packages available, and container base images will shrink in number as official Docker library images and distribution base images deprecate the branch.
Migration plan to supported PHP versions
Teams should target a move to PHP 8.2 or 8.3 ahead of the November 2025 deadline. The PHP supported-versions matrix shows PHP 8.2 remains under security support until 8 December 2025 and PHP 8.3 retains active support until November 2025 with security coverage into November 2026, giving teams overlap to complete validation. Start by inventorying runtime footprints: identify FPM pools, CLI jobs, queue workers, cron tasks, and embedded PHP engines in third-party appliances. Update CI pipelines to run dual-version test suites on PHP 8.1 and 8.2/8.3 to surface deprecations early.
Next, remediate language-level incompatibilities. Enable `E_DEPRECATED` in non-production environments to catch dynamic property usage, reliance on implicit resource-to-object casting, or deprecated `utf8_encode`/`utf8_decode` calls. Replace removed Sodium and OpenSSL function aliases with supported equivalents, update Doctrine and Symfony components to versions that declare PHP 8.2 support, and confirm Composer plugins operate correctly under the newer runtime. Use `composer why-not` to resolve package constraints that prevent upgrades and pin dependency sources to versions released within the past twelve months.
Finally, plan cutovers environment by environment. For containerised workloads, rebuild images using official `php:8.2-fpm` or `php:8.3-fpm` bases with matching extensions and INI settings. For bare-metal or VM deployments, ensure package repositories point to supported PHP streams and align opcache and JIT settings with the new runtime defaults. Instrument pre- and post-upgrade performance metrics to validate opcode cache warmup, memory usage, and latency changes, and retain rollback paths only for short durations to avoid drifting back to 8.1.
Operational readiness and governance
Coordinate communication with security and compliance teams to record the decommissioning of PHP 8.1 as a formal risk reduction action. Update asset inventories, SBOMs, and vulnerability management records to reflect the planned runtime upgrade and to remove PHP 8.1 from exception lists once cutover completes. Document how incident response processes will handle any residual 8.1 systems during the transition, including segmentation and virtual patching controls if immediate upgrades are not possible for a small subset of workloads.
Service owners should also update disaster recovery artifacts. Backup and restore procedures must be tested against the new runtime to ensure application data formats and serialization mechanisms remain compatible. High-availability clusters that used mixed-version nodes temporarily must be re-homogenised on the target runtime to avoid divergence in cache formats or session handling. Where SaaS products embed PHP (for example, marketing automation or customer experience platforms), request vendor attestations confirming their upgrade timeline so supplier risk records are complete.
The November 2025 cutoff is not a theoretical milestone; it represents the point at which security bulletins will stop landing for PHP 8.1 and threat actors will focus on lagging deployments. By starting compatibility tests now, adjusting Composer constraints, and sequencing environment migrations, engineering teams can complete the move to PHP 8.2 or 8.3 well before the upstream maintenance window closes and keep compliance and performance baselines intact.
Verification checklist and supplier management
Before declaring the migration complete, teams should complete a verification checklist: confirm application error budgets and SLOs held steady across the cutover; validate that observability dashboards track PHP version metrics; and ensure blue-green or canary release steps are documented for future runtime updates.
Dependency snapshots and SBOMs should be regenerated under the new runtime so vulnerability scanners and software composition analysis tools reflect the updated library graph. Where commercial support agreements cover PHP (for example, paid distributions or managed hosting platforms), request updated support statements that explicitly cite PHP 8.2 or 8.3 to avoid ambiguity during incident response.
Vendor and supplier coordination is equally important. Many SaaS extensions, plug-ins, and managed commerce platforms bundle PHP components that follow the upstream lifecycle; seek attestations from those providers that their environments will shift off PHP 8.1 before the end-of-support date. Include runtime migration status in quarterly business reviews with key suppliers, and document contingency plans if a supplier lags. Transparent communication ensures external dependencies do not reintroduce the very exposure that the core engineering team is closing.
Continue in the Developer pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Secure Software Supply Chain Tooling Guide
Engineer developer platforms that deliver verifiable provenance, SBOM distribution, vendor assurance, and runtime integrity aligned with SLSA v1.0, NIST SP 800-204D, and CISA SBOM…
-
AI-Assisted Development Governance Guide
Govern GitHub Copilot, Azure AI, and internal generative assistants with controls aligned to NIST AI RMF 1.0, EU AI Act enforcement timelines, OMB M-24-10, and enterprise privacy…
-
Developer Enablement & Platform Operations Guide
Plan AI-assisted development, secure SDLC controls, and runtime upgrades using our research on GitHub Copilot, GitHub Advanced Security, and major language lifecycles.
Coverage intelligence
- Published
- Coverage pillar
- Developer
- Source credibility
- 90/100 — high confidence
- Topics
- PHP 8.1 · Runtime lifecycle · Security maintenance · Composer dependencies · Upgrade planning
- Sources cited
- 3 sources (php.net, iso.org)
- Reading time
- 6 min
Documentation
- PHP Supported Versions — php.net
- PHP 8.1.0 Release Announcement — php.net
- ISO/IEC 27034-1:2011 — Application Security — International Organization for Standardization
Comments
Community
We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.
No approved comments yet. Add the first perspective.