PHP 8.2 Gets Its Last Security Patch on December 31. Nearly Three in Ten PHP Sites Are Already Older Than That.

The PHP project publishes its support calendar years ahead of time, in a plain table, with no marketing attached. The row that matters this autumn reads 8.2, released 8 December 2022, active support ended 31 December 2024, security support ends 31 December 2026. After that date the branch receives nothing, including fixes for flaws found the following week.

Four months is enough time to do this calmly and not enough time to keep ignoring it. The destination is not 8.2 to 8.3 as a minimum viable hop, because 8.3 loses active support at the end of December 2027 and drops to security-only itself. WordPress has already moved its stated floor, and the honest target for most sites is 8.3 or 8.4.

Start by finding out what you are actually running, which is not always what your host's marketing page implies. In any WordPress install, Tools then Site Health then Info then Server reports the PHP version in one line. Everything after that is sequencing.

The Calendar, Not the Changelog

PHP's support policy gives each release branch two years of full support followed by two years of security-only fixes, a structure the project documents on its supported versions page and which endoflife.date mirrors in the same shape. The dates are not negotiable and they do not slip.

Under that policy, 8.1 stopped receiving security fixes on 31 December 2025. PHP 8.2 follows on 31 December 2026. PHP 8.3, released November 2023, holds security support until the end of 2027. PHP 8.4, released November 2024, keeps active support through the end of this December and security support until the end of 2028. PHP 8.5 arrived in November 2025 and runs to the end of 2029.

What that produces, read across, is a narrow window where 8.4 is the only branch still in active support and 8.5 is the only one with a runway past 2028. A site landing on 8.4 today buys two years before it needs to think about this again. A site landing on 8.3 buys a little over one.

The Installed Base Is Considerably Older Than the Calendar

W3Techs, surveying on 28 August 2026, put PHP 8 at 63.2 percent of sites that run PHP. PHP 7 accounted for 28.8 percent and PHP 5 for another 7.9 percent, with a residue of 0.1 percent still on PHP 4. The PHP 7 line reached its final security date in November 2022, so nearly three in ten PHP sites are running a language runtime that has been unpatched for approaching four years.

Those numbers do not describe abandoned hobby projects. PHP still powers 70.2 percent of the sites whose server-side language can be identified at all, which means the unpatched share represents a very large number of live commercial sites with checkout pages and contact forms on them.

The reason for the lag is rarely ignorance and almost always fear, specifically the fear that a version bump will produce a white screen on a Tuesday afternoon. That fear is reasonable. It is also the thing a staging copy exists to eliminate.

Why WordPress Moved the Floor

The official WordPress requirements page now states the position without hedging.

PHP: Version 8.3 or greater. MariaDB 10.11+ or MySQL 8.0+. HTTPS: Required for every install.

The same page notes that WordPress will still run on PHP 7.4 and MySQL 5.5.5, then adds that these versions have reached end of life and may expose a site to security vulnerabilities. That is the distinction most site owners miss. WordPress PHP requirements describe what the software will tolerate and what the project recommends, and those are two different lines on the same page.

Practically, a plugin developer testing against 8.3 and 8.4 has no obligation to keep an eye on 8.2 behavior once the branch is out of support. Compatibility problems on old runtimes stop being bugs and start being an unsupported configuration, which changes what a support ticket gets you.

The Server Is Not the Whole Defense

Patchstack's State of WordPress Security in 2026 recorded 11,334 new vulnerabilities across the WordPress ecosystem during 2025, a 42 percent increase on the previous year. Plugins accounted for 91 percent of them and themes for 9 percent, while WordPress core produced six, all rated low priority.

High-severity findings rose 113 percent year over year, and the report puts the median time to mass exploitation at five hours, with roughly half of high-impact vulnerabilities exploited inside twenty-four hours. Broken access control made up 57 percent of the most targeted vulnerability types, privilege escalation another 20 percent.

The finding that should reframe how anyone thinks about hosting is the block rate. Patchstack measured hosting-level defenses stopping 12 percent of attacks against known exploited WordPress vulnerabilities, and 26 percent across a wider set. Whatever your host's firewall page claims, it is catching a minority of what arrives, which is the argument for keeping the runtime underneath it current rather than treating the server as a shield. We made a version of this case when hosting configuration started functioning as a trust signal, and the numbers have only sharpened since.

A Four-Month Sequence That Does Not Break Production

September: Inventory

Record the current PHP version from Site Health for every site you manage, in one spreadsheet, with the host and the control panel type beside it. Then install a compatibility scanner such as PHP Compatibility Checker or run PHPCS with the PHPCompatibilityWP ruleset against your active theme and plugins, targeting 8.4. The scan produces noise, and the signal inside it is the list of deprecated function calls in code you actually control.

Flag anything abandoned. A plugin with no update in three years will not be patched for a new runtime, and the upgrade is the moment to replace it rather than the moment to discover it.

October: Test on a Copy

Clone the site to a staging environment, which every serious host now offers as a one-click operation, and switch the staging PHP version to 8.4. Load the admin, run a checkout if there is one, submit every form, and check the error log rather than trusting the front end to look fine.

The failures cluster in two places. Custom theme functions written before PHP 8 tend to break on passing null where a string is expected, which was a deprecation in 8.1 and is stricter now. Older commercial plugins break on removed functions and on the tightened rules around dynamic properties. Both produce specific line numbers in the log, which makes them fixable rather than mysterious.

November: Switch, With a Rollback Ready

Take a full backup, confirm you can actually restore it, and change the live PHP version through the host control panel in a low-traffic window. Most panels let you revert in a click, which means the worst realistic outcome is a few minutes of degraded service rather than a rebuild.

Watch the error log for forty-eight hours afterward, not the homepage. Sites that appear healthy frequently throw warnings on the checkout confirmation or the password reset, and those are the paths nobody clicks during a manual check. If something does go wrong at speed, our emergency recovery sequence covers the triage order.

December: Close the Loop

Set a calendar reminder for the next PHP end of life date that applies to you, which is 31 December 2027 if you landed on 8.3 and 31 December 2028 if you landed on 8.4. Then check the version once more, because some hosts run scheduled migrations that quietly reset a per-site override back to the account default.

The deadline is 31 December. The work is four evenings spread across four months, and none of them has to be the evening the site goes down.