These terms describe different parts of the same security story.
A vulnerability is a weakness. A threat is a circumstance or event that could cause harm. An exploit is a technique or code that takes advantage of a vulnerability. Risk expresses the organization's exposure to potential harm, commonly considering likelihood and impact.
Fast chain: Threat source or event → targets a vulnerability → may use an exploit → creates a threat event → produces risk based on likelihood and impact → controls reduce likelihood, impact, or both.
1. The chain at a glance
Consider an internet-facing server that has not been patched.
| Part of the story | Example |
|---|---|
| Asset | Public web server |
| Vulnerability | Known remotely exploitable software flaw |
| Threat source | Attacker scanning the internet |
| Exploit | Code or technique that triggers the flaw |
| Threat event | Remote compromise attempt |
| Impact | Data exposure and service disruption |
| Risk | The organization's exposure based on likelihood and impact |
| Mitigation | Patch, isolate, restrict access, monitor, or apply compensating controls |
The terms are connected, but they are not interchangeable.
2. Vulnerability
A vulnerability is a weakness that could be exploited or triggered by a threat source.
Examples include:
- unpatched software
- weak default credentials
- excessive permissions
- insecure configuration
- missing input validation
- exposed management interface
- poor physical access control
A vulnerability can exist before anyone actively attacks it.
Vulnerability is not the attacker
If a scenario says:
“A server is running a version with a known remote-code-execution flaw.”
The flaw is the vulnerability.
The attacker is the threat source.
The code that takes advantage of the flaw is the exploit.
3. Threat and threat source
A threat is a circumstance or event with the potential to cause adverse impact.
A threat source or threat agent is the origin of the action or condition that may exploit or trigger a vulnerability.
Threat sources are not limited to malicious hackers. They can include:
- criminal groups
- insiders
- nation-state actors
- accidents
- human error
- hardware failure
- fire, flood, or other environmental events
That matters because a vulnerability can be triggered intentionally or accidentally.
Threat vs. threat source
Security+ wording may distinguish:
- Threat: the harmful circumstance/event
- Threat source: the actor, condition, or origin capable of causing it
For example:
A disgruntled administrator intentionally deletes production data.
The administrator is the threat source. The destructive action is the threat event.
4. Exploit
An exploit is the method, technique, or code used to take advantage of a vulnerability.
Examples:
- crafted network request that triggers a memory corruption flaw
- malicious input that abuses an injection vulnerability
- code that leverages a privilege-escalation bug
- technique that bypasses an insecure access-control check
The exploit is not the vulnerability itself.
A vulnerability can exist even when no working public exploit is available. Conversely, publication of reliable exploit code can change the practical likelihood of attack and therefore affect risk.
Exploit vs. payload
In attack discussions, an exploit may create the initial condition that lets the attacker execute something else.
The exploit takes advantage of the weakness.
A payload is what runs or happens after successful exploitation, such as installing malware or opening a remote shell.
5. Risk
Risk is about the potential harm to the organization.
NIST commonly frames information-security risk as a function of:
- likelihood
- impact
A severe technical vulnerability does not automatically create the same risk in every environment.
Compare:
System A
- vulnerable service exposed directly to the internet
- sensitive customer data
- active exploitation observed
- no compensating control
System B
- same vulnerable software
- isolated lab network
- no sensitive data
- access restricted
- scheduled for replacement tomorrow
The vulnerability may be technically identical. The risk is not.
Risk is contextual
Risk decisions consider factors such as:
- asset value and business importance
- exposure
- threat likelihood
- potential impact
- existing controls
- detectability and recovery capability
- legal, safety, contractual, and operational consequences
That is why vulnerability severity and business risk are related but not identical.
6. Where controls fit
Controls reduce risk by changing the story.
A control might:
- remove the vulnerability
- reduce exposure to a threat source
- make exploitation more difficult
- detect a threat event sooner
- limit the impact
- improve recovery
For example, if an emergency patch cannot be installed immediately, an organization might isolate the system and restrict inbound traffic as compensating controls.
The vulnerability still exists, but the likelihood or impact of successful exploitation may be reduced.
For control categories and functions, use the Security Controls Quick Reference.
7. Scenario comparisons
Scenario 1: Old web framework
A website uses a framework with a known injection flaw.
- Vulnerability: injection flaw
- Threat source: attacker
- Exploit: malicious request crafted to trigger the flaw
- Risk: likelihood and impact of successful compromise in this environment
- Mitigation: patch/update, validation controls, filtering, segmentation, monitoring
Scenario 2: Weak door lock
A server room uses an easily bypassed lock.
- Vulnerability: weak physical access control
- Threat source: unauthorized person
- Exploit/technique: bypassing or defeating the lock
- Risk: likelihood and impact of unauthorized physical access
- Mitigation: stronger lock, badge access, guards, cameras, alarms
Scenario 3: Flood-prone facility
A critical server room is below flood level.
- Vulnerability: facility placement and insufficient flood protection
- Threat source/event: flooding
- Exploit: there may be no attacker or exploit code at all
- Risk: likelihood and business impact of the flood affecting systems
- Mitigation: relocation, barriers, redundancy, recovery planning
This is a useful reminder that not every security risk involves an attacker.
8. Common exam traps
Trap: calling malware a vulnerability
Malware is generally a threat mechanism or malicious tool. The vulnerability is the weakness it exploits or the condition that lets it succeed.
Trap: equating CVSS score with business risk
A vulnerability score can help describe technical severity. Organizational risk still depends on context, exposure, controls, likelihood, and impact.
Trap: assuming there must be exploit code
Natural disasters, hardware failures, mistakes, and other threat events can trigger weaknesses without malicious exploit code.
Trap: using “threat” and “threat actor” as exact synonyms
A threat actor is a type of threat source. The threat is the potential harmful circumstance or event.
Trap: treating mitigation as proof the vulnerability disappeared
Segmentation or filtering may reduce risk while the underlying vulnerability remains. Patching or removing the vulnerable component may eliminate the weakness itself.
9. Rapid review grid
| Question asks about... | Think |
|---|---|
| A weakness | Vulnerability |
| A person/group/condition that could cause harm | Threat source |
| A harmful circumstance or event | Threat |
| Code or technique that takes advantage of a weakness | Exploit |
| Likelihood and impact of harm to the organization | Risk |
| Technical vulnerability severity | Useful input, but not identical to business risk |
| Reducing likelihood or impact | Risk mitigation/control |
| Fixing the underlying flaw | Remediation of the vulnerability |