PHP 8.2 end of life: what WordPress, WooCommerce, Magento and Laravel site owners need to do

In short

• PHP 8.2 gets its last security fixes on 31 December 2026. After that the PHP project releases nothing more for 8.2, however serious the flaw.
• The flaws fixed on 21 October 2026 show what that means. Two critical remote-code-execution bugs were fixed in 8.2, 8.3, 8.4 and 8.5. Branches already past end of life got only source-code patches you build yourself.
• Move to PHP 8.4 if your platform version supports it (security fixes until 31 December 2028), or to 8.3 (until 31 December 2027) if it doesn't yet.
• Some platform versions need upgrading first: Magento Open Source and Adobe Commerce 2.4.6 run only on PHP 8.1 and 8.2. Laravel 10 and 11 can run newer PHP, but the framework itself is already out of security support.
• Upgrade both PHPs: the one that serves your website and the one that runs cron jobs, queues and command-line tools. They are often different.
• The safe order: find out what you run, check your code, test on a copy, switch with a backup ready, watch the logs.

Key dates

Sources: php.net supported versions, unsupported branches and the 2026 news archive.

php.net's own definition of end of life: "A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities."

What happened on 21 October 2026

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Both "can allow unauthenticated remote code execution". Some security news sites, such as Help Net Security, call the pair "PHP2Shell"; php.net does not use the name.

What php.net said (2026 news archive):

• Who is at risk: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". It considers the risk highest for mod_php.
• Mitigation: "There are no complete mitigations, updating is the only safe choice." The interim settings it published "reduce exposure to specific attack paths but do not make an installation safe."
• End-of-life branches: "PHP 8.1 and older no longer receive updates from the PHP project." Because of the severity, the security team "provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1" for people who build PHP from source. Ready-made packages for those versions depend on your Linux distribution or a long-term-support vendor.
• A follow-up on 23 October (CVE-2026-115560, session upload progress) suggests setting session.upload_progress.enabled=0 "until the next regular bugfix release".

The UK's National Cyber Security Centre told organisations to update, "prioritising internet-facing systems", and, where they could not apply the temporary mitigations in time, to "consider taking the system offline until it can be fully mitigated". WooCommerce said sites on Automattic's platforms (WordPress.com, WordPress VIP, Pressable and WP Cloud) were already protected, and told everyone else to check with their host and update PHP.

Why it matters for 8.2: 8.2 received a fix (8.2.35) because it was still in security support. A flaw of the same kind found after 31 December 2026 would get no 8.2 release at all.

Check you have the fixed build. Your PHP should report at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or a distribution package your vendor says contains the backport). Step 1 below shows how to check both the web and the command-line PHP.

Which PHP your platform version can run

Pick the newest PHP branch that both your platform version and your plugins, extensions or packages support. If your platform version stops at 8.2, upgrade the platform first.

WordPress and WooCommerce

Sources: WordPress PHP compatibility (updated 4 November 2026) and requirements; WooCommerce PHP 8.1 requirement (29 September 2026).

Read WooCommerce's new floor carefully. PHP 8.1 is the minimum from 11.6, but 8.1 itself has had no fixes since 31 December 2025. Meeting the minimum is not the same as being on supported PHP. Aim for 8.3 or 8.4.

In WordPress the risk is rarely core. It is plugins and themes, especially custom, premium or abandoned ones that declare no PHP range.

Magento Open Source and Adobe Commerce

Sources: Adobe system requirements (updated 13 October 2026), 2.4.9 release notes and released versions (updated 14 October 2026).

A Magento PHP change usually travels with other stack changes (OpenSearch, MariaDB, Valkey, Varnish), which is why the 2.4.6 case is a project rather than a switch. Our guide to Magento 2.4.7's end of life covers the rest, with an upgrade runbook.

Laravel

Source: Laravel release notes and support policy.

A Laravel 12 app can move to PHP 8.3, 8.4 or 8.5 without a framework upgrade, but Laravel 12 itself stops receiving security fixes on 24 February 2027, so plan the move to Laravel 13 alongside it. Laravel 10 and 11 apps are already outside security support for the framework and need an upgrade either way.

Step 1: find out what you're running

Check two PHPs for every site:

• Web PHP serves page requests (PHP-FPM, mod_php or LiteSpeed).
• CLI PHP runs cron jobs, queue workers, WP-CLI, Composer and bin/magento.

On many servers they are separate binaries and can be different versions. A site can serve pages on 8.4 while its nightly import still runs on 8.2.

