The ShadowTrackr CVSS score is a standard CVSS v4 vector string that we keep continuously updated based on real-world threat activity — most importantly, exploit maturity. NVD and MITRE scores are frequently outdated the moment they're published, and even when current, CVSS v4's base score does not factor in whether a vulnerability is actively being exploited. Ours does.
That's why sorting by shadowtrackr_cvss_score instead of cvss_score in ShadowTrackr often surfaces a very different — and more actionable — priority list.
The number of published CVEs has grown every year, and that trend is accelerating. Since 2016, organizations beyond MITRE — including Microsoft, Cisco, HackerOne, and national CERTs — have been able to publish CVEs directly as CVE Numbering Authorities. That widened the pipeline considerably.
NVD, the US National Vulnerability Database, used to add enrichment data (CVSS scores, CWE classifications, affected product lists) on top of the base CVE record. Since 2026, NVD stopped enriching every incoming CVE — there are simply too many. In parallel, organizations like CISA and national NCSCs have stepped in with their own advisories, flagging the vulnerabilities that matter most within their areas of responsibility.
The result: no single upstream source gives you a complete, current, prioritized picture. ShadowTrackr's internal CVE database exists to close that gap.
We maintain an internal CVE database assembled from several sources — CVE JSON feeds, CSAF advisories, NVD, CISA KEV, national NCSC advisories, and vendor-specific feeds, among others. Some of these sources publish a usable CVSS vector string; when they do, we translate it into CVSS v4 format and update our internal vector accordingly.
Many sources don't publish a clean vector at all. Instead they describe risk in prose — “remote attack,” “exploit published,” “actively exploited in the wild” — or the signal comes from elsewhere entirely, such as a new Metasploit module targeting a specific CVE. We translate all of these signals into an update to the CVE's internal CVSS v4 vector string, log the change, and recalculate the ShadowTrackr CVSS score using the standard CVSS v4 calculator.
Every change is logged and visible. You can review the full history of updates to any CVE's score in the ShadowTrackr GUI or in the CVE search tool.
The single biggest driver of the difference is exploit maturity — a threat-metric group introduced in CVSS v4 that NVD and MITRE's published base scores do not incorporate. Exploit maturity in our model has three states:
A CVE with a high base severity but no known exploit activity poses a very different level of real-world risk than one with the same base severity that's actively being weaponized. CVSS v4's specification allows for that distinction. Most published scores don't use it. Ours does, continuously, as new threat intelligence comes in.
If you're triaging by NVD or MITRE's published score alone, you're working from a snapshot that may already be stale and that never accounted for exploitation activity in the first place. In ShadowTrackr, sorting your cves or cves_asset index by shadowtrackr_cvss_score instead of cvss_score gives you a live view of which of your exposed assets carry real, current risk — not just theoretical severity.
From there:
cves_asset index breaks vulnerabilities down one CVE, one asset per row, with first-seen and last-seen dates — useful for both current exposure and historical incident response.You can also scope any of this to the CISA KEV list, a specific national NCSC's advisories, or your own asset tags.
Knowing a CVE's score is only useful if you know it applies to what you're actually running. Vulnerability feeds describe affected versions in wildly inconsistent formats — <12.1, “all versions before 14,” “from 8.1 to 8.3,” 4.3-4.5, and dozens of other variants, sometimes within the same feed. ShadowTrackr's matching engine has been built and refined specifically to parse these formats and match them against the software we detect on your assets — including non-CVE sources like WordPress's own insecure/outdated version disclosures, which don't always get a formal CVE.
Not necessarily. It means our model currently assesses higher real-world risk, based on the same base metrics plus exploit-maturity signals NVD's published score doesn't include.
Continuously, as new source data, advisories, or exploit-activity signals come in — not on a fixed schedule.
Yes. Every vector string update is logged and viewable per-CVE in the GUI and in the CVE search tool.
No — we ingest and build on top of it. The ShadowTrackr score is designed to be a more current, more actionable layer on top of the standard CVSS v4 framework, not a replacement for it.