Support Library

Known Vulnerabilities (CVEs) in Website Software

Every widely used web server, language runtime and CMS has published security flaws. Each one gets a CVE identifier, a severity score and, usually, a fixed release. When your website announces a version that is still affected, anyone can look up how to attack it, and for flaws that are already being exploited, automated tools do exactly that.

Author
CategoryWebsite Security
Length6 minute read
UpdatedNovember 1, 2026

The short answer

Update the software named in the finding to a release that fixes the listed CVEs, starting with any that CISA lists as known exploited. If the version comes from a Linux distribution package, install the distribution’s security updates and check its advisory for each CVE, because the fix may already be in place without a new version number.

How an unpatched version gets attacked

How a published vulnerability leads to an attack on an unpatched site, and how patching stops it Top, not patched: the site reveals Apache 2.4.49. A path traversal flaw, CVE-2021-41773, is published for that version and CISA adds it to its Known Exploited Vulnerabilities list because attackers are using it. Automated scanners find the site and exploit it. Bottom, patched: the vendor releases a fixed version, the team applies it within days, and the same scan finds nothing to exploit. Not patched Version revealed Apache/2.4.49 CVE published CVE-2021-41773 Exploited in the wild On CISA’s KEV list Site attacked Automated, at scale Public exploit matches the version Every day unpatched adds risk Patched promptly Vendor fix released Advisory and new version Update applied Package or upgrade Scan finds nothing Flaw is gone Site stays safe Monitor for the next one Known flaw closed Exploit attempts fail How a published vulnerability leads to an attack on an unpatched site, and how patching stops it Top, not patched: the site reveals Apache 2.4.49. A path traversal flaw, CVE-2021-41773, is published for that version and CISA adds it to its Known Exploited Vulnerabilities list because attackers are using it. Automated scanners find the site and exploit it. Bottom, patched: the vendor releases a fixed version, the team applies it within days, and the same scan finds nothing to exploit. Not patched Version revealed Apache/2.4.49 CVE published CVE-2021-41773 Exploited in the wild On CISA’s KEV list Site attacked Automated, at scale Public exploit matches the version Every day unpatched adds risk Patched promptly Vendor fix released Advisory and new version Update applied Package or upgrade Scan finds nothing Flaw is gone Site stays safe Monitor for the next one Known flaw closed Exploit attempts fail
Apache 2.4.49 is a real example: its path traversal flaw was exploited within days of disclosure in October 2021, and 2.4.50’s fix was incomplete, so 2.4.51 was needed.

How DNS Panopticon detects it

Security Posture collects the software versions your homepage reveals: the Server and X-Powered-By headers (for example Apache/2.4.49, OpenSSL/1.0.2k or PHP/7.4.3) and what Website Recon’s technology detection reads from the page, such as a WordPress generator tag or a jQuery file name. Apache, nginx, OpenResty, IIS, Tomcat, OpenSSL, PHP, WordPress, Drupal, Joomla and jQuery are matched. Each version is looked up in the NIST National Vulnerability Database (NVD), with CISA’s known-exploited flag. The result appears on the Vulnerability Management card.

FindingSeverityWhen it appears
… has vulnerabilities attackers are exploitingCriticalAt least one CVE affecting this version is on CISA’s Known Exploited Vulnerabilities (KEV) list. The finding names up to three.
… has N known vulnerabilitiesBy CVSS scoreThe NVD lists CVEs for this version. Severity follows the worst CVSS score: 9.0 and above is critical, 7.0 to 8.9 high, 4.0 to 6.9 medium, lower or unscored is low.
Same, on a distribution buildMediumThe version string names a Linux distribution (Ubuntu, Debian, Red Hat, CentOS and others). Distributions often backport fixes without changing the version, so the card takes fewer points off and says so.
No known vulnerabilities in …PassThe NVD lists no CVEs for this version.
… couldn’t be checked for CVEsNot gradedThe NVD did not answer. Scanning again usually works.

Matching is by version number only. Software that hides its version cannot be matched, and when nothing reveals a version the card is not graded. Hiding the version is covered in Server Version Disclosure, but it is not a substitute for patching.