Web PHP

• WordPress and WooCommerce: Tools › Site Health › Info › Server shows the PHP version for web requests.
• Any platform: your host's control panel, or a temporary phpinfo() page on staging only (delete it afterwards).

CLI PHP (replace placeholders such as <site-root>):

php -v                              # the default CLI binary
cd <site-root>
wp cli info                         # WordPress: the PHP binary and version WP-CLI uses, and its php.ini
wp core version                     # WordPress core version
bin/magento --version               # Magento: application version
composer show magento/product-community-edition   # Open Source (Adobe Commerce: magento/product-enterprise-edition)
php artisan --version               # Laravel: framework version
crontab -l                          # look for hard-coded binaries such as /usr/bin/php8.2

Also check your process manager (for example Supervisor) for queue workers that start a versioned PHP binary.

Step 2: check your code and dependencies

Static checks find a lot, but not everything. Treat them as a filter before testing, not a substitute for it.

WordPress and WooCommerce

List what each plugin says it needs, and what has updates waiting:

wp plugin list --fields=name,version,update,requires_php
wp theme list --fields=name,version,update

requires_php is the minimum each plugin declares (WP-CLI). Update first, on staging, then scan custom and premium code with PHPCompatibility's WordPress ruleset:

# in a tools folder or the site's development checkout, not on production
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/phpcompatibility-wp:"^3.0@dev"
vendor/bin/phpcs -p <site-root>/wp-content/themes/<theme> <site-root>/wp-content/plugins/<plugin> \
  --standard=PHPCompatibilityWP --runtime-set testVersion 8.4 --extensions=php

Why the @dev version: the last stable PHPCompatibility release, 9.3.5 (December 2019), predates PHP 8, and the project's own instructions install the 10.x line, which is still at alpha. The WordPress ruleset follows with its 3.x line.

Magento and Adobe Commerce

cd <magento-root>
composer why-not php 8.4                       # which installed packages block PHP 8.4
php8.4 "$(command -v composer)" check-platform-reqs --no-dev   # run with the target PHP binary

composer why-not (also called prohibits) lists the packages that block a PHP version; check-platform-reqs checks the PHP binary that runs it, so run it with the version you are moving to (Composer). The binary name php8.4 is an example; yours depends on how PHP is installed.

Adobe Commerce licence holders can also run Adobe's Upgrade Compatibility Tool against a target release, for example bin/uct upgrade:check <magento-root> --coming-version=2.4.8. It "is available for Adobe Commerce instances only".

Third-party extensions are the usual blockers: payment, ERP and search modules pinned to old PHP ranges.

Laravel

cd <app-root>
composer why-not php 8.4
composer config platform.php                   # is the PHP version pinned in composer.json?

If config.platform.php is pinned to 8.2, raise it to the version you are moving to (for example composer config platform.php 8.4.0), raise "php" in require if needed, then preview the change with composer update --dry-run before running it. For the framework jump to Laravel 13, follow Laravel's upgrade guide (laravel/framework to ^13.0, phpunit/phpunit to ^12.0, pestphp/pest to ^4.0).

Deprecations worth searching for

PHP 8.4 deprecates implicitly nullable parameters, such as function foo(T1 $a = null); write ?T1 $a = null instead. It also deprecates trigger_error() with E_USER_ERROR, and the E_STRICT constant (php.net). Deprecations don't break a site on their own, but they fill logs and become errors in a later major version.

Step 3: test on a copy

1. Clone production to a staging environment with a recent copy of the database.

2. Switch staging to the new PHP, for web and CLI.

3. Turn on logging, not display. In WordPress:

   Shell

   wp config set WP_DEBUG true --raw
   wp config set WP_DEBUG_LOG true --raw
   wp config set WP_DEBUG_DISPLAY false --raw
   tail -f <site-root>/wp-content/debug.log
   

   In Magento, watch var/log/exception.log and var/log/system.log; in Laravel, storage/logs/laravel.log. Watch the PHP-FPM error log too.

4. Run the journeys that earn money, not just the home page: log-in, search, basket, checkout with each payment method, account pages, admin saves, imports and exports, scheduled jobs, emails, and any API your business depends on.

5. Run your automated tests under the new PHP if you have them.

6. Fix, update or replace what fails, and repeat until the logs are clean.

Step 4: switch production

