Vulnerability Severity Levels Explained | Categories & CVSS

Vulnerability Severity Levels Explained (CVSS, Categories & Risk)

Understanding vulnerability severity levels is the first step in an effective remediation program. But severity alone does not tell you where to focus. A Critical-rated flaw on an isolated test server is not the same threat as a High-rated flaw sitting on a public-facing system that handles payment data. The score is a starting point. Context is what turns a score into a decision.

This guide covers how vulnerabilities are classified, how the CVSS scoring system works, and how teams can build a remediation roadmap that reflects actual business risk rather than just numbers on a dashboard.

What Are Vulnerability Severity Levels?

Vulnerability severity levels are standardized classifications, such as Critical, High, Medium, and Low, that indicate the potential impact of a security vulnerability if exploited. These levels, typically based on CVSS scores, help organizations assess and compare vulnerabilities across systems, vendors, and environments.

Most organizations rely on the Common Vulnerability Scoring System (CVSS)—maintained by FIRST (Forum of Incident Response and Security Teams) and used by the National Vulnerability Database (NVD)—as the standard for assigning these levels. This security vulnerability classification framework generates a numerical score from 0.0 to 10.0, which maps to five qualitative ratings:

CVSS v3.1 is currently the most widely deployed version. CVSS v4.0 was released in November 2023, but as of 2025, only about 26% of published CVEs carried a v4.0 score—adoption remains limited even among major enrichment sources like NIST NVD and CISA.

How Vulnerabilities Are Categorized

Vulnerability categories describe the type of security issue, helping organizations understand root causes and assign remediation ownership. While severity measures impact, categorization identifies whether a vulnerability stems from outdated systems, misconfigurations, or human factors like social engineering.

Based on real-world testing engagements, most vulnerabilities fall into three primary categories:

Category 1: Out-of-Date Systems and Missing Patches

The first category covers out-of-date systems or systems missing security patches.

Out-of-date systems can be end-of-life (EoL), meaning the vendor or creator no longer maintains the project. New vulnerabilities may be discovered in EoL hardware or software that will never be patched, updated, or formally disclosed as the developer moves on to other goals.

Missing security patches are different. The vendor is still actively maintaining the product—the responsibility for keeping patches current falls to the network administrator and the patching policy. As remote work extended the network perimeter, every user with elevated access became a potential exposure point.

Typically, these issues receive a Critical or High rating because of the severity of their impact on an organization. Application misconfiguration and out-of-date systems are among the most common findings that enable remote code execution or data leakage. Fortunately, most operating systems default to automatic updates, which mitigates much of this risk at the endpoint level. Organizations without a formal patching policy should address that gap first.

Category 2: Misconfigurations

Misconfiguration in both applications and infrastructure is the most common category RedLegg encounters during engagements. Misconfigurations have led to the disclosure of sensitive data and unauthorized access to admin panels—including file upload functions, user settings, configuration pages, traffic interception points, and more.

These vulnerabilities often appear on older systems that have not been in use for years. Hardware and software in that state should be taken offline and replaced or formally documented as accepted risk with a high-alert threshold set on the host.

Web application vulnerabilities frequently fall under this category as well. Security header tokens are a recurring finding: pages without proper security tokens can be exploited to coerce users into completing unintended actions. That exposure can allow a malicious actor to transfer funds, change account credentials, expose private API keys, or gain full application access.

Exploiting a misconfiguration typically requires chaining multiple data points rather than a single click. An attacker who discovers a clickjacking flaw still needs to build a spoofed page, register a convincing domain, and successfully manipulate the victim before capturing valid credentials—and then contend with additional controls like two-factor authentication.

These vulnerabilities most commonly score in the Medium or Low range.

Category 3: Social Engineering Attacks

Social engineering defines the third category. Success in social engineering attacks depends entirely on the attacker's ability to convince the target that they are someone else, making it harder to quantify variables and assess severity.

Social attacks range from badge cloning, which captures an authentication mechanism, to tailgating to gain physical building access, to impersonating IT or HR personnel to extract sensitive information. If a targeted user has minimal access, the risk is relatively contained. If an attacker uses tailgating to gain physical access to the building, they may be able to plant keyloggers, data taps, or drop devices and map additional weak points, including server room entry controls.

Because social engineering sits largely outside the CVSS framework, user awareness training and physical penetration testing are the most reliable countermeasures available.

CVSS Severity Levels: What the Scores Actually Measure

CVSS severity levels measure the intrinsic characteristics of a vulnerability, including how it can be exploited and the potential impact on affected systems. The resulting score reflects theoretical severity, not real-world risk within a specific environment.

The CVSS framework consists of three key metric groups:

• Base Metrics capture the characteristics of the vulnerability itself: attack vector, attack complexity, privileges required, user interaction, scope, and impact on confidentiality, integrity, and availability.
• Threat Metrics (formerly Temporal in CVSS v3.x) reflect external factors that change over time, such as the maturity of available exploit code and the status of patches.
• Environmental Metrics allow organizations to customize the score to their environment, accounting for asset criticality, existing compensating controls, and the extent to which a given system's compromise would actually matter to business operations.

The NVD publishes Base Score assessments for all CVEs in its database. Individual organizations are responsible for Threat and Environmental scoring, and this is where most teams struggle.

Critical vs. High Vulnerabilities: What's the Difference?

