PHP 8.2 reaches end of life on 31 December 2026: what changes for your website.

Every WordPress, WooCommerce, Drupal and Laravel website runs on PHP, the programming language that turns a request for a page into the page itself. Like the browser on your laptop, PHP comes in versions, and each version is supported for a fixed period before the people who maintain it stop fixing it. On 31 December 2026 that period ends for PHP 8.2, the version a large share of websites were built on or moved to in 2023 and 2024. After that date, a security hole found in PHP 8.2 stays open.

This article sets out the support schedule, what October's advisory from the PHP project taught everyone about unpatched runtimes, where WordPress and WooCommerce stand, what tends to break when a website moves version, and how a support team plans the move so that it is uneventful.

What PHP is and why its version matters.

PHP is the language WordPress is written in, and the server runs it every time somebody loads a page, submits a form or completes a checkout. The hosting company installs a particular version of PHP on the server, and that version is the floor that WordPress, WooCommerce, every plugin and every theme stand on. A developer can keep every plugin current and still be running them on a runtime that has not had a security fix in years, because the PHP version is set in the hosting control panel, not in WordPress.

The PHP project publishes a support schedule and keeps to it. Each release branch gets two years of active support, during which bugs and security issues are fixed in regular point releases, then two further years during which only security issues are fixed, released as needed. After four years the branch reaches end of life and receives nothing. The schedule is public years in advance, which is why a planned move is always possible and a rushed one is always a choice.

The dates that matter.

Taken from the PHP project's own table, the picture at the end of October 2026 looks like this.

• PHP 8.1 reached end of life on 31 December 2025.
• PHP 8.2, released in December 2022, left active support on 31 December 2024 and leaves security support on 31 December 2026.
• PHP 8.3 is in its security only period and is supported until 31 December 2027.
• PHP 8.4 is in active support until 31 December 2026, then security support until 31 December 2028.
• PHP 8.5, released in November 2025, is supported until 31 December 2029.

The practical reading is that 8.2 is the last stop before unsupported, 8.3 buys only fourteen months, and 8.4 is the version a website moved today should land on unless a plugin or an integration rules it out. A website rebuilt in 2027 should start life on 8.5.

What October showed about an unpatched runtime.

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, each rated 9.2 on the CVSS version 4 scale, that allow unauthenticated remote code execution. In plain terms, an attacker who can send a request to the website can run code on the server before WordPress has loaded, with no password and no vulnerable plugin. The project described the risk as highest for Apache with mod_php, with a demonstrated exploit, and said that while a handful of configuration changes reduce exposure, there are no complete mitigations and updating is the only safe choice.

Two details from that advisory are the reason the end of life date deserves attention now. First, the fix was shipped for every supported branch on the same day, which is exactly what support means: 8.2 got its patch because it was still inside its security window. Second, the project said it had provided minimal source backports for 7.4, 8.0 and 8.1 only because of the severity, and pointed everyone else on those versions to their Linux distribution or a long term support vendor. That is a courtesy, not a policy, and a website should not be run on the assumption that it will be repeated. From January, PHP 8.2 joins that group.

Where WordPress and WooCommerce stand.

The two platforms most Australian business websites run on have already moved their recommendations past 8.2. WordPress recommends PHP 8.3 or greater; it still works on 7.4 and above, but its requirements page notes those versions have reached end of life and may expose the website to security vulnerabilities. WooCommerce's server recommendations say the same, PHP 8.3 or greater and tested up to 8.4, with the same warning about legacy environments.

WooCommerce has also set a hard floor. From WooCommerce 11.6, planned for February 2027, the minimum becomes PHP 8.1, and WooCommerce 11.3 shows stores on 7.4 or 8.0 a dismissible notice in the admin recommending they contact their host. A store that stays on an old runtime is not switched off, but it stops receiving WooCommerce updates beyond 11.5, which for a trading store means no new payment, tax or security fixes either. The floor is 8.1 for now, and on the project's own history it will keep rising.

