Revisiting CVE and CVSS: From Vulnerability Identification to Risk-Based Remediation

Introduction

In my previous article, I discussed CVSS 3.1 and 4.0, including their scoring differences and calculation methodologies. However, I think it is worth revisiting how we use CVE and CVSS in our actual security assessments.

The number of publicly disclosed vulnerabilities continues to increase, and vulnerabilities are no longer limited to individual applications. They can affect programming languages, shared libraries, operating systems, databases, storage systems, container platforms, and even infrastructure management tools.

For an infrastructure team, identifying a CVE is only the beginning. We still need to determine whether the vulnerability affects our environment, whether the affected component is exposed, whether exploitation is possible, and what consequences it could have.

A critical CVSS score does not automatically mean that every system running the software is vulnerable. Similarly, a medium-severity vulnerability should not automatically be considered safe to ignore.

I want to revisit this process from a practical perspective:

1. Understand the difference between CVE and CVSS.
2. Identify all potentially relevant vulnerabilities within an environment.
3. Verify which findings actually apply to the affected systems.
4. Assess the risks using technical and environmental information.
5. Determine how to mitigate the findings and verify the result.

The objective is not simply to collect CVE numbers. It is to understand what they mean for the systems we are responsible for.

1. CVE and CVSS: Two Different Purposes

Before conducting an assessment, we need to understand the difference between CVE and CVSS.

CVE: Common Vulnerabilities and Exposures

CVE provides standardized identifiers for publicly disclosed cybersecurity vulnerabilities.

A CVE record normally contains:

• A unique CVE identifier.
• A description of the vulnerability.
• References to relevant advisories and technical information.
• Information about affected products and versions, where available.

For example:

CVE-2025-55182, commonly known as React2Shell, identifies a remote code execution vulnerability affecting React Server Components.

The CVE identifier allows security teams, vendors, researchers, and vulnerability management tools to refer to the same vulnerability without confusing it with another issue.

However, a CVE identifier does not tell us whether our particular system is affected. We still need to examine the affected product, version, configuration, and deployment conditions.

Another important detail is that CVE records have different statuses. A reserved identifier does not necessarily have publicly available vulnerability details, while a rejected record should not be treated as a valid vulnerability finding.

Reference: CVE Program

CVSS: Common Vulnerability Scoring System

CVSS provides a standardized method to communicate the technical severity of a vulnerability.

It assigns a numerical score from 0.0 to 10.0, together with a vector describing the characteristics used to derive that score.

CVSS helps us compare vulnerability severity, but it is not a complete measurement of organizational risk.

For example, consider two systems:

• A development server running a vulnerable application that is not accessible from outside the organization.
• An Internet-facing application server providing access to sensitive healthcare information.

Even when both systems have the same CVE and CVSS Base Score, their actual organizational risks may be very different.

This is why we need to consider the environment in which the vulnerability exists.

The official CVSS specification is maintained by FIRST:

CVSS 4.0 Specification

2. Where Should We Find CVE Information?

One of the common problems during vulnerability assessment is relying on a single source of information.

Searching Google for a product name and CVE is useful for initial research, but it is not sufficient for a complete assessment.

Different sources provide different types of information.

CVE Program

The CVE Program provides the official CVE records and identifiers.

It is useful for identifying whether a particular vulnerability has been publicly recorded and for reviewing its original description and references.

National Vulnerability Database (NVD)

The National Vulnerability Database is maintained by NIST.

It provides additional vulnerability information, including CVSS assessments, product applicability information, CPE identifiers, and other technical metadata.

The NVD can help us identify vulnerabilities associated with particular products and versions.

However, NVD enrichment is not necessarily available immediately for every published CVE. We should also examine the original vendor advisory instead of assuming that missing NVD information means that a vulnerability does not exist.

Vendor Security Advisories

Vendor advisories are particularly important because they explain which versions are affected and which versions contain the fixes.

For example, a vulnerability may affect only:

• A particular product version.
• A particular application module.
• A specific operating system.
• An optional feature or plugin.
• A specific deployment configuration.

The vendor may also publish a mitigation before a CVE record becomes available.

GitHub Security Advisories

For software distributed through GitHub and package ecosystems such as npm, GitHub Security Advisories can provide useful information about affected dependencies, patched versions, and package-level vulnerabilities.

Not every advisory has a CVE identifier.

This is important because searching only for CVE numbers may cause us to overlook relevant security findings.

CISA Known Exploited Vulnerabilities (KEV)

