Your CVE is reachable. But is it exploitable?

Any SCA tool worth its salt has reachability analysis these days. When a dependency has a known vulnerability, these tools can tell you whether your code calls the affected function. This is pretty much non-negotiable because it helps teams focus their security efforts instead of sifting through noise. Every other step in prioritizing dependency CVEs builds on it.

But just because the vulnerable function is reachable doesn’t mean it’s exploitable. Reachability means your code can execute the vulnerable function, while exploitability means an attacker can satisfy the necessary conditions the bug needs to do damage.

So engineering teams that only have reachability analysis still have to either manually trace which CVEs are actually a problem or figure out which findings are the most urgent ones. Plenty of teams skip manual triage entirely and just patch everything above a CVSS threshold, which is where the noise and wasted effort come from.

Let’s look at how exploitability analysis takes reachability analysis further.

What is reachability analysis?

Most teams rank CVEs by CVSS severity, often through the default labels their security tools show, and some add EPSS and KEV on top (glossary at the bottom for the acronyms). These signals describe the CVE in general and give every app that uses the package the same score, so they don’t say anything about how it behaves in your code.

Reachability analysis checks whether your code can execute the vulnerable function in a dependency, usually by mapping how your code calls into its dependencies as a call graph. If a vulnerable function never gets called, there's virtually no harm (unless the app changes). 

Before reachability analysis, SCA tools flagged every CVE in every dependency, including transitive packages your code didn’t even call. Teams either patched everything above a CVSS threshold or triaged by hand. Reachability changed that by tying each finding to your actual code, so engineers could spend their time on findings that matter in production. It turned a dependency alert queue into something they could actually work through.

Reachability works at two levels. 

• Dependency-level reachability checks whether your code imports or uses the vulnerable package at all. This filters out packages that only sit in your lockfile as unused transitive dependencies. 
• Function-level reachability goes further and checks whether your code calls the specific function containing the bug, so an app that only uses an XML library to generate documents gets cleared for a CVE in that library’s parser.

Why reachable code can still be safe

However, reachable code isn’t necessarily exploitable. Reachable code can still be safe when an attacker can’t meet the conditions the bug needs to fire. Most vulnerabilities need more than the function running. They need attacker-controlled input to reach it in a specific shape, a certain configuration or feature to be turned on, a particular privilege level, or a deployment where the result can actually hurt you.

CISA's VEX (Vulnerability Exploitability eXchange) status justifications list "vulnerable code not in execute path" and "vulnerable code cannot be controlled by adversary" as separate reasons a product isn't affected. The first describes a reachability verdict and the second an exploitability verdict.

What makes a CVE exploitable in an app

An exploit usually depends on several things being true at once, so if one of them is missing in your app, attacks will fail. CVSS captures some of these conditions in its exploitability metrics, like privileges required and user interaction. Your app’s real exposure can sit well above or below the published score.

Reachability vs exploitability in one lodash CVE

CVE-2021-23337 is a command injection in the JavaScript utility library, Lodash. The vulnerability lives in lodash's _.template affecting versions before 4.17.21. lodash inserts a value into the function’s source code without sanitizing it, so an attacker who controls that option can pass code instead of a variable name and run it when the template compiles.

This CVE has a CVSS score of 7.2 and, as of October 2026, an EPSS score of about 21%, higher than 97% of scored CVEs. It isn’t on KEV. Those numbers look scary, but this information is, of course, totally independent of the context of your app. 

Let's look at three apps that all depend on a vulnerable lodash version, but have different reachability and exploitability.

• App A never calls _.template and only uses collection utilities like map and filter. Reachability analysis can dismiss this finding because the vulnerable function never runs.
• App B calls _.template to render an email, with the template string and options hardcoded by the developer. Reachability flags it, since the function runs on every request. An attacker can't influence the variable option, though, so exploitability analysis can downgrade the finding with a written reason.
• App C spreads request data into the template options. The function is reachable, and attacker input reaches the variable option, so the finding stays high. Exploitability analysis would raise the severity or priority of the issue.

The same CVE requires different responses depending on the application. 

Exploitability can change as your code changes

If an exploitability analysis tool says your code is "not exploitable", it only reflects your code and deployment as they stand today. A new call site, a new input path, a config change, or a base image update can flip that verdict.

Lodash's 2021 fix added validation for the variable option but missed options.imports key names, which feed the same Function() constructor. That second path became CVE-2026-4800, fixed in lodash 4.18.0.

So in the example earlier, prototype pollution somewhere else in the application could change App B’s exploitability. Prototype pollution lets an attacker add properties to Object.prototype (which, if you’re not a JS dev, is what nearly every JavaScript object inherits from). _.template copies inherited properties into imports, so a prototype pollution bug anywhere else in App B could give an attacker that path without any change to App B's _.template code.

How Aikido checks CVE exploitability

Aikido’s CVE Exploitability Analysis reads the repository code along with linked container context, including the Dockerfile, base image, distro, and how the container is running. It uses Aikido Agent, which reads how the vulnerable package is used in your code or container image and decides whether the finding is exploitable in your environment. The agent then takes the triage actions you allow, which can be ignore, snooze, downgrade, or upgrade. Each decision comes with the agent's written reasoning, which the reviewer can read before approving.

Before ranking a reachable CVE, someone has to find out whether attacker input can get to the vulnerable parameter and what your config and deployment need to look like for the bug to fire. CVE Exploitability Analysis runs that check for every CVE in scope and records the reasoning behind each verdict.

You can turn on CVE Exploitability Analysis for your repositories and linked containers from Aikido's Triage settings. The setup guide walks through choosing a scope and the actions the agent can take.

FAQ

What is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a unique ID for a publicly disclosed security vulnerability, such as CVE-2021-23337. MITRE runs the CVE program, and authorized organizations called CVE Numbering Authorities assign the IDs, so every tool and advisory can refer to the same flaw by the same name.

What is CVSS?

CVSS (Common Vulnerability Scoring System) rates how severe a vulnerability is on a 0 to 10 scale, based on the flaw itself. FIRST maintains the standard, now on version 4.0, and scores map to severity labels from low to critical. A CVSS score describes the vulnerability in general, so it can’t account for how your app uses the affected code.

What is EPSS?

EPSS (Exploit Prediction Scoring System) estimates the probability that a CVE will be exploited somewhere in the wild in the next 30 days. FIRST publishes a score between 0 and 1 for each published CVE and updates it daily. A high EPSS score signals attacker interest across the internet, but it can’t tell you whether your own app is exposed.

What is KEV?

KEV is CISA’s Known Exploited Vulnerabilities catalog, a list of CVEs with confirmed exploitation in the wild. US federal agencies must fix KEV-listed CVEs by set deadlines under Binding Operational Directive 22-01, and CISA recommends every organization use the catalog to prioritize patching. As of October 2026, it lists about 1,700 CVEs.