The reason both projects move carefully is visible in WordPress.org's own statistics, read on 27 October 2026: about 27 per cent of WordPress installations report PHP 8.3, 23 per cent report 8.2, 15 per cent are still on 7.4, about 10 per cent report 8.4 and just under 10 per cent report 8.1. Put another way, from January more than half of the WordPress installations reporting in will be on a PHP version with no security support. Being in that half is a decision somebody has to own.

What breaks when a website moves version.

For a well maintained website the move from 8.2 to 8.3 or 8.4 is usually quiet, because each release deprecates behaviour for years before removing it and because the popular plugins are tested on every supported version. Problems come from the parts nobody has looked at recently.

• Abandoned plugins and themes. A plugin whose last update predates PHP 8 may rely on functions that were removed or behaviour that now throws an error. The WordPress plugin page shows the Tested up to version and the Requires PHP line; anything blank or years old is a candidate for replacement, not a reason to hold the runtime back.
• Custom code. Bespoke themes, child theme functions and integrations written for an earlier version are the most common source of fatal errors, and they are also the easiest to fix because you own them. PHP 8.2 deprecated the creation of dynamic properties on ordinary classes, and 8.4 deprecated implicitly nullable parameter types; both show up as warnings in the error log on the new version long before they become failures.
• Server extensions. Code encoders, image libraries, caching modules and database drivers are compiled for a specific PHP version. If the website depends on one, the host needs to provide the matching build.
• Hosting plans that cap the version. Some older or cheaper plans offer nothing above 8.1 or 8.2. That is a hosting problem to solve first, and our article on hosting migration covers when a move is justified.
• Silent behaviour changes. String to number comparisons and sorting changed in the PHP 8 series. These rarely break a page; they change a result, which is why testing covers checkout totals, exports and reports, not just whether the home page loads.

How a support team plans the move.

The upgrade itself is a setting in the hosting panel. The work is everything that makes changing that setting safe, and it follows a sequence that fits inside a normal support cycle.

• Find out where you are. In WooCommerce the version is under WooCommerce, then Status, under Server environment; on any WordPress website it is in the health check under Tools. Record the version for every environment, including staging and any second website on the same server.
• Choose the target. For most websites moving now, 8.4 is the right landing point; pick 8.3 only if a plugin or an extension you cannot yet replace has not been tested beyond it, and put a date on revisiting that.
• Inventory the risk. List every plugin, theme and custom integration with its last update date and its stated PHP compatibility, and run a static compatibility scan over the custom code. The output is a short list of items to update, replace or fix before anyone touches production.
• Rehearse on staging. Copy the website to a staging environment, switch it to the target version, turn on error logging and walk through the journeys that matter: pages, forms, search, login, cart, checkout, payment, account pages, exports and any integration that runs on a schedule. Fix what the log shows and repeat until it is clean.
• Change production in a quiet window. Take a backup you have tested restoring, switch the version, run the same journeys again and watch the error log for the next day. Rolling back is the same setting in reverse, which is the main reason to do this in the panel rather than by moving servers.
• Write it down. The version, the date, what was fixed and what was replaced go into the support record, with the next review date set against the schedule above.

If you cannot move before the deadline.

Some websites will not be ready by December, usually because a critical plugin or a bespoke integration needs real development first. The honest position is that the website is then running on an unsupported runtime, and the job is to shorten that period and reduce exposure while it lasts.

Ask the host whether its platform carries vendor backports for the version you are on, as the major Linux distributions and some managed hosts do, and get that in writing with an end date. Keep the web application firewall and the rest of the security stack current, knowing that October's advisory made clear these reduce exposure rather than remove it. Isolate the website from anything else on the same server, keep restorable backups, and put the development that unblocks the upgrade at the top of the support queue with an owner and a date. Treat the whole arrangement as a bridge measured in weeks.

How we can help.

Keeping the runtime inside its support window is part of the website support work we do for clients, alongside hosting, security monitoring, backups and the maintenance that keeps a website trading. If you do not know which PHP version your website runs, or you know and it is 8.2 or older, we can run the inventory above, rehearse the move on staging, make the change in a quiet window and leave you with a record and a review date. Start with a conversation about where your website is hosted and what it depends on.