Fix a vulnerable dependency

A direct dependency

1. Open the manifest, for example package.json. The vulnerable line has a squiggle and, once safe versions have loaded, a → <version> hint at its end.

2. Hover the line. Check the Exploits section and whether the headline ends in (CISA KEV); that decides how urgent this is.

3. Put the cursor on the line and press Ctrl+. (Cmd+. on macOS).

4. Choose a bump. The first entry is the target for vulnetix.sca.safeHarbourStrategy; up to three alternatives follow, each saying how many known vulnerabilities would remain.

5. The manifest line changes, keeping any range operator (^4.17.20 becomes ^4.17.21). Ctrl+Z undoes it.

6. Save, then update the lockfile with your package manager. The extension does not run it.

   npm install        # or: yarn install, pnpm install, pip-compile, go mod tidy, cargo update

7. The lockfile change is picked up by the file watcher and the finding clears after the re-check.

No quick fix is offered when:

Situation	Why	What to do
Hover says “Pro unlocks Safe-Harbour version recommendations.”	Ranked versions are not on your plan	Choose a version yourself from the advisory
Hover says “Resolving safe versions…”	The lookup for this manifest is still running	Wait a moment and retry
Fix: none available	No release clears Safe Harbour within vulnetix.sca.maxMajorBump	Raise maxMajorBump (a major bump is usually a code change), or see below
Malicious package.	A version bump is not a fix	Remove the dependency
End of life	No further security releases are expected	Plan a migration

Decide how urgent it is

Before you change a version, read the hover card. A theoretical critical in code you never call is different work from an exploited high.

On the hover card	What it tells you
(CISA KEV) at the end of the headline, **CISA KEV** on an advisory line	Exploitation in the wild is confirmed. Fix it now.
Exploits: N known, listed as actively exploited	Public exploit code exists, or the advisory is on the CISA, VulnCheck or EU KEV list
Exploits: none known	Exploit data was checked and none was found
Pro unlocks exploit intel.	Exploit data was not part of the answer on your plan. This is not the same as none known.
EPSS n% on an advisory line	The probability of exploitation in the next 30 days
CVSS n on an advisory line	Base severity score

Reachability (whether your code calls the vulnerable function) is not available in the editor; vulnetix scan signed in reports it.

A transitive dependency

A package you did not declare appears in the lockfile, and the declaring line in the manifest says introduced via <pkg@version> or , including <pkg@version> pulled in transitively. There is no version on the manifest line to bump for it.

In order of preference:

1. Upgrade the parent. If a newer release of the direct dependency pulls a fixed version, bump the parent (by hand, or with its own quick fix when it is vulnerable itself).

2. Force the version with your package manager:

   Ecosystem	Mechanism
   npm	"overrides": { "qs": "6.5.3" } in package.json
   Yarn	"resolutions": { "qs": "6.5.3" } in package.json
   pnpm	"pnpm": { "overrides": { "qs": "6.5.3" } } in package.json
   Go	go get example.com/mod@v1.2.4, which raises the minimum version selected
   Cargo	cargo update -p name --precise 1.2.4

   An override asserts that the parent works with a version it was not tested against. Run its tests.

3. Record why it stays. Suppress it with a reason (see Suppressions), or record a VEX statement with the CLI (VEX).

Many at once

The editor fixes one line at a time. To plan and apply fixes across a repository, use the CLI, which resolves targets the same way and also runs the package manager and rescans:

vulnetix fix --strategy safest --max-major-bump 0 --dry-run   # show the plan
vulnetix fix --strategy safest --max-major-bump 0             # apply interactively

See SCA for vulnetix fix and vulnetix scan --sca-autofix.