What Are Vulnerabilities?

A vulnerability is a weakness in software, hardware, configuration, identity control, or process that an attacker may use to compromise a system. Some vulnerabilities begin as coding mistakes. Others come from unsafe settings, outdated components, weak authentication, missing patches, exposed services, or access rights that are broader than they should be.

A bug is not always a vulnerability. A bug may cause a feature to fail, slow down an application, or create poor user experience. A bug becomes a vulnerability when it creates a security weakness that can be used to read data, change data, bypass access controls, disrupt services, or move deeper into an environment.

The CVE Program describes its role as identifying, defining, and cataloging publicly disclosed cybersecurity vulnerabilities. Its 2025 CNA Rules state that CVE IDs and CVE Records help different parties refer to the same publicly disclosed vulnerability with confidence.

How Vulnerabilities Form

Vulnerabilities can appear at many stages of technology development and operation. A developer may write code that does not validate input correctly. A system administrator may leave a default password unchanged. A cloud team may publish storage data by mistake. A vendor may ship software with an authentication flaw. A container image may include an outdated package.

Security weaknesses also appear after deployment. A safe configuration can drift over time. A service can become exposed after a firewall rule change. A once-current application can become risky when a new flaw is disclosed. A user account can gain unnecessary permissions during troubleshooting and retain them long after the work is finished.

A vulnerability matters because it gives an attacker a possible path. That path may lead to data theft, privilege escalation, service disruption, malware deployment, lateral movement, or unauthorized access.

Vulnerabilities and CVEs

A CVE is a public identifier assigned to a publicly disclosed cybersecurity vulnerability. It gives vendors, security teams, researchers, and tools a shared name for the same issue.

CVE IDs are not assigned only by MITRE. The CVE Program works through CVE Numbering Authorities, known as CNAs, which are authorized organizations that assign CVE IDs and publish CVE Records. The 2025 CVE CNA Rules define CNAs as organizations authorized to assign CVE IDs and publish CVE Records, usually as part of public vulnerability disclosure.

A CVE record often includes a description, affected products, references, and other metadata. Security tools use these records to match known vulnerabilities against assets in an environment.

CVE data helps teams speak the same language, but it does not answer every risk question on its own. A vulnerability may have a high severity score, yet pose less danger in one environment if the affected system is isolated. A medium-severity vulnerability may pose more danger if it affects an internet-facing system with sensitive data.

How CVSS Helps Measure Severity

The Common Vulnerability Scoring System, or CVSS, gives security teams a common way to describe the technical severity of vulnerabilities. The National Vulnerability Database supports CVSS v3.x and v4.0, and it describes CVSS as a factor used for severity calculation and remediation prioritization.

CVSS scores usually range from 0.0 to 10.0. A higher score signals greater technical severity. The score may reflect factors such as whether the flaw can be exploited remotely, whether authentication is needed, how complex the attack is, and what impact it may have on confidentiality, integrity, or availability.

CVSS is useful, but it should not be the only input for decision-making. Security teams also need context such as asset value, internet exposure, exploit availability, business function, compensating controls, and whether attackers are already using the vulnerability.

CISA’s Known Exploited Vulnerabilities Catalog exists for that reason. CISA describes the catalog as an authoritative source of vulnerabilities exploited in the wild and recommends using it as an input for vulnerability management prioritization.

Common Types of Vulnerabilities

Broken authentication

Broken authentication occurs when attackers can compromise credentials, session tokens, password reset flows, or identity checks. A successful attack may let them impersonate users, access private accounts, or gain elevated permissions.

Common causes include weak password rules, poor session handling, missing multi-factor authentication, unsafe token storage, and flawed login logic.

Injection flaws

Injection flaws happen when an application accepts untrusted input and sends it to an interpreter as part of a command or query. SQL injection is one of the best-known examples. An attacker may send malicious input that changes a database query and exposes, modifies, or deletes data.

OWASP’s 2025 Top 10 lists injection among major web application security risk categories, alongside access control failures, security misconfiguration, and other application weaknesses.

Cross-site scripting

Cross-site scripting, often called XSS, allows attackers to inject malicious scripts into web pages viewed by other users. The target is usually the user, not just the website. A successful XSS attack may steal session tokens, alter page content, redirect users, or capture sensitive input.

XSS often appears when applications accept user input and display it without proper validation or output encoding.

Cross-site request forgery

Cross-site request forgery, or CSRF, tricks an authenticated user’s browser into sending an unintended request to a trusted application. If the application accepts the request, the attacker may cause actions such as changing account settings, submitting forms, or modifying records.

Strong request validation, anti-CSRF tokens, and safer authentication patterns reduce this risk.

Security misconfiguration

Security misconfiguration refers to unsafe settings in systems, applications, cloud services, databases, networks, or identity controls. Examples include public storage, open admin ports, default credentials, verbose error messages, disabled logs, weak encryption settings, and overly broad access policies.

Misconfiguration is often preventable, but it remains common because environments change quickly and ownership is sometimes unclear.

Vulnerabilities and Data Exposure

Vulnerabilities can lead to data leaks and data breaches, but the two terms are not the same. A data leak usually refers to data being exposed accidentally, often through misconfiguration or human error. Examples include sending a confidential file to the wrong recipient, placing sensitive files in public cloud storage, or leaving an unlocked device visible in a public place.

A data breach involves unauthorized access, theft, disclosure, or compromise of data. A vulnerability can be the opening that allows that breach to happen.

Verizon’s 2025 Data Breach Investigations Report found that exploitation of vulnerabilities as an initial access step grew by 34 percent and accounted for 20 percent of breaches. The same report noted that only about 54 percent of perimeter device vulnerabilities were fully remediated, with a median remediation time of 32 days.

How Vulnerability Scanning Works

A vulnerability scanner checks systems, applications, packages, configurations, and services against vulnerability data and security checks. The scanner compares what exists in the environment with known flaws, missing patches, unsafe settings, and exposed services.

Scan quality depends on accurate asset data, current vulnerability intelligence, credentialed access where needed, and complete coverage across endpoints, servers, cloud workloads, containers, and third-party applications.

Scanning gives teams visibility, but scanning alone does not reduce risk. The findings must be prioritized, assigned, fixed, and validated. Frequent scanning also helps teams spot patterns, such as recurring patch delays, repeated misconfigurations, or specific asset groups that carry more risk.

How Teams Should Prioritize Vulnerabilities

A long list of findings can overwhelm security and IT teams. Prioritization helps them decide what to fix first.

A sound prioritization model considers severity, exploit activity, asset exposure, business impact, data sensitivity, privilege level, and remediation effort. A vulnerability on an internet-facing system with sensitive data should usually move faster than the same issue on an isolated test machine.

Known exploitation should carry special weight. When a vulnerability appears in CISA’s Known Exploited Vulnerabilities Catalog, it means attackers have used it in real activity, which makes delayed remediation much harder to justify.

Why Vulnerabilities Need Continuous Management

Vulnerabilities are not one-time problems. New CVEs are published constantly, systems change daily, and configurations drift as teams deploy updates, connect tools, and adjust access.

A mature vulnerability management process keeps asset inventory, scanning, prioritization, remediation, and validation connected. Teams need to know what they own, which weaknesses affect those assets, which issues create the most risk, who owns each fix, and whether remediation worked.

Vulnerabilities become dangerous when they remain unknown, unassigned, or unresolved. Clear visibility and timely remediation help organizations reduce attack paths before attackers can turn small weaknesses into larger incidents.