PHP Upgrade 2026: What Just Happened, Why It Matters, and How to Upgrade Safely

Home › News › PHP Upgrade 2026: What Just Happened, Why It Matters, and How to Upgrade Safely

By the DESSS Team | Updated November 2026

If you manage a website or web application built on PHP, October 2026 was probably a stressful month. In the space of three days, the PHP project shipped emergency security fixes, researchers published working exploits, and a second remote code execution bug was announced. If you haven't checked your servers yet, this article is your nudge.

We've spent the last few weeks helping clients patch, test and upgrade PHP across Windows and Linux servers. Below, we've pulled together what we've learned: what went wrong, which versions are safe, and a practical plan you can follow (or hand to us).

The short version

• Two critical PHP flaws (nicknamed PHP2Shell) let attackers run code on your server without logging in. They affect PHP 5.4 through 8.5.11.
• Fixes are out for PHP 8.2, 8.3, 8.4 and 8.5. There is no official fix for PHP 8.1 or older.
• PHP 8.2 stops receiving security updates on December 31, 2026. That's weeks away.
• PHP 8.6 arrives November 19, 2026, with stricter session defaults that can quietly break logins and checkouts.

What actually happened in October

PHP2Shell: CVE-2026-109618 and CVE-2026-109619

Both bugs are rated critical, with a CVSS v4.0 score of 9.2. In plain terms, someone can send a specially crafted web request to your site and take control of the server behind it.

• CVE-2026-109618 comes from how PHP cleans up after running out of memory. Cleanup can treat half-built data as valid, and that opens the door.
• CVE-2026-109619 comes from leftover data. One request can leave state behind that the next request on the same worker then trusts.

The PHP team released fixed versions on October 21, 2026: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Exploit code was public within days, so this isn't a theoretical risk.

Old versions are now a real liability

PHP2Shell shows exactly what "end of life" means. A fix exists, but if you're on PHP 8.1, 8.0 or 7.x, it isn't for you. Old PHP also blocks updates to WordPress plugins, Laravel, Drupal and Magento, and it tends to fail compliance checks like PCI DSS.

New releases change old behavior

Upgrading isn't just a version bump. A few changes that regularly trip people up:

• PHP 8.5 always builds OPcache in.
• PHP 8.6 turns on stricter session cookies by default.
• PHP 8.6 also deprecates some functions. Nothing breaks yet, but your logs will fill up.

Which PHP version should you be running?

For most production sites today, we recommend PHP 8.4. Choose 8.5 if your plugins and packages already support it.

Each PHP release gets two years of bug fixes, then two years of security-only fixes. You can always confirm current dates on php.net.

How this plays out on Windows vs. Linux

The vulnerability is the same everywhere, but the upgrade experience is very different.

On Linux, a package manager does most of the work. The catch is that updating packages doesn't restart running PHP-FPM workers, so a server can look patched while still running the old code. Distribution versions also lag behind, and each PHP version needs its own set of extensions.

On Windows, upgrading is hands-on. You download a new build, pick the right type (Non-Thread Safe for IIS, Thread Safe for Apache), install the right Visual C++ runtime, update IIS paths and recycle the app pool. Miss one step and the site returns a 500 error.

We've written a dedicated guide for each platform, plus one on how upgrades affect database connections:

• PHP Upgrade on Windows Server: IIS and Apache Impact, Fixes and Best Practices
• PHP Upgrade on Linux Server: Impact, Fixes and Best Practices
• How PHP Upgrades Affect Direct Database Connectivity

A safe upgrade plan, step by step

Think of this as two jobs. Patching within your current branch (for example, 8.3.x to 8.3.36) is urgent and low risk. Moving to a new branch (8.1 to 8.4) is a small project that deserves proper testing.

1. Patch first. Get every supported server to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, and restart PHP.
2. Apply the interim fix. Turn off session upload progress until the CVE-2026-115560 patch is installed.
3. Take inventory. List every server, container, hosting panel and bundled PHP binary, with its version and extensions.
4. Scan your code. Tools like PHPCompatibility and Rector flag removed functions and deprecated syntax.
5. Check your dependencies. Run composer outdated and composer check-platform-reqs, and update plugins and modules.
6. Build a staging copy. Never test an upgrade on your live site.
7. Test with all errors visible. Walk through login, checkout, forms, uploads and payment callbacks.
8. Review session behavior before moving to PHP 8.6, especially cross-site POST flows.
9. Deploy with a rollback plan. Keep the old version ready and watch logs for 48 hours.
10. Stay current. Subscribe to PHP security announcements and review your versions every year.

How DESSS can help

We've been building and maintaining PHP applications for more than two decades, from WordPress and Joomla sites to Magento stores and custom Laravel platforms. Here's how we can take this off your plate:

• Emergency patching: We apply the PHP2Shell fixes and mitigations, then confirm the new code is running.
• Version audit: A full inventory of your PHP versions, extensions and end-of-life exposure.
• Code compatibility fixes: We find and fix deprecated and removed features before they break your site.
• Platform upgrades on Linux, Windows Server, cPanel, Plesk and Docker through our Upgrades & Migrations team.
• CMS and eCommerce upgrades for WordPress, Joomla and Drupal sites and Magento stores.
• Testing and zero-downtime deployment backed by our Software Testing practice.
• Ongoing care through Application Maintenance and Managed IT Services, so you never fall this far behind again.

Explore our Web Development and Custom Application Development services to see the full range of PHP work we do.

Request a customized PHP upgrade quote

No two environments are the same, so we don't do one-size-fits-all pricing. Tell us a little about your setup and we'll come back with a clear plan and a quote built around it:

• Your current PHP version(s) and where you'd like to be
• Your server setup (Windows with IIS or Apache, or Linux with Nginx or Apache)
• Your framework or CMS
• How many sites, servers or containers you run
• Your timeline and any compliance requirements (PCI, HIPAA)

Request your customized quote

Talk to a DESSS PHP specialist. With PHP 8.2 reaching end of life on December 31, now is the right time to plan.

Frequently asked questions

Is my site vulnerable to PHP2Shell?

If it runs PHP 5.4 through 8.5.11 and hasn't been updated since October 21, 2026, yes. Check your version and make sure PHP was restarted after updating.

Can I patch PHP 8.1 instead of upgrading?

There's no official fix for 8.1. Unofficial patches exist, but they're stopgaps. The real fix is moving to 8.2 or newer, ideally 8.4.

Should I jump straight to PHP 8.6?

Not on release day. Test it on staging now and move production once your plugins and packages support it.

How long does an upgrade take?

A security patch can take a few hours. A major version jump on a custom application can take days to weeks, depending on the code and how well it's tested.

Is upgrading harder on Windows?

It's more manual, because you manage builds, runtimes and IIS settings yourself. The code changes are the same on both.

Disclaimer

The information in this article is provided for general informational and educational purposes only. It reflects publicly available information as of November 4, 2026. PHP versions, support dates, security advisories and third-party software change often, so always confirm details with official sources such as php.net and your software vendors before making changes.

This article is not professional, legal or security advice, and following these steps does not guarantee protection against every vulnerability or compatibility issue. Always back up your systems and test upgrades in a staging environment before applying them to production. DESSS, Inc. is not liable for any loss, damage or downtime resulting from the use of this information.

Product names and trademarks mentioned (including PHP, Microsoft, Windows, IIS, SQL Server, Oracle, MySQL, MariaDB, PostgreSQL, Ubuntu, Debian, Red Hat, cPanel and Plesk) belong to their respective owners and are used for identification only. Links to third-party sources do not imply endorsement. Please also see the DESSS Disclaimer and Privacy Policy.