What is a vulnerability? Types explained (CVE, CWE, CVSS)

A vulnerability is a weakness that can be used to compromise a system, application, device, identity, or business process.

The weakness may come from faulty code, an unsafe configuration, excessive access, an exposed service, or a missing security control. Attackers can use it to access data, change information, interrupt a service, or gain control of a system.

Security teams use CVE, CWE, and CVSS to describe and assess vulnerabilities. The terms are related, but they serve different purposes.

CVE identifies a specific publicly disclosed vulnerability. CWE describes the weakness type that caused it. CVSS provides a technical severity score.

Understanding the difference helps teams read vulnerability reports, communicate with developers, and decide what needs attention first.

What is a vulnerability

A cybersecurity vulnerability is a weakness in software, hardware, firmware, configuration, identity controls, or operating processes.

Some vulnerabilities are created during product design or development. Others appear when a system is installed, configured, updated, or connected to other technology.

Common examples include:

• A web application that does not validate user input

• A server running an outdated software version

• A cloud storage service open to the public

• An account with more permissions than the user needs

• A network service protected by a default password

• An API that does not check whether a user can access a requested record

• A device that no longer receives security updates

A vulnerability does not always have to be a coding error. A fully patched system may still be exposed because of weak credentials, unsafe permissions, or an incorrect setting.

Vulnerability, threat, exploit, and risk

These terms describe different parts of a security problem.

Vulnerability

A weakness that can be used to cause harm.

Threat

A person, group, event, or condition that may take advantage of a weakness.

Exploit

Code, commands, or a technique used to take advantage of a vulnerability.

Risk

The likelihood that a vulnerability will be used and the harm that could follow.

Consider an internet-facing server with an authentication flaw.

The authentication flaw is the vulnerability. An attacker is the threat. The method used to bypass authentication is the exploit. The possibility of account takeover, data theft, or service disruption forms the risk.

A vulnerability can exist without being exploited. But its risk changes when exploit code becomes available, attackers begin using it, or the affected system becomes easier to reach.

Common types of vulnerabilities

Vulnerabilities can appear across many parts of an IT environment.

Software vulnerabilities

Software vulnerabilities are defects in code or product design.

Examples include buffer overflows, injection flaws, memory safety errors, race conditions, and improper input validation.

An attacker may use these flaws to run code, read data, change files, or interrupt an application.

Configuration vulnerabilities

Configuration vulnerabilities come from unsafe or incorrect settings.

Examples include publicly accessible storage, open administrative ports, disabled encryption, default accounts, and weak logging settings.

The software may work as designed, but the way it has been configured creates exposure.

Authentication and access vulnerabilities

These weaknesses affect how users prove their identity and what they are allowed to do.

Examples include weak passwords, missing multifactor authentication, broken session controls, excessive privileges, and poor access reviews.

A valid account with unnecessary permissions can create as much risk as a software defect.

Network vulnerabilities

Network vulnerabilities include exposed services, outdated protocols, poor segmentation, unsafe remote access, and unsupported network devices.

A weak network boundary can give an attacker access to systems that were never meant to be reachable.

Cloud vulnerabilities

Cloud vulnerabilities often involve identity, permissions, storage settings, exposed credentials, or incorrect network rules.

A cloud workload may be patched but still exposed through an overly broad identity policy or a public management interface.

Application and API vulnerabilities

Applications and APIs can contain broken access controls, unsafe input handling, weak authentication, insecure dependencies, and missing rate limits.

These weaknesses may allow attackers to view another user’s data, perform unauthorized actions, or send commands to connected systems.

Process vulnerabilities

Security failures can also come from weak operating processes.

Examples include delayed patching, incomplete offboarding, poor change control, missing asset ownership, and unreviewed exceptions.

A process weakness may leave a known technical problem open for far longer than expected.

What is a CVE

CVE stands for Common Vulnerabilities and Exposures.

The CVE Program identifies, defines, and catalogs publicly disclosed cybersecurity vulnerabilities. Each cataloged vulnerability receives a CVE Record so vendors, researchers, security teams, and tools can refer to the same issue using a shared identifier.

A CVE identifier follows a standard format.

CVE-2026-12345

The first part shows that the record belongs to the CVE system. The year usually relates to when the identifier was assigned. The final number identifies the individual record.

A CVE Record may contain:

• The CVE identifier

• A short description

• The affected product or component

• References to vendor advisories or research

• Weakness information

• Severity data when available

A CVE does not provide a complete risk decision.

It does not tell a company whether the affected product is present, whether the system is reachable, whether an attacker is using the flaw, or what business process depends on the asset.

Not every security weakness receives a CVE. Internal coding defects, unsafe configurations, excessive permissions, and process failures may not appear in the public CVE catalog.

What is a CWE

CWE stands for Common Weakness Enumeration.

CWE is a community-developed list of software and hardware weakness types that can lead to vulnerabilities. Its purpose is to describe the underlying coding, design, or architecture problem rather than one specific product flaw.

Examples include:

• CWE-79 for improper neutralization of input during web page generation

• CWE-89 for improper neutralization of special elements used in an SQL command

• CWE-787 for out-of-bounds write

• CWE-22 for improper limitation of a pathname to a restricted directory

