[Bug] compareVersions ranks a pre-release above its release, so a pre-release install before the fix is reported not vulnerable

[cnYui]

Summary

compareVersions in src/utils/version.ts ranks a pre-release above its associated release, inverting semver §11.3 ("a pre-release version has lower precedence than the associated normal version"). Because versionMatchesRange in src/advisory/local-db.ts short-circuits on compareVersions(version, fixed) >= 0, an installed pre-release that sits before the fix version is silently classified as not vulnerable.

That is a false negative in a vulnerability scanner, so I am reporting it rather than sitting on it.

Root cause: parseVersionTuple splits on /[.+-]/ into one flat tuple, and compareVersions pads the shorter tuple with the number 0. A pre-release tag therefore ends up compared against 0 as a string, and "beta".localeCompare("0") is 1.

// src/utils/version.ts L28-38
const len = Math.max(pa.length, pb.length);
for (let i = 0; i < len; i++) {
  const av = pa[i] ?? 0;
  const bv = pb[i] ?? 0;
  ...

Pre-releases do reach the matcher: findMatchingVulnerabilityIds gates only on looksLikeVersion, whose regex ^[0-9]+\.[0-9]+\.[0-9]+(?:[-+][^/]+)?$ explicitly admits them. isPreReleaseVersion is applied only to candidate fix versions in the remediation path, never to the installed version.

Environment

• OS: Windows 11
• Node.js version: v24.11.0
• Package manager: npm 11.6.1
• Lockfile type: n/a (defect is in the version comparator, reproducible directly)
• CVE Lite CLI version: 1.33.0 (main @ 16d746c)

Command used

npx tsx repro.ts

Expected behavior

Per semver §11.3, 1.2.3-beta.1 < 1.2.3, so an advisory with fixed: "1.2.3" should still report an installed 1.2.3-beta.1 as vulnerable — the fix has not landed in that build.

Actual behavior

compareVersions("1.2.3-beta.1", "1.2.3") returns 1, and the advisory matcher reports 1.2.3-beta.1 as not vulnerable.

Reproduction

repro.ts at the repo root — it imports the real compareVersions / looksLikeVersion and inlines the exact body of versionMatchesRange (src/advisory/local-db.ts L215-233) so the matcher can be exercised without a sqlite database:

import { compareVersions, looksLikeVersion } from "./src/utils/version.js";

function versionMatchesRange(version: string, row: { introduced: string | null; fixed: string | null; last_affected: string | null }): boolean {
  const introduced = row.introduced;
  const fixed = row.fixed;
  const lastAffected = row.last_affected;
  if (introduced && introduced !== "0" && compareVersions(version, introduced) < 0) return false;
  if (fixed && compareVersions(version, fixed) >= 0) return false;
  if (lastAffected && compareVersions(version, lastAffected) > 0) return false;
  return true;
}

console.log(looksLikeVersion("1.2.3-beta.1"), "beta".localeCompare("0"));
console.log(compareVersions("1.2.3-beta.1", "1.2.3"));
const row = { introduced: "1.0.0", fixed: "1.2.3", last_affected: null };
for (const installed of ["1.2.2", "1.2.3-beta.1", "1.2.3-rc.2", "1.2.3"]) {
  console.log(installed, versionMatchesRange(installed, row));
}

Relevant files or output

looksLikeVersion('1.2.3-beta.1') = true
"beta".localeCompare("0")        = 1

compareVersions('1.2.3-beta.1','1.2.3') = 1   (semver 11.3 requires < 0)
compareVersions('1.2.3','1.2.3-beta.1') = -1  (semver 11.3 requires > 0)
compareVersions('2.0.0-rc.1','2.0.0')   = 1   (semver 11.3 requires < 0)

advisory { introduced: '1.0.0', fixed: '1.2.3' }
  installed 1.2.2          -> reported vulnerable: true
  installed 1.2.3-beta.1   -> reported vulnerable: false   <-- wrong, the fix is in 1.2.3
  installed 1.2.3-rc.2     -> reported vulnerable: false   <-- wrong
  installed 1.2.3          -> reported vulnerable: false

The same inversion reaches the online npm-advisory path at src/remediation/npm-registry.ts L404-408 (upperBoundOk), and affects compareVersions used as a sort comparator at L178 / L261-262.

Notes for whoever picks this up:

• Nothing in tests/ pins the current behavior. The only pre-release assertion is tests/helpers.test.ts L351, compareVersions("1.2.3-beta", "1.2.3-alpha") > 0, which stays true under a semver-correct comparator.
• Fixing it is contained to src/utils/version.ts; the two consumers become correct without edits.

I have a fix ready and will open a PR against this issue.

[sonukapoor]

Thanks for this, it's an unusually good report. You diagnosed it to the exact comparison and you were right that nothing in the suite pins the broken behaviour.

I reproduced all of it. For anyone reading later, the concrete damage offline:

installed next@15.2.3-canary.0
  [15.0.0, 15.2.3)  -> not detected   GHSA-f82v-jwr5-mffw (CVE-2025-29927)
  [15.2.3, 15.2.4)  -> DETECTED       wrong advisory

A canary that does not contain the fix gets treated exactly like 15.2.3 which does, so we clear a critical auth bypass and report an unrelated CVE in its place. That makes this the top of the bug queue.

Two corrections to the write-up, both in your favour.

npm-registry.ts:404-408 is not actually reachable with a pre-release. Those candidates are already filtered by .filter(v => !isPreReleaseVersion(v)) at line 260, so nothing gets through. But there is a real problem in that file, one branch earlier: publishedVersions at line 176 has no such filter, so the nearest-published-version lookup at line 192 can return 1.2.3-rc.1 for an advisory fixed in 1.2.3. That one hits online users too. I have split it out as #1082 so please leave it alone here, otherwise the two fixes tangle.

Second, there is an adjacent bug you did not mention: build metadata is not ignored either, so compareVersions("1.2.3+build.5", "1.2.3") returns 1 where semver §10 wants 0. Same root cause, the + in the split regex. Worth fixing in the same pass.

A few things I will be looking for on the PR:

• No new runtime dependency. Please do not pull in semver. We ship four runtime deps and the small footprint is a deliberate product decision, so this needs to be hand-rolled.
• Keep the memoisation added in perf(version): cache parsed version tuples in compareVersions #740. The comparator is on a hot path.
• Cover §11.3, §11.4.3 and §11.4.4, plus build metadata, plus versionMatchesRange with a pre-release install.

One consequence to call out in the PR description: offline scans will now correctly report more findings for pre-release installs, so anyone on a canary or rc with a --ratchet baseline may see new findings and need to regenerate. That is the fix working, but it should not surprise people.

Go ahead and open it whenever you are ready.

[sonukapoor]

Cross-reference: fixing this comparator also completes #1083.

#1083 scopes the reported fix version to the OSV range containing the installed version. Its window check calls compareVersions(installedVersion, fixed), so for a pre-release install the window match fails and selection falls back to the global minimum, which is a downgrade.

Measured against the #1083 fix as it stands:

installed 15.2.2           -> 15.2.3   correct
installed 15.2.3-canary.0  -> 14.9.9   wrong, should be 15.2.3

No change is needed in #1083 for this. Once the comparator here is semver-correct, that case resolves on its own. Worth re-running it as part of verifying this fix.

[sonukapoor]

@cnYui, I owe you a straight explanation. I told you to go ahead and open a PR, and a few hours later #1084 landed from someone else covering the same ground. I merged it rather than sit on a live false negative over the weekend. That is not how I wanted this to go.

To be clear about what you contributed: you found it, you diagnosed it to the exact comparison and the exact clause, you checked that no existing test pinned the behaviour, and you identified both consumers. That report is why this got fixed today rather than in six months. The one thing you had slightly off, the npm-registry.ts:404 line, turned out to point at a real bug one branch earlier.

If you are still up for contributing, #1007 is yours if you want it, and it is close to what you were already looking at: a fix command that pins a version which does not exist, cross-wired from another package in the same scan. Say the word and I will hold it for you.

Either way, thank you for the report.

[sonukapoor]

@cnYui, correcting myself. I offered you #1007 yesterday and I should not have: it was already reported and self-assigned by another contributor back in August, and I did not check before pointing you at it. My mistake, not a change of mind.

Something better suited to you anyway: #1082. It is the one your report led me to, one branch earlier than the line you flagged. resolveLowestKnownNonVulnerableVersion builds its publishedVersions list without filtering pre-releases, then picks the nearest version at or above the advisory's fix hint, so it could return 1.2.3-rc.1 for a fix that landed in 1.2.3.

Since #1084 landed the common case no longer reproduces, because a correct comparator makes that comparison false. But that is incidental: the path still has no explicit intent to exclude pre-releases, so an advisory whose own fixed value is a pre-release still selects one. The sibling path at line 260 already filters correctly, so it is largely a matter of applying the same thing and deciding what should happen in that residual case.

Yours if you want it, and I will assign it so this does not happen twice.

[sonukapoor]

@cnYui, one last note and then I will stop filling your inbox.

I have changed how this project handles issues because of what happened here. We no longer offer issues to specific people or assign them, because assignment clearly did not reserve anything: this one was assigned to you and got picked up anyway. It is first working PR wins now, stated up front, so nobody else gets told an issue is theirs and then watches it go elsewhere.

That does not give you the fix back. What it does mean is that the report gets credited: you will be named in the v1.34.0 release notes as the reporter of the bug #1084 fixed, alongside the author of the fix. Finding it was the hard part.

Worth knowing how far your report reached. It led to three separate fixes, not one. #1084 corrected the comparator. #1085 fixed a second bug it exposed in findFirstFixedVersion, which was recommending a downgrade across a major boundary for a critical finding. And the npm-registry.ts:404 line you flagged, which I told you was not reachable, turned out to point at a real defect one branch earlier that is still live on main and is being fixed in #1096 right now. You were closer to right on that than I was.

No ask attached. If you want to send a PR at something in future, pick whatever is open and send it, and it will get a proper review.