--- id: 10084 canonical_url: "https://phying.com/item/10084" title: "Your CVE is reachable. But is it exploitable?" type: "blog" cve: null cvss: null severity: "unknown" vendor: null product: null affected_versions: null source_domain: "aikido.dev" source_url: "https://www.aikido.dev/blog/cve-reachable-vs-exploitable" published_at: "2026-10-18T00:00:00Z" snapshot_at: "2026-10-27T14:53:13Z" archived_by: "Phying News (https://phying.com/item/10084)" lang: "en" --- # Your CVE is reachable. But is it exploitable? *Published on: 2026-10-18 · Source: [aikido.dev](https://www.aikido.dev/blog/cve-reachable-vs-exploitable)* [Blog](https://www.aikido.dev/blog)![](https://cdn.prod.website-files.com/642adcaf364024552e71df01/66734db225dd2cbf1aa7d863_arrow_back.svg)[News](https://www.aikido.dev/category/news)![](https://cdn.prod.website-files.com/642adcaf364024552e71df01/66734db225dd2cbf1aa7d863_arrow_back.svg) Your CVE is reachable. But is it exploitable? # Your CVE is reachable. But is it exploitable? Written by [Dania Durnas](https://www.aikido.dev/team-members/dania-durnas) Published on: Oct 18, 2026 Last updated on: Oct 19, 2026 # 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)](https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex) 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. Condition| What lowers exploitability| Example ---|---|--- Attacker-controlled input| Only developer-controlled values reach the vulnerable parameter| Hardcoded `_.template` options Required configuration or feature flags| The bug needs a setting or module your app doesn't use| [Spring4Shell](https://www.cisa.gov/news-events/alerts/2022/04/01/spring-releases-security-updates-addressing-spring4shell-and-spring-cloud-function-vulnerabilities) needed JDK 9 or later, Tomcat, WAR packaging, and Spring MVC or WebFlux Privileges or authentication| The vulnerable path sits behind login or an admin role| An admin-only endpoint instead of a public signup form User interaction| The vulnerable output never reaches a victim’s browser or device| An XSS bug in an HTML sanitizer used only to generate server-side PDFs Deployment context| Untrusted input can't reach the service, or the platform isn't affected| A parser in an internal batch job only sees data already inside your network Mitigations already in place| A control outside the code blocks the payload| Input validation, web application firewall (WAF) rules, sandboxing, or egress filtering ## Reachability vs exploitability in one lodash CVE [CVE-2021-23337](https://github.com/advisories/GHSA-35jh-r3h4-6jhm) 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. ![Dependency tree showing reachability vs exploitability. An app depends on express, lodash, and xml-builder, and only lodash is reachable. Within lodash, the app calls map and filter, which are unaffected, and _.template, which contains CVE-2021-23337. Hardcoded options leave _.template not exploitable \(App B\), while request data reaching it makes it exploitable \(App C\).](https://cdn.prod.website-files.com/642adcaf364024654c71df23/6ad2a56f744752aa28f9d269_27ac7764.png) 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](https://www.aikido.dev/code/open-source-dependency-scanning-sca) 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](https://help.aikido.dev/aikido-agent/cve-exploitability-analysis), 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. ![Aikido CVE Exploitability History Detail for the sharp package. The agent found the vulnerability reachable through Next.js image optimization and downgraded it from critical to high, because the app runs on Alpine Linux with musl libc and accepts no untrusted AVIF or HEIF uploads.](https://cdn.prod.website-files.com/642adcaf364024654c71df23/6ad2a56f744752aa28f9d26e_7695a48f.png) 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](https://www.cve.org/About/Overview), and authorized organizations called[ CVE Numbering Authorities](https://www.cve.org/ProgramOrganization/CNAs) assign the IDs, so every tool and advisory can refer to the same flaw by the same name. **What is CVSS?** [CVSS](https://www.first.org/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](https://www.first.org/cvss/v4.0/user-guide), 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](https://www.first.org/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](https://www.cisa.gov/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](https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities), and CISA recommends every organization use the catalog to prioritize patching. As of October 2026, it lists about 1,700 CVEs. Share: [](https://www.aikido.dev/blog/cve-reachable-vs-exploitable#)[](https://www.aikido.dev/blog/cve-reachable-vs-exploitable#)[](https://www.aikido.dev/blog/cve-reachable-vs-exploitable#) https://www.aikido.dev/blog/cve-reachable-vs-exploitable [Text Link](https://www.aikido.dev/blog/cve-reachable-vs-exploitable#) ### Subscribe for news 4.7/**5** Tired of false positives? Try Aikido like 100k others. [Start Now](https://app.aikido.dev/login) Get a personalized walkthrough Trusted by 100k+ teams [Book Now](https://www.aikido.dev/book/demo) Scan your app for IDORs and real attack paths Trusted by 100k+ teams [Start Scanning](https://app.aikido.dev/login) See how AI pentests your app Trusted by 100k+ teams [Start Testing](https://app.aikido.dev/login) [Start Now](https://app.aikido.dev/login) [Similar Posts](https://www.aikido.dev/blog/cve-reachable-vs-exploitable#)[See all](https://www.aikido.dev/blog) October 19, 2026 • News ## Yearly pentests can’t keep up. Test more on the same budget 76% of teams ship major changes weekly, but only 21% test every release. Here’s how AI pentesting closes that gap without raising your security budget ![](https://cdn.prod.website-files.com/642adcaf364024552e71df01/6836b17027f911d14ce42ba7_arrow%20right.svg) # AI # AI Penetration Testing # Pentesting [](https://www.aikido.dev/blog/more-pentesting-same-budget-ai) September 23, 2026 • News ## Cyber Resilience Act is here! Myth busting and first impressions The Cyber Resilience Act's first deadline just came up on September 11, 2026. What the new Single Reporting Platform looks like, and four common CRA myths debunked. ![](https://cdn.prod.website-files.com/642adcaf364024552e71df01/6836b17027f911d14ce42ba7_arrow%20right.svg) # Compliance # European Cyber Security # Cyber Resilience Act [](https://www.aikido.dev/blog/cyber-resilience-act-myth-busting-first-impressions) September 10, 2026 • News ## The CVE spike across major software companies is a remediation problem CVE volume is climbing across major software companies, and a federal audit shows even NIST couldn't keep up. Here's why remediation speed, not disclosure count, is the number that actually matters. ![](https://cdn.prod.website-files.com/642adcaf364024552e71df01/6836b17027f911d14ce42ba7_arrow%20right.svg) [](https://www.aikido.dev/blog/cve-spike-remediation-problem) ## Get secure today, quickly and for free. Secure your code, cloud, and runtime in one central system. Connect a repo to discover what the reasoning agents find in your codebase. [Start for Free](https://www.aikido.dev/blog/cve-reachable-vs-exploitable#) No credit card required | Scan results in 32 seconds. Trusted by 150k+ orgs ![](https://cdn.prod.website-files.com/642adcaf364024654c71df23/68f0df51a54a9f5b7497b39e_Revolut%20Logo%20White.svg) ![](https://cdn.prod.website-files.com/642adcaf364024654c71df23/68960390ab7ebe39b3122c27_n8n.svg) ![](https://cdn.prod.website-files.com/642adcaf364024654c71df23/6a1438eb9201010c780f1153_Lovable%20whit.svg) ![](https://cdn.prod.website-files.com/642adcaf364024654c71df23/697ca64e980facdb570df824_deel.svg) ![](https://cdn.prod.website-files.com/642adcaf364024654c71df23/69a94cf424da41df3e2eaab6_Prove%20white.svg) ![](https://cdn.prod.website-files.com/642adcaf364024654c71df23/6a3538e16f173af4a9e55082_omnea%201.svg) --- > 📦 **Full-Text Markdown Snapshot** archived by [Phying News](https://phying.com/item/10084) · Original source: [aikido.dev](https://www.aikido.dev/blog/cve-reachable-vs-exploitable)