The CISA KEV Catalog identifies vulnerabilities for which there is evidence of exploitation in the wild.

This information is particularly useful when prioritizing mitigation.

A vulnerability appearing in KEV deserves attention because exploitation has been observed, although we still need to determine whether the affected product exists in our environment.

EPSS: Exploit Prediction Scoring System

The Exploit Prediction Scoring System is maintained through FIRST.

Unlike CVSS, EPSS estimates the probability that a published CVE will be exploited in the wild within the next 30 days.

EPSS produces a value between 0 and 1 and updates its scores daily.

It is a useful additional signal when we need to prioritize a large number of vulnerability findings.

However, EPSS does not determine the impact on our particular environment.

We should therefore distinguish between:

• CVSS: How severe is the vulnerability?
• KEV: Is there evidence that the vulnerability has been exploited?
• EPSS: What is the estimated probability of exploitation activity in the next 30 days?
• Environmental assessment: What would happen if this particular system were compromised?

These sources provide complementary information rather than interchangeable scores.

3. How to Identify All Potentially Relevant CVEs

This is where I think many vulnerability assessment workflows need improvement.

A simple software inventory and a port scanner are not necessarily enough to identify every vulnerability in an environment.

We need to understand what is actually running behind each service.

For example, an application server may contain:

• A programming language runtime.
• Application frameworks.
• Third-party libraries.
• Database connectors.
• Web server components.
• Image processing libraries.
• Operating system packages.
• Container runtime components.
• Additional plugins and modules.

A vulnerability may exist in a dependency that the administrator does not directly manage.

Therefore, I would approach CVE identification as a component correlation process.

Step 1: Build an accurate asset inventory

Start by identifying the systems within the assessment scope.

For every asset, collect the following information:

The exact version is important.

Knowing that a system uses Linux is not enough. We need to identify the distribution, release, installed packages, and relevant build information.

Likewise, knowing that a system uses React or Node.js does not tell us which versions of the underlying components are installed.

Step 2: Identify direct and indirect dependencies

We should not stop at the application name.

For software projects, examine:

• Dependency manifests.
• Lock files.
• Software Bill of Materials (SBOM).
• Container image contents.
• Operating system package inventories.
• Runtime and framework dependencies.
• Third-party plugins and extensions.

An SBOM is particularly useful because it provides an inventory of software components and their relationships.

For example, a Next.js application may depend on React Server Components, image processing libraries, and other packages.

If we only check the Next.js version, we may overlook a vulnerable dependency or an overridden package version.

Step 3: Search using multiple identifiers

I would use several search methods instead of relying on one product-name search.

A. Search by vendor and product

Example:

• Vendor: Microsoft
• Product: Windows Server
• Version: Exact build number

B. Search by package name

Example:

• Package: react-server-dom-webpack
• Version: Exact package version

C. Search by CPE

Common Platform Enumeration (CPE) provides standardized product and version names.

NVD supports searching for vulnerability information using CPE identifiers and applicability criteria.

D. Search by package URL (PURL)

PURL helps identify software packages across different package ecosystems.

For example, an npm package and an operating system package may have different identifiers even when they contain related software.

E. Search vendor security advisories

Search for the product name, affected version, framework, optional features, and security advisory identifiers.

This is important because some findings may be published as GHSA identifiers without an associated CVE.

Step 4: Expand the search to related components

Once we identify an application, we should follow its dependency relationships.

For example:

Application → Framework → Shared libraries → Runtime → Operating system → Container image → Host environment

We should also consider the infrastructure supporting the application:

• Database servers.
• Storage systems.
• Authentication services.
• Reverse proxies.
• Network gateways.
• Container orchestration.
• CI/CD pipelines.

A vulnerability in a shared component may affect more than one application.

Step 5: Compare affected and fixed versions

Every candidate CVE needs to be compared with the actual installed version.

We should examine:

• Affected version range.
• Fixed version.
• Operating system requirements.
• Required application features.
• Configuration dependencies.
• Authentication requirements.
• Network exposure.
• Additional prerequisites.

A system running a product name associated with a CVE is not automatically affected.

We need supporting evidence.

Step 6: Build the complete candidate list

I would maintain a vulnerability register with the following fields:

The initial candidate list should be broad enough to avoid missing relevant findings.

Afterward, we validate and remove findings that do not apply.

Importantly, I would not call this an absolute list of every vulnerability in existence. It is a comprehensive list of currently identified candidates within a defined assessment scope and information date.