One CWE can be linked to many CVEs.

For example, separate products may each contain their own SQL injection vulnerability. Each product flaw may receive a different CVE identifier, but the records may point to the same CWE category.

CVE answers which specific vulnerability is being discussed.

CWE answers what type of weakness caused it.

CWE data can help development teams find recurring coding problems, improve testing rules, review architecture, and reduce repeated defects. The 2025 CWE Top 25 from CISA and MITRE groups commonly exploited weakness categories to help development, security, and procurement teams focus on recurring causes of software vulnerabilities.

What is CVSS

CVSS stands for Common Vulnerability Scoring System.

CVSS is an open framework used to describe the technical characteristics and severity of software, hardware, and firmware vulnerabilities.

A CVSS score ranges from 0.0 to 10.0. A higher score represents greater technical severity under the conditions used to calculate it.

CVSS version 4.0 uses four metric groups:

• Base

• Threat

• Environmental

• Supplemental

Base metrics describe characteristics that remain largely constant, such as how an attack can be performed and what technical impact may follow.

Threat metrics account for conditions that can change over time, such as the availability of exploit activity.

Environmental metrics allow an organization to adjust the assessment for its own systems, controls, and business requirements.

Supplemental metrics provide more context but do not change the final score. FIRST states that the score should be published with its vector string so readers can see how it was calculated.

A CVSS score is not a complete risk score.

Two companies can have the same CVE with the same base score but face very different risk. One may run the affected software on an isolated test device. The other may run it on an internet-facing server that processes customer records.

How CVE, CWE, and CVSS work together

The three systems answer different questions.

Consider a web application with an SQL injection flaw.

The specific flaw in the product may receive a CVE identifier.

The record may map to CWE-89 because the application handles SQL input incorrectly.

A CVSS score may then describe how the flaw can be exploited and the potential technical impact.

Together, the records give teams a shared reference, a weakness category, and a severity assessment.

They still do not answer every prioritization question.

Why CVSS alone is not enough

CVSS helps security teams compare technical severity. It should not be the only reason for choosing what to fix first.

Prioritization should consider:

• Whether attackers are using the vulnerability

• Whether exploit code is publicly available

• Whether the affected system is internet-facing

• Whether the vulnerable function can be reached

• What privileges an attacker needs

• What data or service the asset supports

• Whether security controls can block the attack

• How difficult the change will be

• What could happen if the system becomes unavailable

A high-scoring flaw on an isolated device may present less immediate risk than a lower-scoring flaw under active exploitation on a public server.

CVSS version 4.0 includes Threat and Environmental metrics that can add context. But organizations still need current asset, exposure, exploit, and business data to set remediation order.

How security teams manage vulnerabilities

Vulnerability management usually follows a repeatable process.

Identify affected assets

Teams need a current record of endpoints, servers, applications, cloud workloads, network devices, and software.

Detect weaknesses

Scanners, application testing, configuration checks, vendor advisories, and security research can identify possible vulnerabilities.

Validate the finding

Validation confirms that the affected product, version, configuration, or code path exists in the organization.

Assess exposure and impact

Teams review reachability, exploitation, asset purpose, permissions, data sensitivity, and existing controls.

Set the remediation order

Findings receive an action order based on actual exposure rather than score alone.

Apply the corrective action

The response may involve patching, changing a configuration, updating code, removing access, isolating a service, or retiring an asset.

Verify the result

A rescan, version check, configuration check, or code test should confirm that the weakness is no longer present.

Common mistakes when reading vulnerability data

Treating every CVE as equally urgent

A CVE identifier names a flaw. It does not state how much risk the flaw creates for every company.

Treating CVSS as business risk

CVSS measures technical severity. It does not know the role of the affected asset or the cost of disruption.

Ignoring weaknesses without CVE identifiers

Misconfigurations, excessive permissions, weak identity controls, and internal defects may create serious exposure without a public record.

Closing tickets without verification

A patch command or closed ticket does not prove that every affected system received the fix.

Missing assets outside the inventory

A vulnerability program cannot assess devices, applications, or cloud resources it does not know exist.

Focusing only on software defects

Identity, configuration, access, and process weaknesses can create direct attack paths even when software is current.

How CVEM adds context to vulnerability management

Continuous vulnerability and exposure management connects vulnerability findings with current asset and business context.

A CVEM process tracks what assets exist, what weaknesses affect them, which assets are reachable, what attackers are using, and which business services may be affected.

The process then connects prioritization with remediation and follow-up checks.

Saner CVEM combines asset visibility, vulnerability assessment, posture anomaly detection, contextual risk prioritization, patching, configuration action, and endpoint management in one operating flow. That approach helps security and IT teams move from finding a weakness to acting on the exposure without treating CVE data or CVSS scores as the full decision.

CVE, CWE, and CVSS answer different questions

A vulnerability is a weakness that can be used to compromise a system, service, identity, or process.

CVE identifies a specific publicly disclosed flaw.

CWE describes the weakness type behind one or more flaws.

CVSS describes technical severity.

Security teams need all three, but none is enough on its own. Current asset data, exploit activity, reachability, business impact, ownership, and verification determine what should be fixed first and whether the work reduced exposure.