Outdated software with known vulnerabilities

Your site is made of many components written by others: a web server, WordPress, a library such as jQuery. When a vulnerability becomes known in one of them, attackers can search specifically for sites still running the old version. A newer version usually fixes the vulnerability. If you are still running an old one, we report it.

How we detect versions

Only from what your homepage sends anyway:

• the Server header, for example nginx/1.18.0
• the X-Powered-By header, for example PHP/7.4.3
• the generator tag in the HTML, which WordPress sets, among others
• the addresses of included scripts, for example jquery-3.4.1.min.js or ?ver=3.4.1

For scripts we recognize 22 widely used JavaScript libraries, including jQuery, Bootstrap, React, Vue, Angular, Lodash and Moment. We read the version only from the file name or address, not from its content. If there is no number there, we don’t detect a version. That is usually the case for bundled apps built with Vite or Next.js, where libraries sit in files with names like index-B7x2kQ9a.js. More in Technology detection.

Where our vulnerability data comes from

For JavaScript libraries, we query OSV.dev with name and version. OSV stands for Open Source Vulnerabilities. The database merges reports from many sources and lists all known entries for that version. In the finding you see how many there are (we count up to six), the description of the first entry and the identifiers, usually CVE numbers, under which you can find more. Your site doesn’t notice this lookup.

If OSV.dev is unavailable, we fall back to a small list of our own for jQuery and Bootstrap. The source then says “List” instead of OSV.dev.

We write “possibly affected” rather than “affected” because there is a lot we can’t know from the outside:

• Many vulnerabilities only apply if your site uses a specific feature of the library.
• Some vendors patch old versions without changing the number. This is common on Linux servers.
• The number in an address can differ from the real version. See Version number only in the file name.

So we can’t see whether a vulnerability is exploitable on your site. Take the finding as a reason to look. Each finding costs 8 points, 20 at most in total.

PHP, WordPress and web servers

We compare PHP and WordPress core against our own list. We report PHP below version 8.1, because it no longer receives security updates, and WordPress below version 6.4.

We don’t compare versions of web servers such as nginx or Apache. We only report that the version is visible. We don’t check individual WordPress plugins and themes.

What you can do

• Update the library. If you include it by address, change the version number there. If it is part of your project, update it there. In Lovable, Bolt, Cursor or Claude Code you can ask the assistant: “Update jQuery to the current version and check that everything still works.”
• WordPress. Let core, plugins and themes update automatically. You switch the PHP version in your host’s control panel. Make a backup first.
• Hiding the number doesn’t help. The finding might disappear, but the vulnerability stays.

Then check again. If no vulnerabilities are known for the new version, the finding disappears.

Still have questions? Email us.