4. Practical Example: A Vulnerable Next.js Application

Let’s consider one example.

An organization operates an Internet-facing application that provides a remote patient monitoring dashboard.

The application stores patient information and receives monitoring data from connected services.

The environment contains:

For this example, assume the application has a use cache function that returns multiple typed arrays.

We now have enough information to examine the relevant Next.js security advisories.

Identifying the related vulnerabilities

As of November 4, 2026, the following three findings are relevant to this configuration.

Finding 1: CVE-2026-96889

Critical · CVSS 4.0: 9.5

This vulnerability concerns a memory-related issue in an upstream library used by Next.js Image Optimization.

The issue can result in remote code execution when Next.js runs on glibc-based Linux under the affected Image Optimization conditions.

For our example, the relevant conditions are present:

• Next.js 16.4.0.
• glibc-based Linux.
• Image Optimization enabled.
• A vulnerable sharp dependency.
• SVG image handling in the application.

The vendor lists Next.js 16.4.1 as the fixed version.

A temporary workaround is to ensure that the version of sharp used by Next.js is 0.35.5 or later.

References:

• Next.js Security Update, October 14, 2026
• CVE-2026-96889

Finding 2: GHSA-673q-mjm6-r5xr

Critical · CVSS 4.0: 9.5

This finding is particularly interesting because it does not have a CVE identifier in the published advisory.

It affects Next.js applications using App Router and Cache Components when a use cache function returns multiple typed arrays.

The potential consequence is unauthenticated remote code execution.

Our example uses exactly this combination.

The vendor states that there is no known workaround for affected applications and recommends upgrading immediately.

Fixed version:

• Next.js 16.4.1.

Reference:

Next.js GitHub Security Advisory

This demonstrates why searching exclusively for CVE identifiers is insufficient.

Finding 3: CVE-2026-94482

High · CVSS 4.0: 8.2

This vulnerability affects Next.js applications using App Router with at least one Server Action.

A crafted request can cause excessive CPU consumption and prevent the application from processing additional requests within the affected process.

This is primarily an availability problem.

Our application uses App Router and Server Actions, so the finding applies.

The vendor identifies the following fixed versions:

• Next.js 15.5.28.
• Next.js 16.4.1.

References:

• CVE-2026-94482
• Next.js Security Update

Summary of the case

All three findings affect the same application, but their technical causes and consequences are different.

The important point is that one software version can be associated with multiple vulnerabilities.

A simple scan that reports only the highest CVSS score would not provide sufficient information for understanding the complete situation.

What about other CVEs?

The three findings above cover the relevant Next.js advisories for the specified October 2026 case.

They do not represent a complete security assessment of the entire server.

We still need to examine:

• The actual Node.js runtime.
• The React and React Server Components packages in the lock file.
• The sharp dependency.
• Linux kernel and system libraries.
• The container base image.
• The container runtime.
• The reverse proxy.
• Database software.
• Other installed packages and services.

We should also search for advisories that have no CVE identifier and check for duplicate CVE records.

For example, CVE-2025-66478 was declared a duplicate of CVE-2025-55182 in the React Server Components security disclosures. Counting both as separate underlying vulnerabilities would inflate the findings.

This is why vulnerability correlation and expert verification are important.

5. CVSS: Understanding Severity Versus Actual Risk

After collecting the candidate vulnerabilities, we need to determine their severity and relevance.

This brings us back to CVSS.

I have already discussed CVSS 3.1 and 4.0 in my previous article, so I will focus here on how to apply the results.

Base Score

The Base Score describes the intrinsic technical characteristics of a vulnerability.

It helps us understand:

• How the vulnerability can be accessed.
• Whether authentication is required.
• Whether user interaction is necessary.
• What impact successful exploitation can have.

The Base Score is useful for comparing technical severity, but it does not know the value of our particular assets.

Threat Score

The Threat metric group considers the maturity of exploit activity.

For example, exploit code may be publicly available, or there may be evidence that exploitation is occurring.

This information can change over time, so vulnerability prioritization needs regular updates.

Environmental Score

This is particularly useful for infrastructure assessments.

The same vulnerability may have different implications depending on where it exists.

Consider:

• A development server with no sensitive information.
• An internal database server.
• A publicly accessible application server.
• A healthcare monitoring service.

Their confidentiality, integrity, and availability requirements may be very different.

CVSS Environmental metrics allow us to customize the assessment based on the affected environment and available security controls.

Supplemental Metrics