Critical vulnerabilities typically allow immediate, unauthenticated exploitation with severe impact, while high vulnerabilities involve more constraints but still represent significant risk. Both require attention, but critical findings generally demand immediate remediation.

The gap between critical vs. high vulnerability ratings—9.0–10.0 and 7.0–8.9, respectively—is meaningful, though not always in the way teams expect. Understanding these vulnerability risk levels in practice requires more than reading the score.

Critical vulnerabilities are typically network-exploitable, require no authentication, and can result in full system compromise. Remote code execution vulnerabilities in widely deployed platforms often land here. In 2025, critical-severity CVEs accounted for approximately 7.4% of all published CVEs, down from 12.8% in 2024, in part due to the shift toward CVSS v4.0 scoring, which was calibrated to reduce score inflation.

High vulnerabilities still represent serious exposure. They often require some level of access or configuration to exploit or involve a lower potential impact than a full compromise. That said, in complex environments, a chain of High vulnerabilities can effectively become a Critical-level event when combined.

The practical distinction: Critical findings almost always warrant immediate action. High findings require prioritization based on environmental context—particularly exposure level, exploitability, and asset value.

Why Severity Does Not Equal Risk

Vulnerability severity does not equal risk because severity measures potential impact, while risk reflects how that vulnerability behaves in your specific environment. Two organizations can face completely different levels of risk from the same CVE.

This is the most important concept in vulnerability management.

A CVSS score measures how bad a vulnerability could be under general conditions. It does not measure how bad it would be in your environment. Two organizations can receive identical scanner outputs for the same CVE and face completely different levels of actual risk.

Several factors determine whether a scored vulnerability represents real risk to your organization:

• Asset criticality. A Critical finding in a development sandbox has different implications than the same finding in a production database that stores customer records.
• Exploitability in context. CVSS Base Scores assume a worst-case scenario for attack conditions. Your environment may have compensating controls, such as segmentation, authentication requirements, or monitoring, that make real-world exploitation significantly harder.
• Exposure. A vulnerability that requires adjacent network access poses a different threat to an internet-facing server than to an air-gapped system.
• Threat intelligence. Active exploitation in the wild changes the calculus entirely. CISA's Known Exploited Vulnerabilities (KEV) catalog grew to 1,484 entries by the end of 2025, a nearly 20% increase from 2024, tracking vulnerabilities confirmed to be actively exploited. A Medium-scored CVE in the KEV catalog may warrant faster remediation than a Critical-scored CVE with no known exploit code.

CVSS itself acknowledges this limitation. The NVD's own documentation states that CVSS is not a measure of risk; it is a measure of severity. The difference matters.

Not sure which vulnerabilities to tackle first? Our team can help you validate your findings and build a prioritization framework based on your actual risk profile, not just scores. Talk to an expert

How to Prioritize Vulnerabilities Effectively

Effective vulnerability prioritization combines severity scores with real-world context, including exploitability, asset importance, and exposure. Relying solely on CVSS scores often leads to inefficient remediation and missed high-risk issues.

For a risk-based prioritization approach:

• Start with exploitability. Is there a known exploit in the wild? Is the vulnerability in CISA's KEV catalog? VulnCheck data from 2025 found that 32% of newly exploited CVEs were weaponized either before public disclosure or within 24 hours of it, a finding that compresses the window for purely reactive patching strategies.
• Factor in asset criticality. Map vulnerabilities to the business function of the affected system. Revenue-generating, regulated, or customer-facing systems should be given higher priority regardless of their raw CVSS score.
• Assess your exposure. Internal vulnerability scans almost always surface more Critical and High findings than external scans because internal systems often run older or proprietary software that can't be updated without disrupting operations. That doesn't mean those findings are more urgent; it means exposure context matters.
• Layer in threat intelligence. CVSS score, asset value, and exploit availability together paint a more accurate picture than any single input.
• Validate before remediating. A finding on a scanner report is an assertion, not a confirmed risk. Penetration testing services validate whether a vulnerability is actually exploitable in your environment, saving remediation cycles on theoretical risks while surfacing the ones that matter.

Vulnerability Scanning vs. Penetration Testing: What Each Does

Vulnerability scanning automatically identifies potential security issues, while penetration testing validates whether those vulnerabilities can be exploited in real-world conditions. Both are essential components of a mature vulnerability management program.

These two tools serve different functions in a vulnerability management program, and neither replaces the other.

Vulnerability scanning is automated detection. A scanner compares your environment against a database of known vulnerabilities and produces a report of findings with associated CVSS scores. It identifies potential issues quickly and at scale. It does not confirm exploitability.

Penetration testing is manual validation. A tester actively attempts to exploit identified vulnerabilities to determine what an attacker could actually accomplish. It confirms real risk, identifies attack chains across multiple lower-scored findings, and provides a more accurate picture of your overall exposure.

For most organizations, vulnerability scanning best practices recommend running automated scans at regular intervals and using penetration testing to validate findings, especially before major infrastructure changes or after significant vulnerability disclosures.

 Frequently Asked Questions 

RedLegg's penetration testing and vulnerability scanning teams work with organizations to validate findings, build risk-based prioritization frameworks, and develop remediation strategies that reflect how your environment actually operates, not just what a scanner reports. Talk to an expert about putting your vulnerability data to work.

Or, keep reading...

• How to optimize your vulnerability scans
• 6 vulnerability scanning best practices
• [Webinar] Best practices in tackling your vulnerability scan results