What Is a Vulnerability in Cybersecurity?

A vulnerability is a defect in a system, its controls, or its procedures that allows the protection it was designed to provide to be bypassed. Deliberate exploitation and accidental triggering both count, which is why FIPS 200 describes a vulnerability as one that could be "exploited or triggered by a threat source," and defines a threat source to include a situation that sets one off by accident. Definitions built only around attackers leave that second case out.

In ordinary use, and in fields such as psychology and disaster planning, vulnerability describes a general susceptibility to harm. Security uses it for an identified defect in an identified system.

Vulnerability, Weakness, Threat, and Exploit

These four terms are routinely used interchangeably. NIST treats weakness as the parent term for vulnerability, while the CVE and CWE programs draw a sharper line between them.

Risk is what these four produce in combination with context: a severe vulnerability in a system that holds nothing valuable and faces no capable threat carries less risk than a moderate one on an internet-facing service holding customer records. 

How Vulnerabilities Are Identified and Scored

A vulnerability becomes trackable when it receives a CVE identifier, published as a record by a CVE Numbering Authority. The National Vulnerability Database then enriches many of those records with a CWE mapping that names the underlying weakness class and a CVSS score that rates severity.

CVSS measures how damaging exploitation would be, using metrics such as attack vector, attack complexity, required privileges, and impact on confidentiality, integrity, and availability. The base score is silent on how likely exploitation is. Optional threat metrics address exploit maturity, but they are rarely populated in public records.

Not every vulnerability gets an identifier. Flaws in internal code, misconfigurations, and defects found in a penetration test are real vulnerabilities that will never appear in any public database.

What Causes Vulnerabilities in Applications

Most application vulnerabilities fall into a few recurring categories: input that reaches an interpreter without neutralization, authorization checks that are missing or applied inconsistently, unsafe handling of memory, deserialization of data an attacker controls, secrets committed into code or configuration, and defaults left in place that were never meant for production.

Inherited code contributes a large share. An application assembles dozens or hundreds of third-party packages, and a defect in any of them becomes a defect in the application that ships it. Application security vulnerabilities cover these categories in more depth.

How Vulnerabilities Are Found

Automated vulnerability scanning compares what is installed against databases of published advisories, which makes it fast, repeatable, and limited to defects someone has already documented.

Static analysis examines source code for weakness patterns before the code runs. Dynamic testing probes a running application from the outside. Penetration testing and bug bounty programs apply human judgment to find logic flaws that no pattern matches. Coordinated disclosure brings in findings from outside researchers.

Each method finds a different subset, and none of them finds everything.

Is Every Vulnerability Exploitable?

No. A vulnerability has to be both reachable and usable before it poses a risk to a particular system.

A vulnerability may be unexploitable in a given deployment because the affected function is never called, because a compensating control blocks the path, or because the vulnerable configuration is not in use. Absence of a working public exploit is a separate condition: it makes a vulnerability currently unexploited rather than unexploitable, and it can change overnight.

Three signals help separate the set that matters:

• CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with confirmed exploitation in the wild. It is evidence rather than prediction, and it covers a small fraction of published CVEs.
• EPSS, maintained by FIRST, publishes a probability that a given CVE will be exploited within the next thirty days. Scores are recalculated daily, so one can climb sharply once exploit code appears.
• Reachability answers the question specific to your application: whether the vulnerable code is loaded and executed at all. A CVE in a package that ships in an image but is never called cannot be reached through that application's normal execution path, though a component present on disk can still be useful to an attacker who has already gained execution by other means.

Severity, probability, and reachability are three separate measurements. A queue sorted on severity alone puts unreachable critical findings above exploitable moderate ones.

Ranking decides what gets fixed first. It does nothing for the findings still sitting in the queue, and nothing at all for a flaw that has no advisory yet. Raven Runtime Prevention works at execution instead, blocking exploitation whether or not the underlying vulnerability has been scored, prioritized, or discovered. See how it works at Runtime Prevention.