CVSS 4.0 also introduces Supplemental metrics such as Safety, Recovery, Automatable, and Value Density.

These can provide additional context.

For example, Safety is important when assessing healthcare and industrial environments.

However, Supplemental metrics do not change the numerical CVSS score. They should be used as additional decision-making information rather than treated as a separate numerical risk score.

CVSS is not the same as business risk

This distinction is important.

A CVSS score of 9.5 does not automatically mean that every affected system must be shut down.

Likewise, a vulnerability with a score of 6.5 should not automatically be postponed when it affects a critical, publicly accessible service.

We need to examine the complete environment.

For our healthcare monitoring example, we should consider:

• Does the application contain sensitive patient information?
• Is it accessible from the Internet?
• Does it connect to other healthcare systems?
• Can the affected service modify patient data?
• Can the vulnerability interrupt monitoring services?
• Are there additional privileges available to the application?
• What would be the impact if the application became unavailable?

This information helps us determine the actual remediation priority.

6. Prioritizing CVEs Using CVSS, KEV and EPSS

When an organization has hundreds or thousands of vulnerability findings, it is not always practical to patch everything simultaneously.

We need a prioritization process.

I would consider the following information together:

For example, a vulnerability with a Critical CVSS score and confirmed exploitation on an exposed production system should receive immediate attention.

Another Critical vulnerability might affect a system that does not use the vulnerable feature and is not exposed to the relevant attack path.

The second finding still needs documentation, but it should not be treated as equivalent to the first.

We should also avoid multiplying CVSS and EPSS scores together and presenting the result as an overall risk score.

They measure different things. EPSS is a probability estimate, whereas CVSS is a technical severity assessment.

They should be combined through an organizational prioritization process that considers environmental impact.

7. Risk Mitigation: What Should We Do Next?

Once the findings are verified and prioritized, we need to decide how to mitigate them.

Not every vulnerability requires the same solution.

I would divide the mitigation process into several stages.

Stage 1: Confirm the findings

Before changing production systems, confirm:

• The affected software is installed.
• The installed version falls within the affected range.
• The vulnerable feature is present.
• The necessary operating conditions exist.
• The vendor has not already provided an applicable fix.

This helps avoid unnecessary upgrades and service interruptions.

Stage 2: Patch or upgrade

The preferred approach is normally to install the vendor’s security update.

For our Next.js example, the recommended action is to upgrade from 16.4.0 to the patched 16.4.1 release or a later supported patched release.

We should also check the dependency lock file and confirm that the deployed application actually uses the corrected packages.

Updating the package manifest without rebuilding and redeploying the application does not resolve the production vulnerability.

Stage 3: Apply temporary mitigation

Sometimes a patch cannot be deployed immediately.

This may happen because of:

• Application compatibility.
• Vendor dependencies.
• Testing requirements.
• Maintenance windows.
• Business operations.
• Medical device or clinical service constraints.

In these situations, alternative controls may reduce exposure.

For CVE-2026-96889, the vendor identifies sharp 0.35.5 or later as a workaround.

For the two other findings, the advisories do not identify an equivalent workaround. Temporary access restrictions or service isolation may reduce exposure, but they should not be considered a replacement for the security update.

A firewall or WAF may help control access, but we should not assume that it completely prevents exploitation.

Stage 4: Review credentials and access permissions

When a vulnerability potentially allows remote code execution, we need to consider what the application can access.

Review:

• Application service accounts.
• Database credentials.
• API tokens.
• Cloud credentials.
• IAM permissions.
• Container permissions.
• Access to storage systems.
• Secrets exposed to deployment pipelines.

The objective is to limit the damage that could occur if the application is compromised.

If compromise is suspected or confirmed, credentials and secrets accessible to the affected application may need to be rotated after the environment has been contained and investigated.

Stage 5: Check for compromise

Patching does not automatically prove that a system has never been compromised.

When a vulnerability has a plausible exploitation path, we should examine relevant evidence, including:

• Application logs.
• Reverse proxy logs.
• Authentication records.
• Unexpected process activity.
• Unusual outbound communications.
• Changes to application files.
• Unexpected user accounts or permissions.
• Cloud and infrastructure audit records.

If there is evidence of compromise, the process should move from ordinary vulnerability remediation to incident response.

The affected environment may need to be isolated, investigated, rebuilt from trusted sources, and restored using verified data.

Stage 6: Verify the remediation

After completing the updates, we should verify:

