What Is a Vulnerability? Weakness, Threat, Risk and Exploit

Most security confusion starts with four words that people use as if they meant the same thing: vulnerability, threat, risk and exploit. A news story says "a critical vulnerability was exploited," and the reader hears one event. In practice these are four different things. Keeping them apart tells you what to fix first, what to watch and what can wait.

This article gives you working definitions, shows how the four connect in one chain, and then explains two naming systems you will meet everywhere. CWE names types of weakness. CVE names specific flaws in specific products. The last sections cover two claims that surprise beginners: a vulnerability with no reachable path is usually low risk, and a wrong setting counts as a vulnerability even though nobody wrote a bug.

You do not need a lab for this one. The hands-on part is a paper exercise. If you read the CIA triad article first, the impact step below will feel familiar.

#Four words, four jobs

Start with the official definition. The NIST Computer Security Resource Center glossary defines a vulnerability as a weakness in an information system, its security procedures, its internal controls or its implementation, that could be exploited or triggered by a threat source. The word that matters is "weakness." A vulnerability is a property of a system. It exists whether or not anyone is looking for it.

#Vulnerability

A vulnerability is a weakness that could be used to cause harm. Some examples:

• A web form that pastes user input straight into a database query. The weakness type is well known, and CWE has an entry for it (more on that below).
• A file server that still accepts an old, weak encryption protocol.
• A storage bucket that lets anyone list its contents.
• A software library version with a publicly documented memory corruption bug.

A vulnerability does not need an attacker to exist. It needs to exist in the system, and that is the first thing to check when you assess something.

#Threat

A threat is a circumstance, an actor or an event that could take advantage of a weakness and cause harm. NIST uses the term "threat source" for the party or the event: a criminal group, a malicious insider, a flood, or an administrator who makes a mistake in a configuration file.

The difference from a vulnerability is direction. A vulnerability describes what could be acted on. A threat describes what could act. A threat is potential. It does not have to be active against you right now for it to matter.

#Risk

Risk combines how likely a harmful event is with how bad it would be. NIST SP 800-30 Revision 1, the guide for risk assessment, treats risk as a function of likelihood and impact. In plain terms, risk is how likely something is to happen, weighed against the damage if it does. It is a judgment, not a precise calculation.

Many teams draw a matrix with likelihood on one axis and impact on the other. The matrix is a thinking aid. It is not a measurement. Two findings with the same severity score can carry very different risk, because the score describes the flaw and the risk describes your environment.

#Exploit

An exploit is a method, a piece of code or a sequence of steps that uses a vulnerability to produce a result its designers did not intend. The word can mean the technique itself or the tool that performs it.

Two relationships are worth remembering. First, an exploit needs a vulnerability to work against. Second, a vulnerability does not need a public exploit to exist. Many vulnerabilities are known and never have a public exploit. Others are triggered by a simple input that anyone can try.

#How the four connect

These four words describe one chain. Here it is in order, using a generic login form as the example:

1. Weakness. The login form accepts unlimited password guesses. There is no lockout and no rate limit. That is the vulnerability.
2. Threat source. Someone holds a list of passwords from an older data breach and reuses them against many accounts. That is the threat.
3. Exploit. A short script submits thousands of login attempts and records the ones that succeed. That script is the exploit.
4. Impact. A matching account is taken over. The attacker reads that user's data, which is a confidentiality loss, and may change settings, which is an integrity loss.
5. Risk. How much this matters depends on two things: how likely steps 2 and 3 are in your setting, and how bad step 4 would be for the accounts involved. Is the form reachable from the internet? Do the accounts use multi-factor authentication? What can each account reach?

You can break the chain at several points. A rate limit removes the weakness. Multi-factor authentication makes a successful guess much less useful. Restricting the form to a private network lowers the threat's reach. Each control breaks a different link, so you need to know which link you are working on.

#How CWE and CVE name flaws

You will see two identifiers constantly in security news, advisories and scanner reports. They answer different questions, and mixing them up is one of the most common beginner errors.

#CWE: the type of weakness

The CWE website describes CWE as a community-developed list of common software and hardware weaknesses. It defines a weakness as a condition in a software, firmware, hardware or service component that, under certain conditions, could contribute to the introduction of vulnerabilities. CWE answers the question: what kind of mistake is this?

Each CWE entry has a number. The entry for SQL injection is CWE-89, which covers improper neutralization of special elements in an SQL command. The entry for cross-site scripting is CWE-79. These entries do not name any product. They describe a pattern that appears in many products, and they help developers recognize the pattern before it ships.

#CVE: the specific flaw

CVE is a list of publicly disclosed cybersecurity vulnerabilities. Each record describes one flaw in one product, usually with the affected versions and links to advisories. The identifier has this shape:

CVE-YEAR-NUMBER

A real example is CVE-2021-44228, the flaw in Apache Log4j 2 that became known as Log4Shell. The ID tells you which flaw it is. The record tells you which product and versions are affected and where to find the vendor's fix.

