If your WordPress site is still running on PHP 7 or earlier, it’s not just outdated. It’s sitting on top of thousands of security holes nobody is ever going to patch.
That’s the blunt point developer Milan Petrović made on a recent WP Tavern podcast: PHP versions older than 8.0 have somewhere in the range of 3,000 to 4,000 open bug reports that will never receive fixes, because those versions are past their official support window. For attackers, that’s not a risk to work around; it’s an open invitation. A publicly documented, permanently unpatched bug is easier to exploit than a zero-day, because there’s no race against a patch. The vulnerability just sits there, indefinitely exploitable, for anyone who bothers to look it up.
Add to that the hosting-side wrinkle Petrović flagged: some hosts run custom PHP builds that don’t map cleanly onto the official support timeline, which makes it harder for a site owner to even tell whether they’re exposed. For context on how far behind “legacy” actually is: PHP 7.4 hit its own end of life back in November 2022, and as of early 2026 only PHP 8.2 and newer receive any security support at all — everything at 8.1 or below, not just 7.x, is now unsupported.
Why this hasn’t been forced already
You’d expect WordPress core to simply raise its minimum PHP requirement and settle the question. Petrović thinks that’s the right move too — he’d like to see the floor raised to PHP 8.0 or 8.1 — but he doesn’t expect it to happen for “at least a year or two, maybe even more.” WordPress powers a huge share of the web, and a lot of that share is sites nobody is actively maintaining. Core has to weigh cutting off legacy PHP against locking those sites out of updates entirely, which is its own kind of risk.
That means the fix isn’t going to arrive automatically. It’s on individual site owners and hosts to move first.
The upgrade doesn’t have to be a rewrite
The good part of Petrović’s argument is that modernizing doesn’t require a big-bang migration. Incremental changes (adding stricter typing, swapping out deprecated functions, adopting newer PHP language features as you touch existing code) get you most of the way there without a full rebuild.
There’s also a performance argument that has nothing to do with security: PHP 8.5 is over 50% faster than PHP 7.4 while using noticeably less memory, and even the more modest jump to PHP 8.3 hosting brings a real, measurable speed gain over 8.1. That’s not a marketing number; it’s an architectural one. Newer PHP versions handle memory and execution more efficiently under the hood. For a host, that difference shows up directly in server load per request.
What this means if you’re choosing (or re-checking) a host
The practical question to ask any host, including us, is simple: what PHP version does my plan actually run, and can I control it? AllCloudHost’s WordPress hosting plans run current, supported PHP versions rather than leaving sites parked on a legacy build by default. If you’re not sure what your current site is running, your hosting control panel will show it — and if it says PHP 7.x or older, that’s worth fixing before it’s worth anything else on this list.
The unglamorous truth here is that most WordPress security incidents aren’t zero-days. They’re known, published, years-old bugs that nobody got around to patching because nobody checked what PHP version they were still running.