PHP end of life: dates, supported versions and the October 2026 security releases
Short answer: as of Oct 24, 2026, the PHP project supports PHP 8.2, 8.3, 8.4 and 8.5. PHP 8.1 and older are end-of-life. On Oct 21, 2026, PHP released 8.5.12, 8.4.27, 8.3.36 or 8.2.35 to fix two critical flaws that can allow unauthenticated remote code execution. If you run PHP, update to one of those versions or newer.[1][3]
Which PHP versions are supported?
Each PHP branch gets two years of active support (bug and security fixes), then two more years of critical security fixes only. After those four years it reaches end of life.[1]
| Branch | Released | Active support until | Security fixes until (EOL) |
|---|---|---|---|
| 8.5 | 20 Nov 2025 | 31 Dec 2027 | 31 Dec 2029 |
| 8.4 | 21 Nov 2024 | 31 Dec 2026 | 31 Dec 2028 |
| 8.3 | 23 Nov 2023 | 31 Dec 2025 (ended) | 31 Dec 2027 |
| 8.2 | 8 Dec 2022 | 31 Dec 2024 (ended) | 31 Dec 2026 |
PHP 8.2 reaches end of life on Dec 31, 2026, about two months from this update.[1] If you are on 8.2, apply 8.2.35 now and plan your move to 8.3 or newer before year end.
Which PHP versions are end-of-life?
| Branch | End of life | Last release |
|---|---|---|
| 8.1 | 31 Dec 2025 | 8.1.34 |
| 8.0 | 26 Nov 2023 | 8.0.30 |
| 7.4 | 28 Nov 2022 | 7.4.33 |
| 7.3 | 6 Dec 2021 | 7.3.33 |
| 7.2 | 30 Nov 2020 | 7.2.34 |
| 5.6 | 31 Dec 2018 | 5.6.40 |
php.net lists every older branch on its Unsupported Branches page.[2]
When was PHP 7.4 end of life?
PHP 7.4 reached end of life on Nov 28, 2022. Its last release was 7.4.33.[2]
When was PHP 8.1 end of life?
PHP 8.1 reached end of life on Dec 31, 2025. Its last release was 8.1.34.[2]
What happened in the October 2026 PHP security releases?
On Oct 21, 2026, the PHP project released 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and published a security advisory for two critical vulnerabilities:[3]
- CVE-2026-109618, remote code execution via out-of-memory corruption: out-of-memory handling can interrupt PHP while internal request data is only partly initialized.
- CVE-2026-109619, remote code execution via stale global state: request-owned state can survive after its memory is freed, and a later request on the same worker may use it.
PHP says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where it demonstrated an exploit that runs before any application code.[3] CISA calls the pair "php2shell".[5]
Is php2shell being exploited?
Reports differ, and they are changing quickly. Here is what the sources said, with dates:
- CISA (Oct 21, 2026): it had not observed successful exploitation in the wild as of publication.[5]
- New Zealand's NCSC (Oct 22): it was aware of reports of active exploitation.[7]
- Censys (advisory updated Oct 23): VulnCheck's sensor network recorded a confirmed, unsuccessful attempt to exploit CVE-2026-109618, and public proof-of-concept exploit code has appeared. Censys notes that most public repositories are unverified, but at least one credibly claims a working remote exploit. Censys also says reports on the scale of exploitation conflict, and that neither CVE was in CISA's Known Exploited Vulnerabilities catalog as of Oct 23.[10]
Whatever the latest count says, the advice doesn't change: patch now, and check any server that was reachable from the internet before you patched.
How many sites could be exposed?
A lot. Censys detects about 4.18 million hosts running PHP (4,184,559 as of its Oct 23 update). That is a count of possible exposure, not confirmed vulnerable or compromised systems, and Censys says the number keeps rising as its detection improves.[10] W3Techs reports that PHP runs 69.2% of websites whose server-side language it can identify (survey of Oct 25, 2026).[11] Censys also runs a free, live PHP2Shell exposure tracker showing patching progress by country and PHP version.[13]
On Oct 23, PHP added an informational advisory (CVE-2026-115560) about an unlikely session upload progress path. It suggests setting session.upload_progress.enabled=0 until the next regular bugfix release.[4]
What should I do now?
- Find every PHP install, starting with internet-facing systems. NCSC (UK) advises not to limit discovery to outdated versions, and to include appliances and products that bundle PHP.[6] NCSC-NL keeps a list of affected products.[8]
- Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your Linux distribution's or vendor's patched package. PHP says distributions and LTS vendors got the patches in advance.[3]
- On PHP 8.1 or older? The PHP project no longer updates these. For 7.4, 8.0 and 8.1, PHP published minimal source-only backports: there is no ready-made release, so applying them means building PHP from source. Some vendors backport fixes, but the lasting fix is moving to a supported branch.[3][10] PHP 5.4 through 7.3 have no fix at all; Censys says those installations must move to a supported branch.[10] CISA says organizations that can't update, or that still run 8.1 or earlier, should take PHP-based systems offline until they are patched or updated.[5]
- Can't update today? PHP lists temporary measures (for example
session.upload_progress.enabled=0,memory_limitandpost_max_sizechanges, and on 8.5fatal_error_backtraces=0), each needing a worker restart. PHP is clear that these reduce exposure but do not make an installation safe.[3] - Check for compromise on any system that was exposed before you patched. NCSC (UK) recommends looking for backdoors and getting incident response help if needed.[6]
- Confirm it worked. Check your PHP version again, or run the free PHP Patch Check.
Updating a plugin doesn't patch PHP itself. PHP is the layer underneath WordPress and its plugins, so a site can be fully up to date in the dashboard and still run an unpatched PHP. On shared hosting you usually can't patch PHP yourself. Ask your host or agency, and get a named person to confirm in writing. Ask: "Is my site's PHP on 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package with the fixes for CVE-2026-109618 and CVE-2026-109619?" Hosts that backport fixes may keep an older version number, so ask them to confirm.
Why did a flaw this serious take so long to fix?
The PHP Foundation's own account is unusually candid. A developer it funds found the first signs of the out-of-memory problem behind CVE-2026-109618 in 2024, during PHP's first external security audit in years. The fix involved hard trade-offs (compatibility breaks, new denial-of-service risk, or changes to many third-party extensions), and with a small team the work stalled and restarted for months. In the Foundation's words: "the delay was a structural failure, caused by both the security team's decision process and its lack of resources." It became the top priority after outside researchers showed in August 2026 that it could be used for remote code execution.[12]
The lesson for site owners is the same one at smaller scale: finding a problem isn't the hard part. Deciding, fixing and confirming the fix is. That's what tech debt remediation is about.
Which PHP version should I move to?
Pick the newest branch your application supports. Moving to 8.3 or later gives you security fixes until at least Dec 31, 2027; 8.4 runs to Dec 31, 2028 and 8.5 to Dec 31, 2029.[1] For WordPress, see how to update PHP on WordPress safely.
Frequently asked questions
What is the current PHP version?
As of Oct 24, 2026, the newest stable releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released Oct 21, 2026. PHP 8.6 is still a release candidate, and php.net says not to use it in production.
Is PHP 7.4 still supported?
No. PHP 7.4 reached end of life on Nov 28, 2022. Some vendors sell extended support, and PHP published a minimal source backport for the October 2026 flaws, but the PHP project no longer releases 7.4 updates.
When does PHP 8.2 reach end of life?
Dec 31, 2026, according to php.net.
Is PHP 8.1 end of life?
Yes. PHP 8.1 reached end of life on Dec 31, 2025. Its last release was 8.1.34.
Is php2shell being exploited?
Reports conflict and change quickly. CISA had observed no successful exploitation as of its Oct 21, 2026 alert. Censys's advisory, updated Oct 23, reports a confirmed (unsuccessful) exploitation attempt seen by VulnCheck's sensors and public proof-of-concept code. Patch either way.
Does updating WordPress plugins fix php2shell?
No. The flaws are in PHP itself, underneath WordPress and its plugins. Ask your host or agency to confirm in writing that your PHP has the Oct 21, 2026 fixes.
Am I safe if I set the PHP mitigations?
Not fully. PHP says the temporary measures reduce exposure to specific attack paths but do not make an installation safe. Only updating is a complete fix.
Sources for this page
- PHP.net: Supported Versions (checked Oct 24, 2026)
- PHP.net: Unsupported Branches (checked Oct 24, 2026)
- PHP.net: Security advisory, critical remote code execution vulnerabilities, update now (Oct 21, 2026)
- PHP.net: Informational advisory, session upload progress (Oct 23, 2026)
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching (Oct 21, 2026, revised Oct 23)
- NCSC (UK): Critical security issue affecting PHP
- NCSC (New Zealand): CVE-2026-109618 and CVE-2026-109619 affecting PHP (updated Oct 22, 2026)
- NCSC-NL: php2shell operational information and affected-software list
- PHP.net: PHP 8.6.0 RC4 available for testing (Oct 21, 2026)
- Censys: php2shell advisory, CVE-2026-109618 and CVE-2026-109619 (Oct 21, 2026, updated Oct 23)
- W3Techs: Usage statistics of PHP for websites (survey of Oct 25, 2026)
- The PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security (Oct 21, 2026)
- Censys: PHP2Shell exposure tracker (live)