1. The application is running the patched version.
2. Vulnerable dependencies have been replaced.
3. Old container images and replicas are no longer active.
4. The affected features have been tested.
5. Network access remains within the expected boundaries.
6. Security scanning no longer identifies the same applicable findings.
7. Monitoring and logging are operating correctly.

A remediation should not be marked complete simply because an administrator reports that an update was installed.

We need evidence that the affected component is no longer vulnerable.

8. Risk Mitigation Is Not Always About Replacing Software

One thing I want to emphasize is that patching or replacing software is not always the only solution.

Sometimes the existing application is supported and can be secured through configuration changes.

Other times, the affected component is no longer maintained and requires replacement.

I would consider four possible outcomes:

We should consider the cost, compatibility, operational impact, and support lifecycle before selecting a solution.

This is particularly important for NAS, SAN, IoT and healthcare devices where replacement may involve additional hardware, integration and service-continuity requirements.

A security recommendation should explain why a particular action is appropriate rather than simply telling the organization to replace everything.

9. AI-Assisted CVE Correlation and Expert Verification

With the increasing number of CVEs and security advisories, I think AI can become a useful part of vulnerability assessment.

However, I would not use AI as the only source of vulnerability information.

I would use it to support the correlation process.

For example, AI can help:

• Identify CVEs associated with products and versions.
• Compare affected and fixed version ranges.
• Identify related vulnerabilities in dependencies.
• Detect duplicate advisories.
• Correlate CVE and GHSA identifiers.
• Summarize vendor security advisories.
• Identify configuration requirements.
• Organize findings by affected assets.
• Prepare remediation recommendations.

This can reduce repetitive research and make it easier to investigate multiple components.

However, every important finding still needs evidence.

An AI-generated finding should include the original advisory, affected version range, installed version, applicable configuration, and supporting evidence.

We should also distinguish between:

• Confirmed vulnerability.
• Potentially affected component.
• Not affected configuration.
• False positive.
• Insufficient information.

An unknown finding should not automatically be classified as a false positive.

For example, if the software version is unavailable or the dependency inventory is incomplete, the correct result is that further verification is required.

AI can help us investigate, but the final assessment and risk acceptance should remain accountable to qualified professionals.

We should also protect the information being processed. Infrastructure inventories, application logs, configuration files, and security reports may contain sensitive information. They should only be shared with AI systems approved for that data.

10. Connecting CVE and CVSS to VAPT and DRP

I think the relationship between vulnerability assessment and disaster recovery becomes clearer when we look at the complete process.

VAPT identifies security weaknesses and evaluates their potential impact.

CVE provides a common reference for known vulnerabilities.

CVSS communicates their technical severity.

Threat intelligence helps us understand exploitation activity.

Environmental assessment identifies the consequences for the organization.

Mitigation reduces the likelihood or impact of exploitation.

DRP prepares the organization to recover if the affected systems become unavailable or cannot be trusted.

For example, if a vulnerability allows an attacker to compromise a database server, simply installing a patch may not be sufficient if the attacker has already modified information or accessed other systems.

The organization may need to investigate the database, verify its integrity, review related credentials, and restore from a trusted backup.

That is where VAPT and DRP begin to work together.

The vulnerability assessment helps us understand the exposure, while the recovery plan helps determine what to do if the system can no longer be trusted.

Conclusion

I think we need to reconsider how we interpret CVE and CVSS.

Collecting CVE numbers and sorting them by numerical severity is useful, but it is not sufficient for a meaningful security assessment.

We need to understand which products are affected, which versions are running, what configurations are involved, whether exploitation is occurring, and what consequences a successful attack could have.

The number of vulnerabilities will continue to challenge infrastructure teams, particularly when multiple layers depend on the same libraries, services and platforms.

AI can help us correlate information and reduce repetitive investigation, but it should not replace technical verification and professional judgment.

Ultimately, the objective is not to produce the longest CVE list or the highest number of Critical findings.

It is to identify the vulnerabilities that actually affect the organization, understand their consequences, and apply the appropriate mitigation.

In my next article, I want to take this discussion further into Disaster Recovery Planning, with a particular focus on Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

Finding a vulnerability tells us what needs attention. Understanding how much service interruption and data loss an organization can tolerate tells us how prepared we need to be when prevention is no longer enough.

References and Resources

• CVE Program
• National Vulnerability Database (NVD)
• FIRST: CVSS 4.0 Specification
• FIRST: EPSS
• CISA: Known Exploited Vulnerabilities Catalog
• NVD: Common Platform Enumeration (CPE)
• Next.js Security Advisories