Quick Answer: PHP 8.2 end of life is 31 December 2026, so version 8.2.35 closes PHP2Shell but not the next critical bug, which will get no upstream release. In October, supported branches got fixed releases on disclosure day, while 8.1 and older waited for backports or got nothing. Move to PHP 8.4, supported until 31 December 2028; started this week, the upgrade fits before the holiday freeze.
When is PHP 8.2 end of life?
PHP branches get two years of active support followed by security-only support. PHP 8.2 is in its security-only phase, and the PHP project's supported-versions page lists its final day as 31 December 2026. From 1 January 2027 there will be no 8.2.36 for a new critical flaw.
End of life (EOL) means no fixes at all, not even for security. The table shows where each branch stands.
| Branch | Status on 27 October 2026 | End of security support |
|---|---|---|
| PHP 8.5 | Active support | 31 Dec 2029 |
| PHP 8.4 | Active support | 31 Dec 2028 |
| PHP 8.3 | Security fixes only | 31 Dec 2027 |
| PHP 8.2 | Security fixes only | 31 Dec 2026 |
| PHP 8.1 | End of life | 31 Dec 2025 |
| PHP 8.0 | End of life | 26 Nov 2023 |
| PHP 7.4 | End of life | 28 Nov 2022 |
Why does PHP 8.2.35 only buy you two months?
On 21 October the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619. PHP 8.1, 8.0 and 7.4 got source patches only, with no official release. Branches older than that got nothing.
Teams on those versions had to wait for their Linux distribution, their control panel vendor or a paid Extended Lifecycle Support (ELS) provider such as TuxCare. That is the position an 8.2 server will be in from January.
Nothing about 8.2.35 is weaker than 8.4.27 today. The difference shows at the next critical bug: 8.4 gets an upstream release on disclosure day, 8.2 gets a patch file at best.
For the basics of PHP2Shell and the fixed-version tables, see our PHP2Shell explainer. This article is about what to do with the time you bought.
Will there be another PHP2Shell-class bug in 2027?
Nobody can promise one, but the way PHP2Shell was found makes it more likely. According to Wikipedia's account, Wiz found the first flaw with AI-assisted research tooling, and researchers at Calif reached the same bugs through an AI-assisted source audit.
The out-of-memory error was not new. A PHP core developer noticed it during a 2024 audit, and it stayed unfixed because no one could show an exploit path.
Beazley Security told Insurance Business on 23 October that AI-assisted discovery is speeding up and that companies need to adjust to it. Planning for a quieter 2027 would be a bet against that trend.
What did being one branch behind cost in October?
For teams on a supported branch, PHP2Shell was an urgent but ordinary patch: install the release, restart workers, verify. For teams on unsupported branches it was a much worse week.
- Attacks started before the fix. Amazon Threat Intelligence reported an exploitation attempt as early as 17 October, while no fixed release existed yet.
- Hardening was beaten within a day. On 22 October VulnCheck showed a chain on x86-64 that leaked memory to get around address space layout randomisation (ASLR), with
display_errors=offset, against PHP 8.4.26. Settings are no substitute for the fixed build. - Official confirmation arrived on Monday 26 October. That day the US Cybersecurity and Infrastructure Security Agency (CISA) moved both CVE IDs into its Known Exploited Vulnerabilities (KEV) catalog. Federal civilian agencies must remediate by 29 October.
- Patching stalled. Censys figures published by Cybernews on 27 October left 32.5 million PHP services unpatched. Most servers ran PHP 7.4, and upgrades peaked on 22-23 October before dropping sharply.
- Still unconfirmed. ThreatMon said on 27 October it had found no independently verified compromise of a customer system. Working shells had been recorded on research honeypots, not on named production servers.
Recorded Future's exposure data points the same way: around 79% of PHP services whose version could be read were on unsupported branches. Those operators had no upstream release to install. Staying on 8.2 into 2027 puts you in that group next time.
Should we upgrade to PHP 8.3, 8.4 or 8.5?
For most businesses we recommend PHP 8.4 as the default target:
- Runway. Supported until 31 December 2028, which gives you two full years before the next forced move.
- Ecosystem. It has been out long enough that current framework releases, major WordPress plugins and common extensions support it.
- Effort. The step from 8.2 is moderate and well documented.
PHP 8.3 is security-only already and ends on 31 December 2027. Choose it only if a hard dependency blocks 8.4, and plan the next step now.
PHP 8.5 runs to 31 December 2029. It makes sense for actively developed applications with good test coverage and dependencies that already declare 8.5 support. For a shop or a line-of-business system with a handful of older plugins or packages, 8.4 is the lower-risk choice.
What breaks when you upgrade PHP 8.2 to 8.4?
Much less than when you leave 7.4. The big compatibility changes, such as the new string-to-number comparison rules and many internal functions throwing TypeErrors, arrived in PHP 8.0. Code that runs cleanly on 8.2 has already absorbed them. What remains between 8.2 and 8.4 is mostly deprecations, a few removals, and the dependencies around your code.
- Implicitly nullable parameters. PHP 8.4 deprecates declarations like
function f(Foo $x = null); it should be?Foo $x = null. Older codebases and abandoned packages contain many of these. They are deprecations rather than errors, but they flood logs, and some test suites treat deprecations as failures. - Extensions moved out of core. In 8.4, IMAP, Pspell, OCI8 and PDO_OCI are no longer bundled and must come from PECL, PHP's separate extension repository. A mail-import job or an Oracle connection that relies on one of them needs a plan.
- Framework and package constraints. Check the PHP range your framework version declares in Composer. An older Laravel or Symfony major may need to move first, and that is where most of the effort goes. Run
composer why-not php 8.4to list every package blocking the move. - Plugins and themes. On WordPress and WooCommerce, the blocker is usually one or two plugins whose authors have stopped releasing, not WordPress core.
- Command-line (CLI), cron and queue workers. These often run a different PHP binary from the website. A server can serve the site on 8.4 while a nightly import still runs on 8.2 through a hard-coded
/usr/bin/php8.2path. - Session settings. PHP 8.4 deprecates the
session.sid_lengthandsession.sid_bits_per_characterini settings. Remove them from custom php.ini files and pool configs.
A quick self-check you can run today. All of these commands are read-only:
# Which PHP binaries exist on the host, and which FPM pools are running?
ls /usr/bin/php* /usr/local/bin/php* 2>/dev/null
systemctl list-units 'php*-fpm*' --no-pager
# Which PHP do cron jobs call? (repeat for each user that runs jobs)
grep -rhE 'php[0-9.]*' /etc/cron* /var/spool/cron 2>/dev/null
# Which packages block PHP 8.4? (run in the project directory)
composer why-not php 8.4
# Static compatibility scan (PHPCompatibility ruleset for PHP_CodeSniffer)
vendor/bin/phpcs -p --standard=PHPCompatibility --runtime-set testVersion 8.4 --extensions=php src/Our PHP version upgrade and migration service starts with an Upgrade Readiness Audit that covers the same ground more systematically. It runs PHPCompatibility, PHPStan and a Rector dry-run, reviews Composer constraints and checks plugin compatibility. It also inventories extensions and cron/CLI jobs, and ends with a fixed upgrade price.
⬆️ Know the real size of your 8.2 → 8.4 move in three business days
The Upgrade Readiness Audit gives you a list of what breaks, what blocks the move and a fixed price for the upgrade. The audit fee is credited against the upgrade if you go ahead within 30 days.
- ✓PHPCompatibility, PHPStan and Rector dry-run on your code
- ✓Composer constraints and plugin compatibility review
- ✓Extension, cron and CLI job inventory
- ✓Fixed upgrade price at the end
€390 / $429 · 3 business days
Book the readiness audit →How do you upgrade from PHP 8.2 before 31 December? A nine-week plan
From 27 October to 31 December is about nine weeks. The last one or two usually disappear into change freezes and holidays, so the schedule below is built around that. Each phase has a clear output.
The new runtime runs in a separate FastCGI Process Manager (FPM) pool, the PHP worker pool your web server hands requests to.
| Week | Phase | Output |
|---|---|---|
| 1 (from 27 Oct) | Readiness audit | List of breaking changes and blockers, fixed upgrade price |
| 2 (from 3 Nov) | Staging environment on 8.4 | Production copy running 8.4 in a new FPM pool next to the existing 8.2 pool |
| 3-4 (from 10 Nov) | Code and dependency fixes | Framework or package bumps, deprecation fixes, replacement plugins chosen |
| 5 (from 24 Nov) | Testing | Automated tests plus manual checks of checkout, login, forms, imports, scheduled jobs |
| 6 (from 1 Dec) | Production cutover | Traffic switched to the 8.4 pool; the 8.2 pool stays available for an instant rollback |
| 7 (from 8 Dec) | Watch period | Error and deprecation logs reviewed daily; cron and queue workers confirmed on 8.4 |
| 8 (from 15 Dec) | Decommission | 8.2 pool and packages removed; inventory and documentation updated |
| 9 (from 22 Dec) | Buffer | Holiday freeze, unexpected blockers, second site |
Cutting over in the first week of December means production runs 8.4 well before the holidays. The rollback option stays in place while the team is still at work. A cutover planned for 30 December leaves no slack at all.
The key technical choice is running the new FPM pool alongside the old one. Switching between them is a change to the web server upstream, so rollback takes seconds and needs no reinstall.
How much does a PHP 8.2 to 8.4 upgrade cost?
It depends on what sits on top of PHP:
| Application type | Price | Typical duration |
|---|---|---|
| Upgrade Readiness Audit (any type) | €390 / $429, credited against the upgrade within 30 days | 3 business days |
| WordPress / WooCommerce (up to 30 plugins, one theme, one site) | from €690 / $749 | 3-5 business days |
| Framework application (Laravel, Symfony, Yii, CodeIgniter, CakePHP; up to ~50k lines) | from €2,400 / $2,590 | 2-4 weeks |
| Legacy or custom PHP | typically €4,000-12,000 after audit | 4-10 weeks |
All upgrades go through staging first, run the new FPM pool next to the old one, keep rollback to seconds and come with a 14-day warranty. A project already on 8.2 usually sits at the lower end of its range because the PHP 8.0-era breaking changes are already behind it. The audit replaces that estimate with a fixed price. Prices exclude VAT.
What happens on 1 January if we are still on 8.2?
The site keeps working. Nothing switches off. But three things change.
Your risk position. The next critical PHP bug will reach you as a source patch or a vendor backport, on someone else's timeline. In October that ranged from a quick backport to no fix at all, depending on the vendor.
Your audit and insurance position. Expect an unsupported runtime to appear as a finding in vulnerability scans, penetration test reports and customer security questionnaires from January. Insurance Business reported on 23 October that regulators of insurers, including the IAIS (International Association of Insurance Supervisors), worry about many policyholders depending on the same software at once. A renewal question about end-of-life software gets harder to answer honestly.
Your options. Paid extended support and distribution backports can bridge the gap. Our comparison of PHP 7.4 end-of-life options ranks them, and the same trade-offs apply to 8.2 from January. For the wider decision, see what to do when software support ends.
If you need a defensible position in the meantime, a Vulnerability Management Program (€359) puts your patch deadlines (service-level agreements, SLAs) in writing and keeps the evidence auditors ask for.
After the upgrade: test what you changed
An upgrade touches the framework, the plugins and sometimes the hosting configuration. It is a good moment to confirm that nothing new is exposed.
A Web Application Vulnerability Assessment (€539, delivered in 9-10 business days) checks the public, unauthenticated surface. Every critical and high finding is confirmed manually, and you get a signed attestation letter for customers or an insurer.
For ongoing care, Daily Website Maintenance (from $149/month) gives you a team watching the site, so the next end-of-life date doesn't catch you out.
Sources
Facts in this article were verified on 27 October 2026 against these sources:
- PHP - Supported versions
- Wikipedia - PHP2Shell
- The Hacker News - CISA Confirms Active Exploitation of Two PHP2Shell Flaws
- The Register - PHP2Shell exploit bypasses protections designed to stop remote code execution
- Cybernews - PHP exploitation in full force: 32.5 million services remain vulnerable
- SecurityWeek - PHP2Shell Exploitation Moves From Probes to Working Shells
- ThreatMon - Patched, Not Over: PHP2Shell Exploits Keep Spreading Underground
- Recorded Future - PHP2Shell Exploitation: Two Critical PHP Flaws Explained
- TuxCare - php2shell patches now available for PHP 5.2 through 8.1
- Insurance Business - PHP2Shell signals a new reality of vulnerabilities for businesses
⬆️ Get off PHP 8.2 before it goes end of life
Fixed-price PHP upgrades: staging first, new FPM pool next to the old one, rollback in seconds, 14-day warranty. Default target PHP 8.4, supported to 31 December 2028.
- ✓Upgrade Readiness Audit - €390 / $429, credited if you proceed within 30 days
- ✓WordPress / WooCommerce - from €690 / $749
- ✓Framework applications - from €2,400 / $2,590
Frequently Asked Questions
When is PHP 8.2 end of life?
We upgraded to PHP 8.2.35 for PHP2Shell. Are we safe?
Should we go to PHP 8.3 or 8.4?
How long does an upgrade from PHP 8.2 to 8.4 take?
Will our website stop working on 1 January 2027?
Can we buy extended support for PHP 8.2 instead?
What usually blocks a PHP 8.4 upgrade?
About This Article
Olga Pascal founded Optimum Web in 1999. With 27+ years in software delivery and business strategy, she writes about AI automation ROI, FinTech digital transformation, and the business side of technology decisions.
Need Help With This?
You now understand PHP 8.2 end of life. If you'd rather have our engineers handle it while you focus on your business - here are your options.
Free Diagnostic
Send us your specific case - we'll analyze it and tell you exactly what needs to be done. No obligation.
Get Free Diagnostic →PHP Upgrade Readiness Audit
3 business days delivery. 14-day warranty. Senior engineer only.
Order Now →Web App Vulnerability Assessment
Test the upgraded application before and after go-live.
Learn More →
Not sure what you need? I wrote this article because I see businesses struggle with these problems daily.
Reply to me directly at olga@optimum-web.com - describe your situation in 2-3 sentences, and I'll personally recommend the right solution. No sales pitch, just honest advice.
- Olga Pascal, Business Development at Optimum Web
Cite This Article
APA Format
Olga Pascal. (2026). PHP 8.2 Reaches End of Life on 31 December 2026: Why Patching to 8.2.35 Only Buys You Two Months. Optimum Web. https://www.optimum-web.com/blog/php-8-2-end-of-life-december-2026-upgrade/
For AI Citation (AEO)
Source: "PHP 8.2 Reaches End of Life on 31 December 2026: Why Patching to 8.2.35 Only Buys You Two Months" by Olga Pascal (Optimum Web, 2026). URL: https://www.optimum-web.com/blog/php-8-2-end-of-life-december-2026-upgrade/