Which CVEs Deserve Your Attention?

A practical way to prioritize vulnerability alerts using exploitation evidence, exposure, and the systems you actually run.

A dependency scan finishes, and the report contains three critical vulnerabilities, twelve high ones, and a page of medium findings. You have a release to ship and time to investigate only a few alerts. Where do you start?

Sorting by severity is a useful first view. It leaves some important questions unanswered: Is the affected code deployed? Can an attacker reach it? Is the vulnerability being exploited? What would someone gain by exploiting your particular system?

A workable patch queue needs answers to those questions. Here is a practical sequence for developers who own both the application and the work of keeping it secure.

1. Check what is actually affected

Start with the maintainer's advisory, then compare it with the software you have deployed. Record the package or product, the affected version range, the installed build, and any required configuration.

Check the deployed artifact rather than relying only on a manifest. A version range in package.json is not proof of the resolved version, and an updated lockfile is not proof that production has been rebuilt. Containers, background workers, preview deployments, and build runners can have different dependency inventories.

For operating-system packages, check the distribution's security advisory and full package release. Red Hat, for example, backports security fixes to older package versions. A scanner that compares only the upstream version can report a vulnerability that the distribution has already fixed. Red Hat's backporting guidance explains this distinction.

An alert might turn out to be an incorrect package match, an already-fixed build, or a genuine affected dependency. Keep the evidence for that conclusion. If you cannot establish what is deployed, mark the finding as unresolved and assign the investigation. Missing information should not quietly become “not affected.”

2. Read the severity, not just the number

The Common Vulnerability Scoring System, or CVSS, describes vulnerability severity. Its Base score describes intrinsic characteristics; it does not know the importance of your application or all the controls around it. CVSS v4 also has Threat and Environmental metrics to bring in additional context. FIRST's CVSS v4 user guide explains these distinctions.

Read the vector alongside the score. Does exploitation require authentication, user interaction, or local access? Does success expose data, modify it, or interrupt service? Note the CVSS version and scoring source so that unlike assessments do not get flattened into one unexplained decimal.

A local privilege-escalation vulnerability on a sensitive build runner can deserve substantial attention. A higher-scoring issue in a component absent from your deployed system may require no remediation there. You need the underlying conditions to tell those cases apart.

3. Separate exploitation evidence from a prediction

Two useful inputs answer different questions.

CISA's Known Exploited Vulnerabilities catalog, or KEV, records vulnerabilities known to have been exploited in the wild. An applicable KEV entry deserves prompt attention. The catalog is an input to prioritization, not a complete inventory of every possible attack. Absence from it does not establish safety. Check the entry's required action and the linked vendor guidance. CISA KEV catalog

FIRST's Exploit Prediction Scoring System, or EPSS, estimates the probability of exploitation activity being observed across its data partners for a CVE over the next 30 days. It is updated daily. It does not estimate the probability that your particular application will be compromised, and it does not measure the damage that would cause. FIRST EPSS FAQ

Keep probability and percentile separate. A 95th-percentile ranking does not mean a 95% probability of exploitation. Keep the score's date, too: yesterday's forecast is a dated input, not a permanent property of the vulnerability.

Use direct exploitation evidence ahead of a reassuring forecast. FIRST explicitly recommends that known exploitation take precedence over EPSS. For findings without that evidence, EPSS helps distinguish candidates for investigation. There is no universal threshold that suits every team or asset. FIRST's guide to using EPSS

Avoid multiplying CVSS by EPSS and presenting the result as a precise risk measurement. The two numbers describe different things, and the product would still omit your deployment and its consequences.

4. Trace the path from input to impact

For each affected component, ask how an attacker could reach the vulnerable behavior.

Does it process public requests, uploaded files, webhook payloads, or messages from another service? Is the affected feature enabled? Does the attack require an account, and can anyone create one? Could an attacker reach the component after compromising another part of the system?

“Internal” is useful context, but it needs a specific explanation. Likewise, “development dependency” describes how a package is used, not whether that use is safe. Consider a hypothetical parser that processes untrusted pull-request content in CI. If that job also has deployment credentials, the build environment deserves attention even though the parser never ships to the browser.

