Check your website for outdated software and known CVEs

How the outdated software and CVE check works

Many sites say more about their software than their owners expect. A response header may read X-Powered-By: PHP/8.3.12, a WordPress page may carry a generator tag with its version, and a file name such as jquery-3.4.1.min.js gives away a library version. The check collects these signs from the responses it receives anyway.

• Detect technologies: web server, language, CMS, plugins, front-end libraries and hosted platforms.
• Read a version only where the site shows one, and rate how sure we are. A guessed or conflicting version is never matched against vulnerability data.
• Compare the version with lifecycle data: a curated list in our code and a cached copy of endoflife.date for languages and CMS.
• For PHP and other languages, compare the exact patch with the security releases of that branch.
• Look up public advisories for that product and version in OSV, NVD and the CISA Known Exploited Vulnerabilities catalog, and add the FIRST EPSS score where one exists.

What we report and how we word it

A match that is listed in the CISA catalog of known exploited vulnerabilities gets a higher severity. EPSS adds the estimated probability that a CVE will be exploited in the next 30 days. Neither means that your site has been attacked.

PHP version check: why the patch number matters

Each PHP branch gets security fixes for a fixed period. According to php.net, 8.2 receives them until 31 December 2026, 8.3 until 31 December 2027, 8.4 until 31 December 2028 and 8.5 until 31 December 2029. Older branches get none.

A supported branch is not enough on its own. On 21 October 2026 php.net released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix two critical remote code execution vulnerabilities and asked all users to update immediately. A site on an earlier patch of the same branch is missing those fixes.

If your site shows its exact PHP version, the check compares it with the security fixes recorded for that branch and tells you whether a newer security release exists. If it shows only 8.3, we say the patch is unknown instead of guessing. Our article How to check your PHP version shows how to see it yourself.

How to read a version match

A detected version is not a confirmed vulnerability. Linux distributions often ship security fixes without changing the version number, the affected feature may be switched off, and a proxy or CDN in front of the site may show its own server name. So the report says “potentially affected” and names where the version came from: a header, a meta tag or a file name.

For each match, update the component, or ask your host whether the fix is already in the package they ship. If it is, the match does not apply to your server.

The reverse also holds: when a site hides its versions, there is nothing to match, and a hidden version is not proof that the software is current.

What this check does not do

• It sees only what the site shows. Software that leaves no trace in public responses, or hides its version, gets no version-based finding.
• It does not log in, read package lists or run exploit code, so it cannot confirm that a vulnerability is reachable on your site.
• It reads the homepage and a few known files, not every page. Plugins and libraries used only on inner pages may be missed.
• Hosted platforms such as Shopify, Wix or Webflow are updated by their provider; we do not attribute their CVEs to your site.
• Lifecycle and advisory data are cached copies, so a brand-new advisory can show up with a delay.
• It does not scan for malware or check blocklists.
• Owner-verified only: on a site with verified ownership, the active port check can also read service versions on open ports, and only the verified owner sees them. For other sites the check does not connect to those ports.