Breaking Lab srl
Most people running a WordPress site could not tell you which version of PHP it is using, and for a long time that was a reasonable thing not to know. It has quietly become a security decision instead of a technical detail, and the reason is not the one usually given.
What “end of life” actually means
Every PHP branch gets two windows. First active support, where bugs and security holes are both fixed. Then a security-only window, where the maintainers patch security issues and nothing else. After that the branch is finished: a vulnerability found in it is simply never fixed.
PHP 7.4 reached that final point in November 2022. PHP 8.0 followed a year later, in November 2023. Anything running on those branches today is running an interpreter that will not receive another security patch, no matter what is discovered in it.
Rather than trust a table in an article — including this one, which will age — check php.net/supported-versions. It is authoritative and it is updated when the dates move. Anyone quoting you a support table from memory is quoting a snapshot.
The honest version of the risk
Here is the part that hosting companies and plugin vendors both tend to skip, in opposite directions.
An unsupported PHP version is not an open door. Most WordPress sites that get compromised are not compromised through the interpreter — they are compromised through a plugin, a theme, or a weak administrator password. That is where the volume is, by a wide margin. If you are running PHP 7.4 with a fully patched WordPress and a small number of maintained plugins, you are in less danger than someone on PHP 8.3 with eleven abandoned plugins and no two-factor authentication.
So the panic framing is wrong. But so is the shrug, and for a specific reason: the risk from an unsupported interpreter is not constant, it grows. Every month adds newly discovered issues that will be fixed in the supported branches and left standing in yours. You are not running a slightly older version — you are running a version whose defects accumulate permanently. The gap only widens.
There is a second cost, less dramatic and more likely to bite you first: things stop being built for you. Plugin and theme authors drop old branches, security plugins raise their minimum, and eventually the thing you actually need to install refuses to run.
Why people stay on old versions
Almost never laziness. Usually one line of somebody else’s code.
PHP 8 removed language features, not just deprecated them. The clearest example is create_function(), a way of building a function from a string that was deprecated in 7.2 and removed outright in 8.0. A theme that calls it does not warn you on PHP 8. It stops working.
This is exactly what pins a lot of WordPress installations in place, and it is worth naming plainly: it is rarely the site that blocks the upgrade, it is the theme. A theme bought once in 2017, customised, and now central to how the site looks. The author has moved on, the license expired, and nobody wants to be the person who upgrades PHP and discovers the front page has gone blank.
That is a real problem and it does not get solved by being told to upgrade. It gets solved by finding out, on a copy, exactly what breaks — and then deciding whether the fix is a patched theme, a replacement, or a rebuild.
The trap almost nobody mentions: the shared pool
If you run several sites on one server, there is a good chance they share a single PHP-FPM pool. It is the default arrangement on most control panels and it is efficient: one set of worker processes serving everything.
It also means the PHP version is not a per-site setting. Switching the pool to a newer branch switches every site on it at once. Six sites, one decision, and if the oldest theme among them breaks, it breaks in company.
This changes the order of operations. You do not upgrade the server and then check the sites; you check every site on the pool first, on copies, and only then move the pool. Or you split the pool — give the problem site its own, on the old branch, and move the rest — which costs a little memory and buys you the ability to deal with them one at a time.
If you are working out how much room that server actually has for another pool, how much RAM you actually need for multiple WordPress sites on one VPS has measured numbers for exactly that arithmetic.
What to actually do, in order
Find out what you are on. Tools like Site Health in WordPress will tell you, and so will a one-line script. You cannot make a decision about a version you have not looked up.
Check whether the version is still supported — the php.net table, not an article.
If it is not, test on a copy before touching anything. Not on the live site, not at the weekend when nobody is around to notice the front page has gone white. A copy is cheap and it converts an open-ended fear into a list of specific errors.
Check what shares the pool. This is the step people skip, and it is the one that turns a routine upgrade into an outage across several sites at once.
Then decide honestly. Sometimes the answer is to upgrade. Sometimes it is to stay on the old branch deliberately, with the risk understood and everything else — WordPress core, plugins, passwords — kept tight. That is a defensible position, as long as it is a decision rather than an accident.
If you are weighing that trade-off for a real site rather than in the abstract, we went through it in detail in can you still run WordPress on PHP 7.4 in 2026? — including what the choice actually costs when you make it on purpose.
