Your CVE is reachable. But is it exploitable?

What it is

The post separates reachability (your code can execute the vulnerable function) from exploitability (an attacker can meet the conditions the bug needs). It uses lodash CVE-2021-23337, a command injection in _.template, to show that one CVE can need three different responses. It then shows how a second lodash CVE, CVE-2026-4800, can change a verdict without any change to the calling code.

How it works

In CVE-2021-23337, lodash inserts the variable option into the function's source without sanitizing it. An attacker who controls that option can pass code instead of a variable name, and the code runs when the template compiles. Versions before 4.17.21 are affected. The CVSS score is 7.2. As of October 2026, EPSS is about 21% (higher than 97% of scored CVEs), and the CVE is not on KEV. None of these scores reflect how an app uses the function.

The 2021 fix validated variable but missed the key names in options.imports, which feed the same Function() constructor. That gap became CVE-2026-4800, fixed in lodash 4.18.0.

Preconditions / Affected

The post's three example apps all use a vulnerable lodash:

• App A never calls _.template. Reachability analysis alone clears it.
• App B calls _.template with a hardcoded template and options. It is reachable but not exploitable, so it can be downgraded with a written reason.
• App C spreads request data into the template options. Attacker input reaches variable, so the finding stays high or is raised.

App B can still become exploitable. _.template copies inherited properties into imports, so prototype pollution anywhere else in the app lets an attacker populate imports without any change to App B's template code. That makes it an exposure to CVE-2026-4800, not CVE-2021-23337.

What to do

• Treat a "not exploitable" verdict as true only for the code and deployment as they stand. The post names a new call site, a new input path, a config change, or a base image update as things that can flip it.
• When triaging a reachable CVE, check whether attacker input can reach the vulnerable parameter. Also check which configuration and deployment conditions the bug needs.
• Record the reason for each downgrade or dismissal. CISA's VEX justifications distinguish "vulnerable code not in execute path" (reachability) from "vulnerable code cannot be controlled by adversary" (exploitability).
• For lodash, 4.18.0 is the version that fixes the second path.

Caveats

The post is from Aikido and ends by describing its CVE Exploitability Analysis. That tool reads repository code and container context (Dockerfile, base image, distro, runtime), and its agent can ignore, snooze, downgrade or upgrade findings, with written reasoning for a reviewer to approve. The post gives no accuracy or false-negative data for it. It also does not say how the prototype pollution scenario would be detected.