fix(remediation): nearest-published-version path can recommend a pre-release below the fix

[sonukapoor]

Follow-up to #1077, split out so that issue stays scoped to the comparator itself.

Problem

resolveLowestKnownNonVulnerableVersion has a second code path that does not filter pre-releases, so it can recommend a version that predates the fix.

src/remediation/npm-registry.ts:176-178 sorts every published version with no pre-release filter:

const publishedVersions = Object.keys(packument.versions ?? {})
  .filter(looksLikeVersion)
  .sort(compareVersions);

Line 192 then picks the nearest version at or above the advisory's fixed-version hint:

const nearestPublishedVersion = publishedVersions.find(version => compareVersions(version, fixedVersionHint) >= 0) ?? null;

Reproduced against the real comparator:

published:           ["1.2.0","1.2.2","1.2.3-rc.1","1.2.4","1.3.0"]
advisory fixed hint: 1.2.3
-> recommends:       1.2.3-rc.1

1.2.3-rc.1 is below 1.2.3 under semver §11.3, so it does not contain the fix. The CLI emits a copy-and-run upgrade command that does not remediate, along with a note presenting it as the nearest published version. This directly contradicts the actionable-output principle: a wrong command is worse than no command.

Note the sibling path at line 261 already gets this right with .filter(v => !isPreReleaseVersion(v)). Only this earlier branch is missing it.

Scope: this affects online mode

#1077's detection false negative is offline-only, because online detection goes through OSV querybatch and the npm bulk advisory endpoint, both server-side and semver-correct. This issue is different: remediation runs against the npm registry for everyone, so a bad fix recommendation reaches all users regardless of --offline.

Relationship to #1077

Fixing the comparator in src/utils/version.ts corrects the ordering but does not fix this on its own. Once compareVersions is semver-correct, 1.2.3-rc.1 >= 1.2.3 becomes false, so .find() would skip it and land on 1.2.4, which happens to be right here. But that is incidental: the path still has no explicit intent to exclude pre-releases, so an advisory whose fixed value is itself a pre-release would still select one. The filter should be explicit rather than emergent.

Sequence: land #1077 first, then this, then re-run the check above.

Suggested fix

Apply the same .filter(v => !isPreReleaseVersion(v)) used at line 261 to the publishedVersions list, and decide deliberately what should happen when the advisory's own fixed value is a pre-release. Add a regression test pinning that a pre-release is never returned as a resolved fix version.

Notes

• In-house: registry call patterns and the fix resolver.
• Related: suggestedFixCommands emits a version that does not exist (cross-wired from another finding) #1007 (suggestedFixCommands emits a version that does not exist) may share this root cause and is worth re-checking once this lands. feat: make --fix / self-fix respect the configured release cooldown (hold back cooldown-window versions) #873 (cooldown-aware fix resolver) edits the same candidate pipeline, so sequence to avoid conflicts.

[sonukapoor]

Severity downgrade now that #1084 has merged.

The common case no longer reproduces. With a semver-correct comparator, 1.2.3-rc.1 >= 1.2.3 is false, so .find() skips the pre-release and lands on the next stable release:

published [1.2.0, 1.2.2, 1.2.3-rc.1, 1.2.4], advisory hint 1.2.3
  -> 1.2.4     (was 1.2.3-rc.1 before #1084)

That happens incidentally rather than by design: the path still has no explicit intent to exclude pre-releases. The residual case is an advisory whose own fixed value is itself a pre-release, where the hint matches exactly and is returned as-is.

So this is no longer a live user-facing bug emitting non-remediating fix commands. It is now a latent correctness gap worth closing deliberately, by applying the same .filter(v => !isPreReleaseVersion(v)) used at line 261, so the behaviour does not depend on a comparator detail elsewhere in the codebase.

[rksharma-owg]

I verified the residual pre-release case on current main at db3f785. I’ll take the narrow scope described here: exclude pre-releases from resolvePublishedFixVersion’s published-version candidates and add focused coverage showing that an exact pre-release hint resolves to the next eligible release. I won’t change the comparator or unrelated remediation behavior.

[sonukapoor]

Correcting my earlier comment on this issue. I downgraded the severity and I was wrong to.

I claimed the common case stopped reproducing after #1084, on the reasoning that a semver-correct comparator makes 1.2.3-rc.1 >= 1.2.3 false. That holds only for a pre-release of the same release. A pre-release of a higher release still satisfies the comparison and is still selected. Verified against current main:

published ["1.2.2", "1.2.4-beta.1"], advisory fixed-version hint 1.2.3
  -> resolves to 1.2.4-beta.1

That reaches the user as npm install <pkg>@1.2.4-beta.1, presented as a verified high-severity fix command. So this is a live defect emitting non-remediating remediation guidance, not the latent correctness gap I described.

The rest of the earlier comment still stands: the residual pre-release-hint case is real, and the sibling path at line 265 already filters correctly. But the framing was wrong and anyone reading this issue should treat it as user-facing rather than theoretical.

PR #1096 addresses it.