CVE answers a different question: which specific flaw, in which product, is this? A single CWE type can have many CVE records across different products, because the same kind of mistake gets made again and again.

#Reading the two together

When you read a CVE record, look for the weakness type it maps to. A record that maps to CWE-89 tells you the flaw is an SQL injection, even if the product is unfamiliar. That lets you apply what you know about the category to a new case. The reverse helps too: if a product has a history of one weakness type, you know what to check first.

#Why a vulnerability with no reachable path is usually low risk

Suppose a service has a known flaw, but it listens only on the loopback address of your laptop. No other machine can connect to it. Is that a vulnerability? Yes. Is the risk high? Usually not, because the likelihood is very low. Nobody outside your laptop can reach the flaw, so no threat source can use it through the network.

This is the risk idea at work. Lower likelihood gives lower risk, even when the impact would be severe. Severity alone does not decide what to fix first.

Be careful, though. "No reachable path today" is a claim about one moment. Some things change the picture:

• A network change, such as a new port forward, a cloud security group rule or a VPN route, can make a service reachable.
• A compromised machine on the same network can reach services that are invisible from outside.
• An employee who is tricked by a phishing message can become a path into an internal system.
• The application itself may expose the service through another route, such as a proxy or a redirect.

So low risk does not mean zero risk, and it does not mean ignore the flaw. The fix can usually wait behind findings that have reachable paths, and you should recheck reachability whenever the network changes.

#Why misconfiguration counts as a vulnerability

Many beginners assume a vulnerability must be a bug in code. That is too narrow. The NIST glossary definition includes the system's "implementation" and "internal controls," and CWE covers configuration weaknesses too. A setting that exposes data or access is a weakness, even if no line of code is wrong.

Here is a simple example. This nginx block turns on directory listing for a path:

location /backup/ {
    autoindex on;
}

No code is broken. Nginx does exactly what this line says. But anyone who can reach the path can see a list of files in that folder, and some of those files may be backups that were never meant to be public. The weakness lives in the configuration, and someone can use it to learn things they should not know.

Other common misconfigurations follow the same logic:

• A cloud storage bucket set to public read when it should be private.
• A default administrator password that was never changed.
• Debug mode left on in a production application, which can show stack traces to visitors.
• An admin interface exposed to the public internet instead of a private network.

Check your own systems this way. For any setting that controls who can see or change something, ask whether a stranger could use it. If yes, you have a vulnerability, whether a developer wrote it or an administrator chose it.

#Hands-on: classify five findings on paper

No lab is needed. Take a sheet of paper or a text file and work through five cases. For each one, write four short answers: the weakness, the likely threat source, whether an exploit is needed to use it, and whether it is reachable from the internet or only from inside a network.

1. A web application runs a library version with a publicly documented flaw. The application is reachable from the internet.
2. A directory listing is enabled on a backup path. The server is reachable only from the office network.
3. A service with a known flaw listens only on the loopback address of a laptop.
4. A login form has no rate limit, but every account requires a second factor.
5. A cloud storage bucket is set to public read, and it is currently empty.

For each case, write one sentence that starts with "The risk is" and gives the reason. Compare your answers with the reasoning above. Cases 1 and 4 have the most useful risk sentences, because reachability and the second factor change how likely the harm is. Case 5 is a misconfiguration that is still a vulnerability, even with nothing stored in the bucket today, since data can arrive tomorrow.

Keep the answers. When you read a real advisory later, you can apply the same four questions.

#Common mistakes

• Using vulnerability and exploit as synonyms. A vulnerability is the weakness. The exploit is the method that uses it.
• Treating a scanner's severity score as your risk. The score describes the flaw in general. Your risk depends on reachability, your data and your controls.
• Ignoring misconfigurations because there is no code bug. Settings can be vulnerabilities too.
• Assuming "no known exploit" means safe. It means no public exploit is known today. It says nothing about whether a private one exists.
• Assuming unreachable means unreachable forever. Network changes and compromised machines can change the path.
• Confusing a CVE ID with a weakness type. The CVE names one flaw in one product. The CWE names the category of mistake.

#How to go further

Read the NIST glossary entry for vulnerability and the risk assessment sections of NIST SP 800-30 Revision 1. Then open any CVE record that interests you and find three things: the affected product and versions, the description of the flaw, and the CWE mapping, if one is listed. This habit turns a list of identifiers into a clear picture, and it is the core skill for reading advisories.

Once the four words feel settled, the next question is how a weakness could be reached on purpose. The article on threat modeling with STRIDE shows a structured way to list threats against a system before anyone attacks it. It uses the same vocabulary you just learned, so the distinctions above will matter there.

When you read CVE records regularly, you will notice that the description often names the condition needed to trigger the flaw. That condition is your first check for reachability. Write it down next to the affected version and your own exposure.

#Sources

• NIST CSRC glossary: vulnerability
• CWE: About CWE
• CVE: Overview
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments