Is Anything on Your Server Running Software That Stopped Getting Updates?

On December 31, PHP 8.2 stops receiving security fixes. PHP 8.1 and every version before it already have. Any site still running one of those versions will keep working exactly as it does today. It just won't get patched when the next vulnerability is found.

That's what makes unsupported software easy to ignore. Nothing breaks. Nothing warns you. The risk only shows up when someone finds a flaw that will never be fixed.

Out of date and unsupported are different problems

Out of date means a fix exists and you haven't applied it yet. That's a scheduling problem.

Unsupported means no fix is coming. The vendor or project has stopped maintaining that version, so every new vulnerability stays open for as long as you run it. That's a planning problem, and the only real fixes are to upgrade, replace or isolate.

The distinction matters more than it used to. Verizon's 2026 Data Breach Investigations Report found that exploiting software vulnerabilities is now the single most common way attackers get in, accounting for 31 percent of breaches, ahead of stolen credentials for the first time in the report's 19-year history.

The plugin problem is bigger than the core problem

For WordPress sites, the risk is rarely WordPress itself. Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42 percent jump on the year before. Ninety-one percent of them were in plugins.

The more worrying figure is how many had no fix ready when they became public. Patchstack found that close to half of reported vulnerabilities weren't patched by the developer before disclosure. Some plugins are simply abandoned. They still install, still run and still show up in your dashboard, but nobody is maintaining them.

Where unsupported software hides

Most teams think about the application they built. The full stack underneath it has more layers, and any one of them can reach end of life:

• The operating system. CentOS 7 reached end of life in mid-2024, and plenty of servers are still running it.
• The language runtime. PHP, Python and Node.js all retire versions on a published schedule.
• The web server and database. Older Apache, Nginx, MySQL and MariaDB releases drop out of support too.
• The control panel. Panel versions have support windows of their own.
• The CMS core. It updates often, but only if someone applies the updates.
• Plugins, themes and libraries. These are the most numerous, and the most likely to be abandoned without notice.

Build an inventory before you build a schedule

You can't patch what you haven't listed. Start with one page:

1. List every layer above for each server, with its current version.
2. Look up the support end date for each one. Most projects publish them.
3. Mark anything already past end of life in red, and anything ending in the next six months in amber.
4. For plugins, check when each was last updated. Anything untouched for a year or more deserves a closer look.
5. Remove what you don't use. An inactive plugin can still be exploited. The cheapest patch is deletion.

A patching rhythm that holds up

Once you know what you're running, the routine doesn't need to be complicated:

• Plugins and themes: check weekly. Patchstack's data shows attackers often start exploiting a disclosed WordPress flaw within hours, not weeks.
• CMS core and runtime minor versions: apply within days of release.
• OS security updates: on a fixed monthly cycle, plus immediately for anything actively exploited.
• End-of-life upgrades: plan them as projects with a date, not as tasks someone will get to.

Take a backup and test the restore before any major upgrade. An upgrade that breaks the site is the main reason teams put them off.

When you can't upgrade yet

Sometimes an old application genuinely can't move: it depends on a library that doesn't run on newer versions, or the rewrite isn't budgeted until next year. That's a real constraint, not negligence. The goal is to shrink the risk while you plan the exit:

• Isolate it. Run it on its own server or network segment so a compromise doesn't spread. We covered the approach in Running Older Applications Safely.
• Put a filter in front of it. A web application firewall can block known attack patterns against software that won't be patched.
• Limit who can reach it. If only internal users need it, it shouldn't be on the public internet.
• Set a retirement date. Isolation buys time. It doesn't make old software safe forever.

How patching works on InMotion Cloud

OS patching and hardening are included on every InMotion Cloud plan. Our engineers apply vendor updates on a scheduled cycle and push critical fixes outside it when a serious vulnerability lands. Managed in-VM support covers the layers inside your servers too: web servers, databases and application services get updates, monitoring and routine upkeep. A web application firewall and DDoS filtering sit in front of your applications as part of the platform.

One limit, stated plainly. We patch the operating system and the software stack it runs. Your application code and your choice of plugins stay yours. If a plugin you depend on is abandoned, we'll flag it and help you decide whether to replace, remove or isolate it, but that decision is yours to make. And because plans differ by managed engineer hours, a large end-of-life migration may need scoping as its own piece of work.

If you'd like help planning an upgrade or isolating something that can't move yet, talk to an InMotion Cloud engineer.