DeveloperPHP 8.2 Security Support Ends
PHP 8.2 security support continues but plan ahead—each PHP version has a limited support window. Stay on actively supported versions to ensure security patches. PHP 8.3 and 8.4 are your forward path.
Fact-checked and reviewed — Kodi C.
PHP 8.2 reaches the end of its upstream security-support window on 8 December 2025, closing the final maintenance branch for the runtime released in December 2022. After that date the PHP Group will stop shipping security patch releases for the 8.2 series, and projects that continue to depend on it will have to self-maintain or accelerate upgrades to the currently supported 8.3 and 8.4 branches to preserve security posture and compatibility.
Lifecycle milestone and scope of change
The PHP supported-versions policy gives each major branch two years of active support followed by one year of security-only fixes. PHP 8.2’s active support ended on 8 December 2024; the remaining security year ends on 8 December 2025. The branch introduced readonly classes, new `true`/`false`/`null` standalone types, fetch property hooks, and `Random\Engine` improvements, which remain available in 8.3 and 8.4 with additional refinements. When the branch closes, upstream CI pipelines, Git maintenance, and release tarballs will stop, and CVE remediation will focus on newer versions.
The cutoff covers more than the core runtime. Extensions maintained in the php-src tree (curl, openssl, intl, mbstring) and bundled libraries cease to receive backports once the security window ends. Projects that depend on serialized object formats, the JIT compiler introduced in PHP 8.0, or the improvements to `openssl_pkey_new` defaults in 8.2 must ensure their production hosts receive updates to the newer branches so cryptographic defaults, header parsing, and memory safety fixes continue to land.
Consequences for frameworks, distributions, and compliance
Frameworks that set PHP 8.2 as a minimum—Laravel 10, Symfony 7, and MediaWiki 1.41—are already testing against PHP 8.3 and 8.4 nightlies. Once security support for 8.2 ends, new framework security advisories will typically ship code that requires newer runtimes, leaving long-running applications stranded if they remain on 8.2. Composer ecosystem trends reinforce this: package authors steadily remove constraints and testing for older branches to reduce CI cost and exploit features such as readonly classes and the new `Random\Engine` APIs.
Operating system distribution policies align with upstream milestones. Debian 12 packages PHP 8.2 today, but backports will taper as maintainers prepare for the branch closure and transition to PHP 8.3. Alpine Linux 3.20 and Ubuntu releases that imported PHP 8.2 will shift to newer branches for default repositories; security fixes for 8.2 after December 2025 would only be available through vendor extended-support contracts, if at all. Cloud images and container base images maintained by community members will likewise pivot to 8.3 and 8.4, shrinking the pool of well-maintained 8.2 artifacts.
Compliance implications mirror those for PHP 8.1. Standards such as PCI DSS require vendors to run software versions that receive vendor security patches. After the upstream end-of-support date, auditors will treat PHP 8.2 as unsupported, so teams would need compensating controls, vulnerability scanning exceptions, and documented timelines to satisfy assessments. Maintaining those exceptions is costlier than completing an orderly upgrade.
Upgrade strategy to PHP 8.3 or 8.4
Successful transitions to PHP 8.3 and 8.4 start with test coverage. Enable verbose deprecation notices in staging to capture usage of features that were deprecated in 8.2 and removed or modified in later branches, such as the old `utf8_encode` functions, dynamic properties on standard classes, or changes to implicit float-to-int conversions. Update build tools like PHPStan and Psalm to versions that recognize the newer language constructs and re-run static analysis to locate type mismatches introduced by stricter typing in 8.3.
Framework and library upgrades should be sequenced with runtime upgrades. Align Laravel applications with the latest 10.x LTS patches that advertise PHP 8.3 support, and move Symfony components to the latest 6.4 or 7.0 patches tested against newer runtimes. For CMS platforms, upgrade WordPress to versions that provide official PHP 8.3 testing matrices and ensure plugin vendors support the newer branch. When using the JIT compiler, revisit configuration values such as `opcache.jit_buffer_size` because PHP 8.3 and 8.4 adjust JIT heuristics; validate performance in representative workloads rather than assuming parity with 8.2.
Production cutovers should be phased. For containerised environments, rebuild images using official `php:8.3-fpm` or `php:8.4-fpm` bases and mirror extension selections with pinned versions. For VM-based deployments, ensure package repositories pull from supported streams, migrate configuration management templates, and rotate any pinned hashes or GPG keys to match new package sources. Maintain rollback plans for the early stages of the migration but remove them promptly to avoid regressions that reintroduce 8.2 after the security cutoff.
Governance, monitoring, and stakeholder communication
Update risk registers and asset inventories to flag PHP 8.2 decommissioning tasks, assigning owners for application teams, platform teams, and third-party supplier managers. Capture supplier attestations for SaaS platforms that embed PHP to ensure their upgrade plans align with the December 2025 deadline. Communicate the migration timeline to audit and compliance teams so annual assessments can document the retirement of 8.2 rather than granting open-ended exceptions.
Strengthen monitoring as the migration progresses. Track runtime versions across fleets through configuration management discovery, gather performance metrics during canary deployments on 8.3 or 8.4, and monitor error budgets for regressions. Use web application firewalls and runtime application self-protection rules as temporary safeguards for any services that cannot migrate before December 2025, but set expiry dates on those compensating controls.
PHP 8.2’s end-of-security date is a fixed milestone with clear consequences. Teams that inventory their workloads, test against supported branches, and coordinate cutovers across container and VM estates will avoid exposure to unpatchable vulnerabilities and maintain compliance standing. Delaying the move past 8 December 2025 would create unnecessary security debt at a time when the PHP ecosystem is standardizing on newer runtimes and deprecating legacy assumptions.
Testing evidence and documentation updates
Secure migrations require evidence. Capture test results that prove critical paths—authentication, payment processing, file uploads, queue processing, and reporting—operate correctly on PHP 8.3 or 8.4. Store those artifacts with change requests, incident runbooks, and DR playbooks so auditors and security teams can verify that runtime upgrades were controlled. Update coding standards to reflect PHP 8.3/8.4 idioms, including enums, readonly classes, and updated randomization APIs, and educate developers on revised linting or static analysis baselines.
Documentation should also track operational nuances. If opcache or JIT parameters changed to stabilize workloads on the newer runtime, note those in runbooks alongside performance benchmarks so teams can detect regressions quickly. Where platforms expose runtime selection to tenants—common in platform-as-a-service offerings—ensure default templates move to PHP 8.3 or 8.4 and deprecate self-service provisioning of PHP 8.2 ahead of the December 2025 deadline.
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.2 · Runtime lifecycle · Security maintenance · Framework compatibility · Upgrade planning
- Sources cited
- 3 sources (php.net, iso.org)
- Reading time
- 6 min
Source material
- PHP Supported Versions — php.net
- PHP 8.2.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.