A known vulnerability is a software weakness that has been publicly disclosed, assigned a tracking identifier (usually a CVE ID), and cataloged in at least one public database such as the National Vulnerability Database (NVD) or the MITRE CVE List. Once a flaw crosses that line — from privately discovered bug to publicly indexed record — it becomes something defenders can search for, scanners can detect, and attackers can weaponize at scale. CVE-2021-44228 (Log4Shell) is a known vulnerability. So is CVE-2017-5638, the Apache Struts flaw Equifax failed to patch before its 2017 breach. The distinction matters because "known" doesn't mean "harmless" — it means documented, and documentation cuts both ways. Security teams use known-vulnerability data to prioritize patching; attackers use the same data to build exploits within hours of disclosure. This glossary entry breaks down how the known-vulnerability system works, who runs it, and why disclosure alone doesn't equal remediation.
What is a known vulnerability?
A known vulnerability is a security flaw that has been publicly identified, documented, and assigned a standardized identifier — most commonly a CVE (Common Vulnerabilities and Exposures) number in the format CVE-YYYY-NNNNN. The moment a flaw receives a CVE ID and appears in the NVD, it stops being a private research finding and becomes a searchable, trackable record with a description, affected products, and (usually) a CVSS severity score. Known vulnerabilities differ from vulnerability classes — like "SQL injection" or "buffer overflow" — because each CVE describes one specific flaw in one specific piece of software, such as CVE-2014-0160 (Heartbleed), a single missing bounds check in OpenSSL's heartbeat extension affecting versions 1.0.1 through 1.0.1f.
How is a known vulnerability different from a zero-day?
The difference is public disclosure status, not exploitability. A zero-day is a vulnerability that is actively being exploited or is known to attackers before a vendor has issued a patch or the flaw has been publicly cataloged — defenders have "zero days" of warning. A known vulnerability has already been disclosed, typically with a CVE ID, a public writeup, and in most cases a vendor patch. The catch is that a vulnerability can be "known" for years and still function like a zero-day for any organization that hasn't patched it: EternalBlue (CVE-2017-0144) was disclosed and patched by Microsoft in March 2017, yet it powered the WannaCry ransomware outbreak two months later in May 2017 and remained a top exploited CVE in breach reports well into the 2020s, precisely because so many systems stayed unpatched.
Who assigns and publishes known vulnerabilities?
CVE IDs are assigned by MITRE and a global network of over 300 CVE Numbering Authorities (CNAs), which include vendors like Microsoft, Google, and Red Hat, as well as coordination bodies and bug-bounty platforms. MITRE has run the CVE Program since 1999, and NIST's National Vulnerability Database ingests each CVE record and enriches it with a CVSS score, CWE (Common Weakness Enumeration) classification, and affected-product data using the CPE format. Other bodies layer additional context on top: CISA maintains the Known Exploited Vulnerabilities (KEV) catalog, which as of 2024 listed more than 1,200 CVEs confirmed to have been exploited in the wild, and federal agencies are required to remediate KEV entries on binding deadlines — often 14 to 21 days for internet-facing systems.
How many known vulnerabilities are published each year?
Disclosure volume has roughly doubled over the past decade: NVD logged around 14,700 new CVEs in 2017, and that number climbed past 29,000 in 2023, with 2024 tracking toward similarly record-setting totals. The cumulative CVE List has now grown to more than 240,000 entries since 1999. That growth outpaces most security teams' manual review capacity — a mid-sized engineering org running a handful of scanners can easily generate thousands of open CVE findings across its dependency tree, most of which are duplicates, false positives, or flaws in code paths that are never actually called. Volume alone is why "known" and "actionable" have become two very different things in vulnerability management.
What happens after a vulnerability becomes "known"?
Once disclosed, a vulnerability enters a race between defenders patching it and attackers weaponizing it. Historical data from exploit trackers shows that a meaningful share of CVEs get a public proof-of-concept or working exploit within 7 days of disclosure, and for high-profile flaws the window can be measured in hours: exploitation attempts against Log4Shell (CVE-2021-44228) were observed within 24 hours of its December 10, 2021 disclosure, and mass scanning began almost immediately after. Vendors typically ship patches alongside or shortly after disclosure, but patch availability doesn't equal patch deployment — the median time-to-remediate for critical vulnerabilities across enterprise environments is frequently measured in weeks to months, not days, which is exactly the gap that turns a "known and fixed" vulnerability into a breach headline.
Why do known vulnerabilities still get exploited years later?
They get exploited because disclosure creates a permanent, searchable attack roadmap that outlives most organizations' patch cycles. CISA's KEV catalog includes CVEs first disclosed as far back as 2010 that were still being actively exploited more than a decade later, and Verizon's Data Breach Investigations Report has repeatedly found that unpatched, previously-known vulnerabilities — not novel zero-days — account for the majority of vulnerability-based breach entry points. The Equifax breach is the canonical example: CVE-2017-5638, an Apache Struts remote code execution flaw, was disclosed and patched in March 2017, but Equifax's unpatched instance was exploited starting in May 2017, exposing data on roughly 147 million people. The vulnerability wasn't unknown to the world — it was unknown, or at least unaddressed, inside Equifax's own environment, which is where most known-vulnerability risk actually lives.
How Safeguard Helps
Knowing that a CVE exists is not the same as knowing whether it can hurt you, and that gap is where most vulnerability backlogs go to die. Safeguard's reachability analysis traces whether a vulnerable function is actually invoked by your application's code paths, so a critical CVE in an unreachable dependency doesn't consume the same triage time as one sitting directly in a request handler. Griffin AI correlates that reachability data with exploit maturity, KEV status, and your SBOM to rank known vulnerabilities by real exploitability rather than raw CVSS score. Safeguard generates and ingests SBOMs automatically across your build pipeline, so newly disclosed CVEs are matched against your actual dependency inventory the moment they're published — not weeks later during a manual audit. When a fix is available, Safeguard opens auto-fix pull requests with the minimal version bump needed to remediate, turning "known vulnerability" from a standing liability into a closed ticket.