How to check your website for known vulnerabilities

CVE stands for Common Vulnerabilities and Exposures. It is a public catalogue of security weaknesses in software, run by the CVE Program with sponsorship from the US Cybersecurity and Infrastructure Security Agency (CISA). Each weakness gets one identifier made of a year and a number, such as CVE-2024-12345, so that a vendor, a researcher and a site owner can be certain they are talking about the same flaw.

A CVE record describes the flaw, names the affected product and versions, and usually points to the fix. In India, CERT-In publishes vulnerability notes that group related CVEs for widely used software and say what to update, which is often the most readable place to start.

What a CVE is not: it is not evidence that your website has been attacked, and on its own it is not even evidence that your website is affected. It is a fact about a version of a piece of software. Whether it applies to you depends on which version you run and how it is set up.

Every website is a stack of software, and each layer can have its own CVEs: the web server (Apache, nginx, LiteSpeed or IIS), the language it runs on (PHP, Node.js, Python), the application (WordPress, Joomla, Magento or a custom framework), every plugin, theme and library on top of it, and the database underneath.

The most reliable inventory comes from the inside. Your hosting control panel shows the PHP and server versions. WordPress lists its own version, plugins and themes on its Updates screen. A custom application's dependency file — package.json, composer.json or requirements.txt — lists its libraries and their versions. Write the list down. Most site owners find at least one plugin nobody remembers installing.

Then compare it with the outside view. Many websites announce their software and version to every visitor, in response headers, in a generator tag, or in the version numbers on script and stylesheet links. Anything visible from outside is visible to an attacker's automated tools too, which is why it is worth knowing what yours shows.

With a list of products and versions, the lookup is mechanical. The US National Vulnerability Database (NVD), run by NIST, can be searched by product name. The software's own security page or changelog is often faster and more precise: WordPress lists the security fixes in each release, and well-maintained plugins say which version fixed which issue.

Read the affected versions carefully. A record that says a flaw affects versions before 5.2.1 does not concern you if you run 5.2.1 or later, and a flaw in a feature you have switched off may not be reachable at all. Most false alarms come from skipping this step.

This is exactly what an automated checker does. A free check such as the one on this site reads the software and versions your website shows publicly and matches them against the public records. It is quick and never tests or touches your site, but it can only see what your site reveals, which is why the inside list from step one still matters.

Most CVEs carry a CVSS score, a number from 0 to 10 defined by an open standard maintained by FIRST, the Forum of Incident Response and Security Teams. The usual bands are 9.0 to 10.0 Critical, 7.0 to 8.9 High, 4.0 to 6.9 Medium and 0.1 to 3.9 Low. The score describes how bad the weakness is in general: how easily it can be reached, whether an attacker must log in first, and what they could do with it.

What the score does not tell you is whether anyone is using the weakness. For that, CISA maintains the Known Exploited Vulnerabilities catalogue, a list of CVEs confirmed to be exploited in real attacks. A Medium flaw on that list is usually more urgent than a Critical one nobody has found a way to use yet.

A sensible order for a small business: anything on the known-exploited list first, then Critical, then High, then the rest during routine maintenance. One update often fixes several CVEs at once, in which case the order matters less than doing the update.

Public databases run a step behind, and in 2026 they fell further behind. Tens of thousands of CVEs are now published every year, and in April 2026 NIST announced that the NVD would prioritise its detailed analysis — the affected-version data and scores that automated tools depend on — for vulnerabilities in CISA's known-exploited catalogue, software used by the US government and other critical software, and mark the rest as not scheduled.

In practice, a new CVE can sit in the database for a long time with no machine-readable list of affected versions. Any tool that relies on that list, free or paid, ours included, cannot match it until the data arrives. The vendor's own advisory usually comes first, which is the case for subscribing to the security announcements of the software you run.

There is a second blind spot. A check that reads what your site shows cannot see what it hides. A site that removes its version numbers, or runs software the checker does not recognise, can come back clean and still be out of date. Hiding version numbers slows automated scanners down a little; it does not remove the weakness, and it is no substitute for updating.

Update. For the great majority of CVEs in website software the fix is a newer version that has already been released. Take a backup you have actually tested restoring, apply the update to a staging copy if you have one, check the site still works, then update the live site. On WordPress, core's automatic minor updates and per-plugin auto-updates handle much of this once they are switched on.

If no update exists yet, the vendor's advisory usually describes a workaround: switching off the affected feature, restricting access to an admin path, or a firewall rule. If a plugin has been abandoned and will never be fixed, replace it. An unmaintained plugin is a CVE waiting to be published.

Then ask whether the weakness was used before you fixed it. A critical, known-exploited flaw that sat unpatched for months deserves a look at the logs, the list of admin users and recently changed files; our guide to the signs of a compromised server covers what to look for. If your business falls under CERT-In's Directions, an actual compromise may also have to be reported within six hours.

One check tells you where you stand today. New CVEs are published every day for the software most websites run, so the useful version of this is a habit: the inventory kept current, updates applied on a fixed schedule, and the security announcements for your main software arriving in an inbox someone reads.

For a small brochure site, once a month is a sensible minimum, with an immediate update whenever a critical or known-exploited flaw is announced for something you run. For a website that takes orders or holds customer data, continuous monitoring is worth having, because the gap between a public CVE and automated attacks against it can be a matter of days.

Whatever you do, check only websites you own or have written permission to test. Probing someone else's systems without permission is not a favour to them, and in India it can be an offence under the Information Technology Act.