1. Take a backup you have restored before, files and database, just before the switch.
2. Pick a quiet moment. For stores, not during your busiest trading days, such as the Black Friday to Cyber Monday weekend.
3. Switch web and CLI PHP together, and update any cron entry or process-manager file that names a versioned binary.
4. Restart what holds the old PHP in memory: reload PHP-FPM (which also clears OPcache), and restart long-running workers. In Laravel, php artisan queue:restart tells workers to stop after their current job so your process manager starts them on the new binary; with Horizon, use php artisan horizon:terminate.
5. Magento: rebuild with your normal deploy steps under the new PHP (for example composer install, bin/magento setup:di:compile, static content, bin/magento cache:flush), with maintenance mode on if your process uses it.

Step 5: watch, and roll back if you need to

• Watch error logs and your monitoring through the first full cycle of scheduled jobs and a normal trading day.
• Rolling back PHP is usually just switching the version back, because a PHP change alone doesn't change your database. Restore the backup only if something wrote bad data. Keep the old PHP available until you are sure.
• Once stable, remove the debug settings from step 3.

What to ask your host

1. Who applies PHP security releases, and when did you apply the 21 October 2026 releases (8.2.35, 8.3.36, 8.4.27, 8.5.12)?
2. Which PHP versions can I run, and can I choose per site and per environment?
3. Do the web PHP and the CLI PHP (cron, queues) change together?
4. Can I test on a staging copy first, and roll back from a backup if needed?
5. What happens to sites still on 8.2 after 31 December 2026? Do they keep running, cost more, or get moved for you?
6. Who upgrades my application? Many hosts patch PHP but leave WordPress, plugins, Magento and Laravel upgrades to you or your agency. Ask which applies.

On self-managed servers the answer to the first question is usually "you". Laravel Forge's advice for the October release, for example, was: "You must update PHP on each of your servers yourself".

If you can't upgrade before 31 December 2026

Be clear about the risk: from 1 January 2027 the PHP project will publish no fixes for 8.2. Some options reduce it; none removes it.

• Ask about backported fixes. php.net notes that "Some distributions and LTS vendors provide backported fixes" for branches it no longer supports. Ask your host or operating-system vendor whether they will, for which versions, and at what cost.
• Reduce exposure: keep everything else current, restrict admin and SSH access, put a web application firewall in front of the site, and watch logs for anything unusual.
• Set a date and keep it. Running 8.2 into 2027 should be a short, documented exception with an owner, not a default.
• For Magento 2.4.6 stores, the PHP problem and the Magento problem are the same project. Plan the Magento upgrade now.

How Corefinity handles PHP versions

Corefinity provides fully managed hosting for WordPress, WooCommerce, Magento 2 and Laravel. What that means for a PHP upgrade:

• New sites run PHP 8.3, 8.4 or 8.5, chosen per environment; end-of-life PHP versions are flagged in the control panel.
• Staging and production environments for every site, with clones and push to live, so you test the new PHP on a copy first.
• Backups (snapshots) every 6 hours by default, hourly possible, kept 30 days, included, so you have a recent restore point.
• Each site runs in its own container.
• 24/7 engineer support.
• Free migration on every plan, done by our engineers, if you'd rather move to a host that runs current PHP.

CoreCluster, one managed cluster for many sites, starts from £300 / €330 / $350 a month (+ VAT in the UK and EU).

One site? CoreStack is one fully managed site with its own staging environment, ordered online, from £150 / €165 / $175 a month ex VAT (Magento 2, on CS4 with Medium staging, from £410 / €450 / $480). Order online

More on PHP hosting at Corefinity, and on what support looks like.

Sources

All checked on 7 November 2026.

• php.net, Supported versions, Unsupported branches and the 2026 news archive (advisories of 20, 21 and 23 October; 8.2.35 release; 8.6.0 RC5 of 5 November)
• php.net, Migrating from PHP 8.3 to 8.4: deprecated features
• Help Net Security, PHP2Shell article (21 October 2026)
• NCSC, Critical security issue affecting PHP (21 October 2026, updated 23 October)
• WooCommerce Developer Blog, PHP security release (21 October 2026) and PHP 8.1 requirement (29 September 2026)
• WordPress, PHP compatibility and WordPress versions (updated 4 November 2026) and Requirements
• Adobe, System requirements, 2.4.9 release notes, Released versions, Upgrade Compatibility Tool
• Laravel, Release notes and support policy and Upgrade guide
• Laravel Forge, PHP security advisory, October 2026
• PHPCompatibility, PHPCompatibility and PHPCompatibilityWP; release history on Packagist
• WP-CLI, wp plugin list and wp cli info
• Composer, command-line interface (accessed 6 November 2026)