Repository navigation
suggestedFixCommands emits a version that does not exist (cross-wired from another finding) #1007
Description
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 fromExpected
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.
Activity
sonukapoor commentedon Aug 20, 2026
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.
sonukapoor commentedon Sep 6, 2026
@alamb-hex, checking in rather than assuming. You self-assigned #1007 in August and you have both defects on #966, and I have not wanted to tread on either. Both have come up in the last few days.
Straightforward question: are you able to work on these, or would you rather hand them back? Genuinely fine either way. You reported both and diagnosed both precisely, so they are yours if you want them. If you are stretched, say so and I will take them off your list without it counting against you.
One piece of context if you do keep #1007.
findFirstFixedVersionchanged last night in #1085 to scope the reported fix to the range containing the installed version, and the comparator was made semver-correct in #1084. Neither touches your cross-wiring case, which is a different mechanism, but the surrounding code moved, so it is worth re-checking your diagnosis against current main before writing anything.fix: correctly assign targetVersion for parent-update targets
fix(remediation): stop parent-update targets merging into install tar…