suggestedFixCommands emits a version that does not exist (cross-wired from another finding)

[alamb-hex]

Summary

suggestedFixCommands produced an install command pinning axios@4.0.6. That version does not exist — axios has never published a 2.x, 3.x or 4.x. 4.0.6 is the latest version of form-data, a different package in the same scan result.

Running the emitted command fails outright.

Version: 1.29.0 · Package manager: npm

Reproduction

Scan a project whose direct dependencies include axios@1.16.1 and js-yaml@4.1.1, and which pulls form-data@4.0.5 transitively via axios. All three are flagged.

Actual

"suggestedFixCommands": {
  "packageManager": "npm",
  "command": "npm install axios@4.0.6 js-yaml@4.3.1",
  "sections": [
    { "key": "urgent:high", "targets": [
      { "package": "axios", "currentVersion": "1.16.1", "targetVersion": "4.0.6", ... }
    ]}
  ]
}

$ npm view axios@4.0.6 version
npm error code E404

$ npm view axios dist-tags --json
{ "next": "1.7.0-beta.2", "old-version": "0.30.0", "v0x": "0.33.0", "latest": "1.19.0" }

$ npm view form-data version
4.0.6          # <- where 4.0.6 comes from

Expected

npm install axios@1.19.0 js-yaml@4.3.1

axios@1.19.0 is the latest 1.x and clears all ten axios advisories in the scan. It also pulls form-data to 4.0.6 transitively, so the third finding resolves without needing its own entry.

Notes

• The js-yaml target (4.3.1) was correct, so the failure mode is a partially-valid command that dies on the first package rather than one that is obviously malformed.
• Suspect the target-version resolution is index-aligned against the findings array rather than keyed by package name: axios is finding Add GitHub Discussions or clarify support path in README #1, form-data is finding Document known lockfile edge cases #3, and axios received a version belonging to another finding. Worth checking whether a two-finding scan mis-assigns in the same way.
• Consequence beyond the failed install: the command implies axios needs a three-major upgrade, which reads as a breaking change requiring review. The real fix is an in-major patch. That is the difference between "schedule this" and "apply this now" for a set of high-severity advisories.

Observed on two independent repos with identical dependency sets, so it is deterministic rather than a one-off.

[sonukapoor]

Thanks @alamb-hex, great catch and excellent diagnosis. You're right on the root cause - the target version resolution is index-aligned against the findings array instead of being keyed by package name, so versions drift when findings don't map 1:1 across the arrays.

Happy for you to take this one. The fix should be in the suggestedFixCommands path - switch from positional array indexing to a package-name keyed lookup so each finding always gets its own validated fix version.