Outdated PHP version

The support schedule is published years in advance and is not extended for popular versions.

After the security window closes, a fix released for supported versions is simply not backported.

So the gap between your runtime and a supported one widens continuously rather than staying fixed.

Some Linux distributions backport fixes into their own packaged builds for longer, which is real and applies only to those packages.

A hosting provider may also maintain its own patched build, which is worth confirming rather than assuming.

Performance: successive major versions have brought substantial improvements, so an upgrade is frequently the cheapest speed gain available on a PHP site.

Plugin and theme compatibility, which increasingly requires a recent version and eventually stops supporting old ones.

Core platform support: WordPress publishes a minimum and a recommended version, and the recommended one moves.

Which means the version is not only a security question — it is what decides whether the ecosystem still works with the site.

Nothing breaks on the day support ends: the site runs exactly as it did the day before.

The risk is that a plugin or a theme uses something removed in the newer version, which is discovered by trying.

On a site with many plugins, the surface for that is large and nobody wants to be the one who finds it in production.

So it is deferred once, then again, and then the gap is two major versions and the upgrade is genuinely harder.

Upgrading one major version at a time, promptly, is considerably less work than catching up later.

Take a full backup — files and database — and confirm you can restore it before changing anything.

Copy the site to a staging environment on the target version and exercise the paths that matter: the checkout, the forms, the admin screens.

Enable error logging on staging and read it, since deprecation notices name exactly what will break.

Update plugins and themes before the runtime, since current versions are far more likely to support it.

Switch production during a quiet period with the rollback path confirmed, and watch the error log for the first hours.

Find out which component blocks it, which is usually one plugin or one piece of custom code.

Replace or rewrite that component, which is the only path that ends with a supported runtime.

In the meantime, confirm whether your distribution or host backports fixes into the build you run.

Remove the version from response headers so it is not advertised, understanding that this changes nothing about the risk.

Treat it as a dated commitment rather than a standing state, because the gap only widens.

`curl -I https://example.com | grep -i x-powered-by` shows the version where the header is sent.

Many servers suppress that header, in which case the platform's own admin screens report the runtime version.

Compare it against the published support schedule, which states the end date for each branch.

Check the staging environment separately, since it frequently runs a different version from production.

Confirm with your host whether their build receives backported fixes, which changes how urgent the finding is.

`wordpress.php` reports the PHP version where it is publicly observable.

`wordpress.detected` and `wordpress.version` establish the platform and its core version.

`technology.stack` and `quality.technologies` report the runtime detected from response signals generally.

`exposure.internal.paths` and `api.errors.disclosure` are neighbouring checks, since error output frequently reveals the runtime when no header does.

No version is matched against a vulnerability database: what is reported is what the site advertises, compared against a published support schedule.

PHP compiles source to opcodes on every request unless an opcode cache stores the result, which is the difference between a site that is merely slow and one that is unusable under load.

It is a runtime extension rather than a plugin, so it is configured by whoever administers the server and is invisible from the application.

A managed host usually enables it; a server built by hand frequently does not, and the omission survives because the site works.

Its memory allocation also matters: a cache too small for the codebase evicts constantly and provides much less than it should.

An upgrade is the moment to check it, since the configuration is frequently carried over from an older build or lost entirely.