What Is a Vulnerability?

Security teams spend most of their time on vulnerabilities: finding them, scoring them, and getting them fixed. But the word gets used loosely. It can mean a CVE, a scanner finding, a misconfigured setting, or something an attacker is actively using. Here’s what a vulnerability actually is, how it differs from related terms, and how vulnerabilities are identified and scored.

What Is a Vulnerability?

A vulnerability is a weakness in software, hardware, configuration or process that an attacker can use to do something they shouldn’t be able to. That could mean gaining unauthorized access, stealing or changing data, running malicious code, or taking a system offline. In other words, a vulnerability puts the confidentiality, integrity or availability of a system at risk.

Vulnerabilities live inside your environment. That’s what separates them from threats, which are the attackers and techniques outside it. For more on how the two combine to create risk, see our breakdown of threat vs vulnerability.

Vulnerability vs. Exploit vs. Exposure

Three terms often get blurred together:

• Vulnerability: The weakness itself, such as an outdated library or a storage bucket left open to the public.
• Exploit: The code or technique used to take advantage of that weakness. Some vulnerabilities have working public exploits within days of disclosure. Many never get one.
• Exposure: Whether an attacker can actually reach the vulnerability in your environment. A vulnerable component that’s never loaded at runtime, or that sits behind network segmentation, has little exposure.

The distinction matters because scanners report vulnerabilities, but attackers need both an exploit and a path in. The gap between a vulnerability existing and an attacker being able to use it is what exploitability describes.

Common Types of Vulnerabilities

Vulnerabilities show up across every layer of an organization. The main categories are:

• Software and code flaws: Injection bugs, memory errors and broken access control. The most serious let an attacker run their own code on a system, known as a remote code execution vulnerability.
• Open-source and third-party dependencies: Flaws inherited from libraries and components your team didn’t write.
• Misconfigurations: Open ports, public cloud storage and overly permissive roles.
• Weak authentication: Reused passwords, missing MFA and stale access keys.
• Hardware and firmware: Flaws in chips, devices and the low-level code that runs them.
• Process gaps: No offboarding process, no asset inventory, or no clear owner for fixes.

We go deeper into each category in our guide to types of vulnerabilities.

Real-World Examples of Vulnerabilities

Log4Shell (CVE-2021-44228). Disclosed in December 2021, this flaw in the Apache Log4j 2 logging library let attackers trigger code execution just by getting an application to log a specially crafted string. It received the maximum CVSS score of 10.0. Because Log4j was embedded in so many applications, many organizations were affected without knowing they used it.

EternalBlue (CVE-2017-0144). This flaw in Microsoft’s SMBv1 protocol was patched in March 2017. Two months later, the WannaCry ransomware used it to spread across systems that hadn’t applied the update. The lesson is that a patch being available doesn’t mean a vulnerability is fixed.

Public cloud storage. A storage bucket set to public access has no CVE and no patch. It’s a single setting, and it’s one of the most common causes of data exposure in the cloud.

How Vulnerabilities Are Identified and Scored

Publicly known vulnerabilities receive a CVE (Common Vulnerabilities and Exposures) ID, assigned by CVE Numbering Authorities under the CVE Program. The National Vulnerability Database (NVD), run by NIST, adds details such as affected products and severity scores. Organizations then find which CVEs exist in their own environment through vulnerability scans.

Three signals are commonly used to judge how serious a vulnerability is:

• CVSS rates theoretical severity on a scale of 0 to 10.
• EPSS estimates the probability that a vulnerability will be exploited in the next 30 days.
• The CISA Known Exploited Vulnerabilities Catalog lists vulnerabilities with confirmed exploitation in the wild.

None of these can see your environment. A 9.8 on an isolated internal test server may matter less than a 6.5 on an internet-facing system attackers are actively targeting. That’s why effective vulnerability prioritization weighs exploitation, reachability and business context alongside the score.

How Seemplicity Fits In

Seemplicity isn’t a scanner. It pulls findings from the security tools you already use and consolidates duplicates of the same vulnerability across tools and assets. Each finding is enriched with context such as known exploitation, reachability and asset criticality, so teams can see which vulnerabilities pose real risk. From there, Seemplicity routes each fix to the right owner and tracks it through to closure.

Finding Vulnerabilities Is Only Half the Job

A vulnerability is a weakness an attacker can use. Whether it matters depends on whether it’s exploitable, reachable and important to the business. Identifying and scoring vulnerabilities tells you where the risk is. The risk only drops when the weakness is gone, whether it’s patched, reconfigured or removed. Where a fix can’t ship yet, compensating controls can reduce the risk in the meantime. That final step, vulnerability remediation, is where vulnerabilities actually get closed.