PHP 8.2 and PHP2Shell: Patch to 8.2.35, Then Plan Your Move

As of 23 October 2026, sites on PHP 8.2 have two jobs. The first is urgent: update to PHP 8.2.35, released on 21 October 2026, or your vendor's patched 8.2 package, because every 8.2 release up to 8.2.34 is affected by PHP2Shell. The second has a deadline: PHP 8.2 reaches end of life on 31 December 2026, about ten weeks from now.

PHP's own 8.2.35 announcement says the branch "will receive no further security fixes after that date." If another flaw like PHP2Shell appears in 2027, the PHP project will not release a fix for 8.2. You would depend on your Linux vendor, your host or a paid support vendor, or you would have nothing.

This page is half patch, half plan. The first part lists the fixed 8.2 packages and how to confirm them. The second helps you pick an upgrade target, check what your CMS allows, and move without breaking the site.

PHP 8.2 Status and Deadlines

Dates are from PHP's supported versions page.

Part One: Patch PHP 8.2 Today

Debian 12 (bookworm)

PHP 8.2 is Debian 12's default. The Debian security tracker lists bookworm's point-release package, 8.2.32-1~deb12u1, as vulnerable and the security package, 8.2.35-1~deb12u1 (DLA-4848-1), as fixed. Your server must pull from Debian's security archive to get it. An example (use apache2 instead if you run mod_php):

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.2-fpm

Fixed 8.2 Packages on Other Linux Distributions

RHEL 8, RHEL 9 and their rebuilds

AlmaLinux's fixed builds keep the 8.2.33 number, so compare full package versions, not the PHP version.

Alpine and Amazon Linux

• Alpine: php82 is fixed as 8.2.35-r0 in the community repository on 3.21 and 3.22. Alpine's security database lists no php82 package for 3.23 or 3.24.
• Amazon Linux 2023: php8.2 is fixed in ALAS2023-2026-3301 (php8.2-cli-8.2.35-1.amzn2023.0.1).
• Amazon Linux 2: the php8.2 Extras package is fixed in ALAS2PHP8.2-2026-015 (php-cli-8.2.35-1.amzn2.0.1).

Docker and Managed Runtimes on PHP 8.2

The official php:8.2 and php:8.2-apache tags were rebuilt with 8.2.35 on 21 October. Pull, rebuild and redeploy, because running containers do not change on their own. Some cloud platforms patched 8.2 for you. For the App Engine standard environment on PHP 8.2 and newer, Google says: "Applications are updated automatically." AWS Elastic Beanstalk's current PHP platform includes 8.2.35. Azure App Service on Linux rolled out 8.2.35 to its built-in images.

Confirming the 8.2 Fix

8.2.35 is the oldest release that has the new memory_hard_limit_percent directive. PHP's manual says that if it "is not recognized, the PHP version in use is affected." To test the PHP that actually serves your site, create a temporary phpinfo() page, search it for memory_hard_limit_percent, then delete the page straight away, because it exposes server details. Our guide on checking your PHP version walks through this safely.

The test is contested, and it is only reliable for builds of PHP's own 8.2.35 release. A backported build such as AlmaLinux's 8.2.33 may not include the directive, even though it is fixed. On those, check the package version against the tables above.

Part Two: What End of Life Means for Your Site

After 31 December 2026, the PHP project stops publishing fixes for 8.2. The site will keep working. It just will not get engine fixes from upstream. Our PHP 8.1 page shows what that looks like during an emergency: no official release, only source backports and vendor packages.

Some vendors support 8.2 longer. Red Hat's application streams life cycle lists the php:8.2 streams on RHEL 9 and RHEL 8 as supported until May 2029. If you run RHEL, AlmaLinux or Rocky, you can stay on 8.2 under that vendor support. Your fixes will come from your OS vendor, and your CMS and plugins must still support 8.2. On Debian 12, check Debian's own security support plans for bookworm rather than assuming.

Choosing Your Next PHP Branch

For most business sites, 8.4 is the practical target. It buys two years of upstream security fixes, versus one for 8.3. If an important plugin is not ready for 8.4, 8.3 is a reasonable step.

What your platform allows

• WordPress: the hosting handbook lists PHP 8.2 to 8.5 for WordPress 7.0 and 7.1, so core is not the blocker. Old plugins usually are. See our WordPress PHP versions guide.
• Drupal: Drupal 11 does not support 8.2 at all. Drupal 10.4 to 10.6 support 8.1 through 8.4, so a Drupal 10 site can move to 8.3 or 8.4 without a major Drupal upgrade.
• Joomla: Joomla 4 recommends 8.2, and Joomla 5 recommends 8.3. Joomla 6 needs at least 8.3.0.
• Magento and Adobe Commerce: 2.4.6 supports only 8.2 and 8.1, so leaving 8.2 means upgrading Magento to 2.4.7 (8.3 and 8.2) or 2.4.8 (8.4 and 8.3) first.
• Laravel: Laravel 11 and 12 run on 8.2 and newer. Laravel 13 needs 8.3.

Your operating system's path

On Debian 12, the default PHP is 8.2, and Debian ships no 8.3 package. The distribution route to newer PHP is Debian 13, whose default is 8.4. On Ubuntu, 24.04 LTS ships 8.3. On RHEL 9 and its rebuilds, the php:8.3 stream is available and fixed. On Alpine, the security data shows php82 only on 3.21 and 3.22, so plan the PHP change and any Alpine upgrade together.

Code Changes From 8.2 to 8.3

PHP's 8.3 incompatible changes and 8.3 deprecations include:

• Date and time errors now throw DateError and DateException types instead of warnings and generic exceptions.
• Using ++ on empty or non-numeric strings is deprecated.
• Calling get_class() or get_parent_class() without arguments is deprecated.
• assert_options() is deprecated.
• Code that came close to the stack limit may now throw an Error.
• Assigning a negative index to an empty array changes the next index the array uses.

Going on to 8.4 adds more, including the removal of the IMAP extension from core. Our PHP 8.4 page lists those changes, and our PHP 8.3 page covers 8.3's packages.

A Step-by-Step Upgrade Plan

1. Confirm every site is on 8.2.35 or a vendor-fixed 8.2 build first.
2. List what runs on PHP: each site, its CMS version, plugins, custom code and scheduled jobs. Note the PHP version for both the web server and the command line.
3. Take a full backup and check that it restores. Our backup and recovery guide explains how.
4. Make a staging copy and switch only the copy to the target PHP version.
5. Test the flows that make you money: forms, checkout, logins, bookings, imports.
6. Turn on error logging on staging and fix the deprecation warnings it shows. Update or replace plugins that fail.
7. Switch production in a quiet period. Restart PHP and confirm the new version is the one serving pages.
8. Keep a rollback path to 8.2.35, never to an older 8.2 release, until the new version has run cleanly for a while.

For older or more complex sites, our guide to upgrading old PHP sites safely goes deeper.

Conclusion

On PHP 8.2, patch first and plan second. Install 8.2.35 or your vendor's fixed package, restart PHP and confirm the build today. Then choose 8.3 or 8.4, test on a copy, and switch before 31 December 2026, unless you rely on vendor support such as Red Hat's. If you want help with either job, our emergency PHP patching service handles the patch, and we can plan the upgrade with you. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions