Out-of-date software and known vulnerabilities

The short version

How a known vulnerability becomes an attack on you

When a researcher finds a flaw in, say, a popular WordPress form plugin, it is reported to the developer, fixed, and then disclosed publicly with an identifier like CVE-2026-12345. The disclosure describes what the flaw is and which versions are affected. This is a good system — it is how everyone learns to patch — but it has a side effect: the day a fix is released is also the day the flaw becomes common knowledge.

Within hours, exploit code circulates. Within days, bots are scanning millions of sites checking the plugin's version and attacking any that have not updated. Your site is not targeted because of who you are. It is targeted because a scanner found a version number that matches a list. The 2026 PHP2Shell flaw is a textbook example: the versions affected were public, the fix was public, and the attacks began immediately against anything still unpatched.

The uncomfortable statistic from every breach report: the overwhelming majority of successful website attacks use vulnerabilities for which a fix had been available for months, often years.

The layers, and who updates each one

• Web server (Apache, nginx, LiteSpeed) — on shared hosting, your host updates this. On a VPS, you do, usually via the operating system's package manager.
• PHP — on cPanel hosting you typically *choose* the version in a "Select PHP Version" or "MultiPHP Manager" screen, and the host patches within that version. Being on PHP 7.4 or 8.0 means your version no longer receives security fixes at all, regardless of how diligent your host is.
• The platform (WordPress, Joomla, Magento, Drupal) — you, or whoever manages the site. WordPress can auto-update minor versions and, since 5.5, plugins and themes too.
• Themes and plugins — you. These are where most WordPress compromises happen, because there are tens of thousands of them, of wildly varying quality, and sites accumulate ones nobody uses any more.
• JavaScript libraries in the page (jQuery, Bootstrap, Swiper, Lodash) — often bundled with a theme and forgotten. An old jQuery is one of the most common findings on the web; its known holes let attackers inject scripts via crafted content.

Why "it still works" is not a reason to leave it

Old software usually works fine, right up until it is used against you. The flaws are not bugs you would notice — the page loads, the form submits — they are ways for someone else to do something the software was never meant to allow: upload a file, run a command, read the database, create an admin account. Nothing looks broken until the site is defaced, redirecting to scam pages, sending spam, or quietly hosting a card skimmer on your checkout.

There is also a cumulative cost. The longer you leave updates, the bigger the jump when you finally do them, and the more likely something *does* break — which is exactly the experience that makes people afraid to update at all. Small, frequent updates are far safer than rare, large ones.

Doing it safely

The fear of updates is usually a fear of not being able to undo one. So the method is: make undo easy, then update often.

• Backups first, every time. Your host likely has daily backups (cPanel's JetBackup or similar); check they exist and that you know how to restore one. For WordPress, UpdraftPlus or similar gives you a one-click backup immediately before updating.
• Turn on automatic updates for everything that supports it. WordPress core, plugins and themes all can. The occasional broken update is far less costly than the compromise you are preventing. If you have a complex site, use a staging copy — many hosts offer one — to test first.
• Delete what you do not use. A deactivated plugin is still code on your server and can still be exploited. Remove unused plugins, themes (keep one default theme as a fallback) and old installations in subfolders.
• Move PHP forward. In your hosting panel, select the newest PHP version your site supports — 8.2 or later as of 2026. Test the site; most well-maintained plugins are fine. If something breaks, that plugin is probably abandoned and should be replaced anyway.
• Replace abandoned software. A plugin not updated in two years, or a theme whose developer has disappeared, will never get a fix. Find a maintained alternative.
• Check JavaScript libraries. If your theme bundles an old jQuery or Bootstrap, update the theme; if the theme is abandoned, a developer can update the library directly or switch to a modern theme.

What VigilScan checks

We identify the software your site reveals — server and PHP versions from response headers, the platform and its version from page markup and well-known files, and JavaScript libraries from the scripts your homepage loads — and compare each version against published vulnerability data. Where we find a match we show the version we saw, the CVE identifiers, and their severity, so you can see exactly what is affected and prioritise. On verified domains, deeper scans enumerate WordPress plugins and themes and check each against known vulnerabilities, which is where the most serious findings usually are.

We only report what the site exposes from the outside. A site that hides its versions (good practice — see our guide to version leaks) may have out-of-date software we cannot see; that is a reason to check inside your admin panel too, not a reason to feel safe.

Common questions