The short answer: a vulnerability is a weakness in a system, an exploit is the technique or code that takes advantage of that weakness, and a threat is the actor or event that might do so. A weakness with no attacker and no working exploit is a very different problem than one being actively attacked in the wild.
These three words get used interchangeably in headlines and hallway conversations, which is a shame because the distinction is exactly what lets you prioritize sensibly. You cannot fix everything at once. Knowing whether you are dealing with a theoretical weakness, a working attack tool, or a motivated adversary is the difference between calm patching and a fire drill.
What Is a Vulnerability?
A vulnerability is a flaw or weakness that could be used to compromise a system. It might be a coding bug like a buffer overflow, a misconfiguration like an open storage bucket, or a design flaw like a missing authorization check. Vulnerabilities are catalogued publicly with CVE identifiers and scored for severity with systems like CVSS.
Crucially, a vulnerability is a potential. It describes what could go wrong. A library in your app might have a known critical CVE, but if the vulnerable function is never called by your code, the practical danger is much lower than the score suggests. This is why modern tools layer reachability analysis on top of raw vulnerability data.
What Is an Exploit?
An exploit is the concrete means of abusing a vulnerability. It can be a piece of code, a sequence of steps, or a crafted input that turns the theoretical weakness into a real compromise. Exploits range from proof-of-concept snippets that merely demonstrate the flaw to weaponized, reliable tools packaged for use at scale.
The existence of a working exploit dramatically changes the urgency of a vulnerability. A weakness with no known exploit is a locked door no one has found the key to yet. A weakness with a public, reliable exploit is a door with the key hanging next to it. Catalogs like CISA's Known Exploited Vulnerabilities (KEV) exist precisely to flag which vulnerabilities have crossed this line.
What Is a Threat?
A threat is the source of potential harm: the actor, group, or circumstance that might act against you. Threats include cybercriminals, nation-state groups, malicious insiders, and even non-human events like a hardware failure. A threat has intent (or at least the capacity) to cause damage; a vulnerability is just the opening they might use.
Threat modeling asks who would want to attack you, what they want, and how they might get it. A vulnerability only becomes dangerous when a threat with the motivation and capability to exploit it exists.
Side-by-Side Comparison
| Aspect | Vulnerability | Exploit | Threat |
|---|---|---|---|
| Plain definition | A weakness | The means of abusing it | The actor or event that might |
| Part of speech | A condition | A tool or technique | An agent or circumstance |
| Example | Unpatched CVE in a library | Public proof-of-concept code | A ransomware group |
| Exists without the others? | Yes, on its own | Only if a vulnerability exists | Yes, always looking |
| How it's tracked | CVE, CVSS, advisories | KEV lists, exploit databases | Threat intelligence feeds |
| You reduce it by | Patching, config hardening | Mitigations, virtual patching | Deterrence, detection, response |
When to Care About Each
Care about vulnerabilities during routine hygiene: scanning your code and dependencies, patching, and hardening configurations. This is the steady, unglamorous work that shrinks your attack surface over time.
Care about exploits when triaging. If a vulnerability you have is being actively exploited in the wild, it jumps the queue regardless of its CVSS score. Exploit availability is often the single strongest signal for what to fix first.
Care about threats when setting strategy. Understanding who is likely to target your industry, and what they are after, shapes where you invest. A payment processor and a hobby blog have the same CVEs available to them but wildly different threat landscapes.
How They Fit Together
Risk is the product of all three. The rough mental model security teams use is: Risk = Threat × Vulnerability × Impact. A vulnerability with no threat actor interested in it and no working exploit is low risk even if its CVSS score is high. A medium-severity vulnerability that a known threat group is actively exploiting against companies like yours is an emergency.
This is why mature programs do not patch strictly by CVSS score. They combine the vulnerability (what's weak), the exploit (is it being abused, and how easily), and the threat (who wants to hurt us) into a single prioritized picture. The three concepts are not competitors; they are three axes of the same risk calculation.
Frequently Asked Questions
Can you have a vulnerability without an exploit?
Yes, and it is common. Many disclosed vulnerabilities never get a public, reliable exploit written for them. That does not mean they are safe forever, but it does mean their immediate risk is lower than one with weaponized exploit code circulating.
Is every threat trying to use a vulnerability?
Not necessarily. Some threats rely on stolen credentials, social engineering, or insider access rather than a technical flaw. A vulnerability is one path a threat might take, but threats are opportunistic and will use whatever works.
Which matters most for prioritizing patches?
Exploit status is usually the sharpest signal. A vulnerability that is actively exploited, especially one on a KEV list, should be fixed ahead of higher-scored vulnerabilities that no one has figured out how to abuse. Combine that with how reachable the flaw is in your specific application.
How does reachability change this?
Reachability tells you whether your code actually uses the vulnerable part of a component. A critical vulnerability in code paths your application never executes is a far smaller real-world risk. It effectively lowers the "vulnerability" term in the risk equation by showing the weakness is not exposed in your context.
Want to move from raw CVE lists to real prioritization? Safeguard's SCA product layers exploit and reachability signals onto your findings so the urgent work rises to the top, and Griffin AI helps reason about which threats actually apply to you. Browse related ideas in our concepts library or start from the basics at the Safeguard Academy.