A third of PHP sites run versions that get no fixes, and 8.2 is next

According to W3Techs' usage survey of 22 October 2026, 34.7% of websites that use PHP run PHP 7 or older, and every one of those versions is past its end of life. On the same day, php.net's supported-versions page shows PHP 8.2 with security support until 31 December 2026: 70 days from today. If you look after client sites, a shared hosting account or an old internal app, this is the week to find out which side of that line each one is on, because the core RCE advisory of 21 October showed what the line costs.

What the survey does and does not say

W3Techs reports that PHP is used by 69.3% of the websites whose server-side language it can identify. Among those PHP sites, it puts version 8 at 65.3%, version 7 at 26.9%, version 5 at 7.7% and version 4 at 0.1%. Two caveats belong next to those numbers. The survey can only count what is visible from outside, so a site that hides its PHP version is not in the version breakdown. And it reports major versions only: the 65.3% on "8" includes 8.0 and 8.1, which are already end of life, and 8.2, which is weeks away from it. The real end-of-life share is therefore 34.7% at the very least.

As a general pattern, old PHP survives for ordinary reasons: a shared host keeps an old version available so nothing breaks, an agency handed a site over years ago and nobody owns its upgrades, or a plugin or package pinned the runtime and was never replaced. None of those is visible from the browser, which is exactly why it keeps running.

What "security support only" means

php.net gives every branch two years of active support from its first stable release, then two more years of critical security fixes only, released as needed, then end of life. Security-only means ordinary bugs stay unfixed; only the serious holes get a release. After the end date, nothing. The project's own wording is that users of an end-of-life release may be exposed to unpatched security vulnerabilities.

The October advisory is a clear example. It states that PHP 8.1 and older no longer get updates from the PHP project. Because of the severity, the security team still published minimal source backports for 7.4, 8.0 and 8.1, for that release only, and only for people who build PHP from source. My reading, which is an inference and not a promise from anyone, is that you should not plan around that happening again.

A dated upgrade plan

The dates come straight from php.net. 8.3 gets security fixes until 31 December 2027. 8.4 is in active support until 31 December 2026 and gets security fixes until 31 December 2028. 8.5 is in active support until 31 December 2027 and gets security fixes until 31 December 2029. For a site on 8.2 today, 8.4 or 8.5 is the sensible target; moving to 8.3 buys one year and means doing it all again soon. Before you switch the runtime, check that the project's dependencies accept it:

# the version the command line runs
php -r 'echo PHP_VERSION, PHP_EOL;'
# run under the target PHP: do the dependencies accept it?
composer check-platform-reqs

Remember that the command line and the web server can run different PHP versions, so confirm the one that serves requests, too.

If someone else runs the server, ask three questions in writing. Which PHP version does the site run in production, for web requests? On what date will it move to 8.4 or 8.5? Who applies PHP security releases, and were the releases of 21 October applied?

The next step today: list your sites, write the PHP version each one serves next to its name, and give every entry below 8.3 an upgrade date before the end of the year. Source: php.net, supported versions.