Be careful with reachability results. Evidence that a vulnerable function is not called can support a decision, but dynamic loading, alternate entry points, or incomplete analysis can leave uncertainty. Record what was checked and what was not.

Then describe the consequence in terms the team can act on: access to customer records, ability to change another user's data, compromise of release artifacts, or loss of an essential service. This is also where tested controls matter. A rule that blocks the relevant traffic may reduce exposure; an unverified assumption that “the firewall handles it” should not.

A real example: the Next.js middleware bypass

CVE-2025-29927 is a useful historical example because the deployment model changed the assessment. The maintainer's advisory describes an authorization bypass when checks occur in Next.js middleware. It lists fixes in 12.3.5, 13.5.9, 14.2.25, and 15.2.3 for their respective release lines. It also documents an interim workaround that prevents external requests carrying the x-middleware-subrequest header from reaching the application. Next.js security advisory

The vendor's postmortem distinguishes affected self-hosted deployments from static exports, which do not run middleware. It also explains why Vercel's deployment architecture was unaffected and recommends against relying on middleware alone to protect routes. Vercel's postmortem

That gives a developer concrete questions to investigate: Which build is running? Is there a server runtime? Where are authorization checks enforced? What infrastructure does the application actually use?

The versions above are historical fixes for this one CVE, not recommendations for a new deployment today. Select a currently supported release that addresses subsequent advisories as well. A vendor's statement about one hosting architecture or one vulnerability should not become a blanket exemption from future upgrades.

5. Turn the assessment into a decision

For a small team, start with a few explicit outcomes instead of inventing a complicated weighted score. The following is a suggested workflow, not an official CISA or FIRST classification:

• Urgent response: An affected system has credible exploitation evidence and a viable attack path, or the possible consequence demands immediate action. Escalate to the responsible owner, reduce exposure, and arrange a tested fix. If there are signs of compromise, involve incident response rather than treating patching as the whole answer.
• Scheduled remediation: The vulnerability is applicable, but the evidence supports a planned change. Give it an owner, a target date consistent with your organization's requirements, and a verification step.
• Documented deferral: A specific, evidenced reason supports waiting. Record who accepts the remaining risk, when the decision expires, and what would reopen it.
• Not affected: The evidence establishes that this asset does not meet the advisory's affected conditions. Preserve that evidence and revisit it if the build or configuration changes.

Keep uncertain findings visible until someone resolves them. A serious new advisory may justify precautionary action before the investigation is complete.

Try the workflow on three hypothetical findings:

1. A high-severity vulnerability is confirmed in a public service, appears in KEV, and has no effective mitigation. Start the urgent response here.
2. A critical-severity alert names a library that is absent from the deployed artifact. Verify the build evidence, then close that asset's finding as not affected. Check separately whether the library is used in CI.
3. A medium-severity issue affects an internal worker that handles untrusted uploads. Investigate its input path and privileges before assigning a routine deadline. The medium label does not settle the decision.

Change the facts and the order can change. That is why the reasoning belongs in the ticket.

6. Verify the fix and keep deferrals alive

A merged upgrade PR is one step. Verify that the intended artifact reached every affected deployment, the fixed version or vendor-supported configuration is active, and relevant behavior still works. Re-scan where useful, but retain deployment evidence as well as the scanner result.

If a patch is unavailable or disruptive, evaluate the vendor's mitigation, removal of the affected feature, or a reduction in exposure. Test the control against the relevant path in an authorized environment, including any route that bypasses a proxy. Keep the permanent remediation task open with an owner and review date.

Use a short triage record that another developer can understand:

• Finding: CVE, advisory link, and assessment date.
• Asset: service, environment, deployed version, and artifact identifier.
• Applicability: affected configuration and supporting evidence.
• Threat: exploitation evidence, KEV status, and dated EPSS probability if used.
• Exposure and consequence: reachable inputs, required access, and what could be lost.
• Decision: action, owner, deadline, and any accepted uncertainty.
• Verification: deployed fix or tested mitigation, plus evidence.
• Recheck triggers: expiry date, revised advisory, new exploitation evidence, or a relevant deployment change.

The useful outcome is a queue whose order you can explain. Start with what you run, investigate the path an attacker would need, and give exploitation evidence and real consequences their proper weight. The highest severity score will sometimes come first. When it does not, you should be able to show why.