Fix a vulnerable dependency

From a squiggle in package.json to a merged upgrade, including the transitive case.

The direct case

You open package.json and a line is underlined:

lodash@4.17.20 — 7 vulnerabilities (2 critical, 3 high). Safe: 4.17.21

1. Put the cursor on the line and press Ctrl+. for the quick fixes.
2. Choose Bump to 4.17.21.
3. The version in package.json changes. Undo works normally.
4. Accept the offered task to run npm install, or run it yourself. Only the package manager can write a correct lockfile, so the extension will not fake one.
5. The finding clears on the next check.

Deciding whether to upgrade at all

Before spending an afternoon on it, open the finding for the exploit picture. A theoretical critical in a code path you never call is different work from a weaponised high with confirmed exploitation.

The things that decide it:

• KEV membership. Confirmed exploitation in the wild. Do it now.
• Exploit maturity. Weaponised means working exploit code exists.
• EPSS. Probability of exploitation in the next 30 days.
• Reachability, if you are signed in. Whether the vulnerable function is called from your code at all.

The transitive case

The harder one. The underline is on your lockfile and the package is something you never added:

qs@6.5.2 — 1 vulnerability (high)
introduced via express@4.17.1 → qs@6.5.2

You cannot upgrade qs; you did not ask for it. Three ways out, in order of preference.

Upgrade the parent. If a newer express depends on a fixed qs, that is the clean fix and it is what the quick fix offers.

Override it. If no parent release helps, force the version. The extension writes the right form for your package manager:

// package.json
{ "overrides": { "qs": "6.5.3" } }

Yarn calls it resolutions, Go uses replace, Cargo uses [patch]. An override is a commitment: you are asserting the parent works with a version it was not tested against. Verify it.

Accept it, on the record. If neither works, mark it not affected with a justification rather than leaving it to nag. See triage a finding.

Several at once

The Remediation view lists every fixable package grouped by manifest. Tick the ones you want, preview the combined diff, apply once, run one install.

Grouping by manifest matters: five npm upgrades are one change and one install, not five.

When there is no fix

Sometimes there is no fixed release. The extension says so rather than inventing one, and offers what exists: configuration workarounds with effectiveness ratings, upstream commits merged but unreleased, distribution backports, and guidance for defending against the weakness class generally.