How to check it yourself

Command or toolWhat it tells you
curl -sI https://example.comThe versions your site reveals in its server and x-powered-by headers.
apachectl -vThe installed Apache version, run on the server (nginx: nginx -v).
php -vThe installed PHP version.
openssl versionThe installed OpenSSL version.
wp core versionThe installed WordPress version, with WP-CLI.
apt list --upgradableDebian and Ubuntu packages with pending updates (Red Hat family: dnf updateinfo list --security).

To see what a specific CVE affects, search for it on the NVD or CVE.org, and check whether it is on CISA’s KEV catalog. For distribution packages, the Ubuntu, Debian and Red Hat CVE trackers say which package release fixed it.

Reading CVEs and priorities

TermWhat it meansHow to use it
CVEA unique ID for one publicly disclosed vulnerability, such as CVE-2021-41773.Look it up to see the affected versions and the fix.
CVSS scoreA 0 to 10 rating of how severe the flaw is in general.A guide to impact, not to how likely an attack is.
CISA KEVCISA’s list of CVEs with evidence of exploitation in the wild.Fix these first, whatever their score.
EPSSFIRST’s daily estimate of how likely a CVE is to be exploited in the next 30 days.Helps order the rest when there are many.
BackportA distribution applies the fix to its own build without changing the upstream version number.Check the distribution’s advisory before assuming you are affected.

Why it matters

  • Attacks are automated. Once an exploit is public, scanners try it against every server that looks affected. Small sites are hit just as often as large ones.
  • Web servers are the front door. A flaw in the web server, PHP or the CMS can give an attacker files, data or a foothold on the network.
  • Exploited flaws move fast. CISA gives US federal agencies two weeks or less to fix newly listed KEV entries. That is a reasonable target for everyone.
  • Old components are a top risk. OWASP ranks vulnerable and outdated components among the most common causes of web application breaches.

How to fix it

  1. Fix known-exploited CVEs first. Update to the version the vendor advisory names as fixed. If you cannot update straight away, apply the advisory’s workaround and restrict access in the meantime.
  2. Use your package manager when the software came from one: sudo apt update && sudo apt upgrade on Debian and Ubuntu, sudo dnf upgrade --security on Red Hat, AlmaLinux and Rocky Linux. Restart the service afterwards so the new code is running.
  3. Update applications in place: WordPress, Drupal and Joomla from their admin dashboards or command-line tools, including plugins and themes. Replace bundled JavaScript libraries such as jQuery with a current release and test the pages that use them.
  4. If the release line itself has ended, patching inside it is no longer possible; plan the move described in End-of-Life and Outdated Website Software.
  5. Scan again with DNS Panopticon to confirm the new version no longer matches.
  6. Make it routine. Turn on automatic security updates where it is safe (unattended-upgrades, dnf-automatic, WordPress automatic background updates), subscribe to your vendors’ security announcements, and keep a list of the software each site runs.

FAQ

The finding lists CVEs, but my distribution says they are fixed. Who is right?

Possibly both. DNS Panopticon only sees the upstream version number, and distributions such as Debian, Ubuntu and Red Hat backport fixes into the same version. If the distribution’s tracker shows your package release as fixed for each CVE, you are protected. That is why distribution builds cost fewer points.

Does hiding the version fix this finding?

It removes the finding, because nothing can be matched, but the flaw is still there. Attackers often try exploits without checking versions. Patch first, then hide the version if you like.

A CVE is scored 9.8 but not on the KEV list. Should it wait?

Not for long. KEV entries are being exploited now, so they come first, but a critical flaw can be added to the list at any time. Plan to fix critical and high CVEs within days to weeks.

Why does jQuery show up? It runs in the browser.

Old jQuery versions have cross-site scripting flaws that attackers can trigger through your pages. They are lower risk than server flaws but should still be updated.

Sources and further reading

Related support articles

End-of-Life and Outdated Website SoftwareServer Version DisclosureEnd-of-Life Server Operating SystemsContent-Security-Policy