---
name: vulnerability-paths
description: >-
  Use when the user asks "how does this vulnerability get into my project", "show me the path
  to this CVE", "which dependency pulls in this vulnerable library", "trace the vulnerable
  dependency chain", "where does this vulnerability come from", or wants the dependency chain
  from a project root artifact down to each transitively vulnerable node — not just a flat
  list of CVEs.
disable-model-invocation: true
---

# Vulnerability Paths

Show the dependency path from a project root Maven GAV to each vulnerable transitive node — so
a CVE deep in the tree can be traced back to which direct dependency pulls it in.

## Steps

1. Parse `groupId`, `artifactId`, `version` for the project root (all required — this tool
   needs one specific, already-known version of the artifact whose transitive tree should be
   checked).

2. Call **`get_vulnerability_paths`** with `groupId`, `artifactId`, `version`.

3. Present each hit in `vulnerabilityPaths`:
   - `vulnerableNode` — the vulnerable `{groupId, artifactId, version}`
   - `path` — the dependency chain from the project root to that node, e.g.
     `spring-boot-starter-web:2.5.0 → spring-boot-starter:2.5.0 → spring-boot-starter-logging:2.5.0
     → logback-classic:1.2.3` (render as an arrow chain or indented tree)
   - `vulnerabilities` — same shape as `get_dependency_vulnerabilities`: `id`, `severity`,
     `summary`, `fixedVersion`. Sort CRITICAL → HIGH → MEDIUM → LOW → unknown. Call out
     `malicious: true` findings separately and first.

   **No hits:** say so plainly — an empty `vulnerabilityPaths` means no known vulnerability was
   found anywhere in the graph; it is NOT a safety guarantee (same OSV coverage caveat as
   `get_dependency_vulnerabilities` — coverage is incomplete and reporting lags disclosure).

   If `unreachableVulnerabilities` is present, mention those separately: a vulnerable
   coordinate exists in the graph but no path from the root could be computed (rare — usually
   a sign the graph itself was truncated or degraded; see `partial`/`truncated` below).

   If `partial: true` or `truncated: true` — say the result is incomplete (deps.dev/OSV
   unreachable, the graph was truncated by the node cap, or the unique-dependency count was
   truncated before querying OSV — see `notes[]` for which).

## Constraints and non-goals

- Not for a flat CVE list with no path context — use `/dependency-vulnerabilities` (specific
  named coordinates) or `/check-deps-vulnerabilities` (whole project scan).
- Not for the full transitive graph with no vulnerability filter — use `/transitive-graph`.
- One project root per call — does not union multiple direct dependencies like
  `/dependency-conflicts` does.

## Known limitations

Same deps.dev isolation caveat as `/transitive-graph`: resolved in isolation from this one
root — project-level `dependencyManagement`, Gradle `ResolutionStrategy` / strict versions /
exclusions are not modeled. When more than one path reaches a vulnerable node, only the
SHORTEST is reported (not every path).

## Fallback (MCP unavailable only)

No practical manual fallback — reconstructing a transitive Maven/Gradle resolution plus
cross-referencing OSV by hand is impractical to reproduce correctly. Tell the user the live
path computation is unavailable rather than guessing at transitive contents or CVE status.