Reachable medium or unreachable critical: which do I fix first?

In most cases, fix the reachable medium flaw first. A medium flaw your code actually calls, on a service outsiders can reach, is a live path. A critical flaw in code you never call has no path today. Two exceptions: if the critical is being used in real attacks, or you cannot confirm it is unreachable, move it up.

TL;DR

• A severity score says how bad a flaw could be. Reachability says whether an attacker has a way to it. You need both.
• Default order: reachable and exploited, then reachable, then unknown, then unreachable.
• An unreachable critical jumps the line when it appears in real attacks, when reachability is unknown, or when the fix is trivial.
• Record why the unreachable critical waits, and set a date to look again.

Definition: reachable. A vulnerable piece of code is reachable when a path exists from your running software to that code. If nothing in your product ever calls the risky function, it is not reachable. If the answer cannot be worked out, it is unknown.

What do "critical" and "reachable" each tell you?

Think of two houses. House one has a weak lock on the back door, but a high wall with no gate surrounds the whole yard. House two has a decent lock, but the door faces a public street. Which door do you fix first? Most people say the street door. The weak lock matters, but nobody can reach it.

That is the same trade. "Critical" is about the lock: how bad would the damage be if someone got through? "Reachable" is about the door: can anyone get to it? The people who maintain the scoring standard, FIRST, say CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk. The score describes the lock, not the street.

A critical score typically reflects factors such as these: the attack can be done over a network, it needs little skill or access, and it gives the attacker a lot. Those are properties of the flaw in general. They are measured without knowing your system. The CVSS specification itself says that consumers should add environmental information, such as what mitigations exist in their setup, to get a score that fits their own situation.

Reachability is that missing environmental fact. It asks whether your own code gets to the vulnerable function. It does not replace severity. A reachable flaw that gives an attacker little still ranks below a reachable flaw that gives total control. But when you compare a reachable medium against an unreachable critical, reachability usually decides.

When should the unreachable critical go first?

There are five situations where the "unreachable" label should not win the argument.

1. The flaw is being used in real attacks. The CISA Known Exploited Vulnerabilities (KEV) catalog lists flaws seen in the wild, and CISA asks organizations to use it as an input to prioritization. If your critical is on that list, attackers are already working on it. Even if you believe the code is not reachable, you may be wrong, so you should confirm quickly and fix in short order.

2. You are not sure it is unreachable. "Not called" can be wrong when code runs through plugins, by name at run time, or through a library you forgot. An analysis result of "unknown" is not "no." For an exploited flaw, treat unknown as reachable. SSVC, a public decision framework, uses the same cautious default for one of its questions: when nothing is known about whether an attacker can automate the attack, assume yes.

3. The fix is trivial. If the fix is a patch release that passes your tests, take it. A ten minute upgrade is cheaper than the meeting about whether to skip it. Reachability helps you decide where to spend scarce effort. It is not a reason to skip a cheap fix.

4. The path will open soon. If a launch next week will expose the affected service to the internet, plan the fix before the launch, not after.

5. A written rule or a customer says so. Some contracts say all critical findings must be fixed in a set time. Reachability can still inform the conversation with the customer, but it will not change what the contract says. Ask for the exact words, and raise it with whoever owns the agreement.

How do the combinations rank?

Use this table as a default order. Your business can tighten it.

Notice two things. First, the table does not put "critical" ahead of "reachable and internet facing." Second, case F is not "ignore." It is "record and recheck," because facts change.

What does this look like with real constraints?

Here is a worked example. All numbers are invented to illustrate the idea.

A team has three developer days to spend on security this sprint. They have two open items.

• Item 1: a flaw in a PDF library, rated critical (9.8). The library is used in a build tool that makes release notes, and nowhere else. No customer input reaches it. Not on KEV. Reachability: not reachable from the shipped product. The fix is a major upgrade that needs about two days of testing.
• Item 2: a flaw in a web framework's cookie handling, rated medium (5.9). The affected function runs on every login request from the internet. Not on KEV, EPSS is moderate. The fix is a minor upgrade that needs about half a day.

The team works out the order. Item 2 is reachable, internet facing and cheap. It goes first. Item 1 does not ship to customers and costs two days. It waits, with a note: "PDF library used in build tooling, not part of the shipped product. Recheck when the tool is moved into the product or when the flaw appears on KEV."

After item 2, the team has two and a half days left. They have a choice: spend them on item 1, or on other reachable findings. Since item 1 is unreachable and has no outside signal, they pick other reachable findings first. They revisit item 1 at the next release.

If the PDF flaw were added to KEV during the week, the team would recheck the "not reachable" evidence that day. If it held, they would still schedule the fix soon, but they would not stop work on item 2.

How do you make the call in five steps?

1. List the two items with the facts. Severity, KEV status, EPSS, reachability result, exposure, and the size of the fix.
2. Check for the five exceptions. Is the critical exploited, unknown, trivial to fix, about to become exposed, or required by a contract?
3. Place each item in the table. Do not skip the "unknown" row. Unknown is a task, not a rank.
4. Pick the order and the budget. Count the effort of each fix and compare it to the time you have.
5. Write down why the loser waits. Add a date, an owner and a recheck trigger.

What can Safeguard do to help with this choice?

Safeguard runs reachability analysis, which traces your own call paths into each vulnerable function, so you can see which findings sit on a live path. Its vulnerability management view gives one queue per product with the signals that set priority and a status for each finding. For fixes, it shows which fixes are available now, grouped into compatible, minor and major upgrades, and marks the ones that may break your code.

Autonomous remediation with fix pull requests is available, but it is off by default and every category starts on Manual, so an administrator decides when to turn it on. The Safeguard CLI can also write code, and you review what it writes as you would any change. Try a free scan at gold.safeguard.sh/scan.

For related reading, see reachability versus EPSS versus CVSS and which signal should drive patching.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how fixes are grouped into compatible, minor and major upgrades, and which ones are marked as likely to break your code.

Quick check

Sources

• FIRST: CVSS v3.1 user guide
• FIRST: CVSS v3.1 specification
• CISA Known Exploited Vulnerabilities Catalog
• SSVC: Automatable decision point
• FIRST: EPSS overview

Last reviewed: 19 October 2026.