[Bug] satisfiesRange ignores the 0.x caret rule, so ^0.25.0 admits 0.26.0 and up

[MRX-72]

Summary

satisfiesRange() treats ^ as "same major, >= floor". That's right for ^1.2.0 but wrong for 0.x: npm resolves ^0.25.0 to >=0.25.0 <0.26.0, because with a zero major the minor is the breaking position. The caret branch only compares majors, so 0 === 0 matches every 0.y.z above the floor.

src/utils/version.ts:223:

if (trimmedRange.startsWith("^")) {
  ...
  return vMajor === tMajor;   // true for every 0.x
}

isBreakingUpgrade() in the same file already handles the 0.x rule (from #990). satisfiesRange() never got it. The ~ branch is fine, it compares major and minor.

Actual vs expected

satisfiesRange("0.26.0", "^0.25.0") -> true    npm: false
satisfiesRange("0.99.0", "^0.25.0") -> true    npm: false
satisfiesRange("0.3.0",  "^0.2.3")  -> true    npm: false
satisfiesRange("0.0.4",  "^0.0.3")  -> true    npm: false
satisfiesRange("0.25.1", "^0.25.0") -> true    npm: true   (fine)

Why it matters

satisfiesRange is the semver oracle for four OA rules, and caret pins on 0.x are common in overrides (esbuild and its @esbuild/* platform binaries, vite plugins, most of the current toolchain).

The one that bites hardest is OA010. admitted-scan.ts:73 builds the admitted set with published.filter(v => satisfiesRange(v, range)), so for "esbuild": "^0.25.0" it admits every published 0.26.x, 0.27.x, ... and then reports "this floor admits vulnerable esbuild@0.2X.Y" for versions npm can never resolve under that override. False positive on a rule whose whole job is judging a floor.

Same wrong answer reaches OA006 (oa006:144, "installed copy is consistent with the pin"), OA005 (oa005:165) and OA008 (oa008:38), in the false-negative direction.

Reproduction

import { satisfiesRange } from "./src/utils/version.js";
satisfiesRange("0.26.0", "^0.25.0");  // true, npm says false

Fix

Take the ceiling from the leftmost non-zero component of the target: major > 0 -> same major; 0.y.z with y > 0 -> same major and minor; 0.0.z -> exact match.

tests/utils/version-extensions.test.ts only covers ^1.2.0, which is why this went unnoticed. Worth a 0.x case per branch.

Environment

Node v26.7.0, macOS, npm, cve-lite-cli 1.35.0 (main @ dad43cd). Pure version logic, no lockfile involved.

---

Separate but adjacent: the same function's doc comment promises pre-release exclusion it doesn't implement (coerceVersion strips the tag, so satisfiesRange("1.0.0-beta", "^1.0.0") is true; npm says false). Different branch, different fix. Say the word and I'll file it on its own.

Happy to pick this up if you want a PR.

[prx-my]

@MRX-72 Hopefully i was able to match the standards for the delivery with the clean implementation, do let me know if i can fix something

[MRX-72]

@prx-my solid work, the fix checks out, I diffed satisfiesRange on your branch against npm's
semver over a 464-pair differential matrix (16 caret ranges × 29 versions). Every
full X.Y.Z caret case matches npm, including the issue's table (0.26.0/^0.25.0 →
false, 0.25.10/^0.25.0 → true), and the other operators (~, >, <, >=, <=, =,
exact, compound) match across 261 more pairs. Full suite is green: 145 suites /
1935 tests. Clean change, +20/−4.

One edge case to close before merge: partial caret ranges. coerceVersion pads
^0 → 0.0.0, so the new else branch treats ^0 and ^0.0 as exact matches.
npm handles them differently:

range	npm meaning	example
^0	>=0.0.0 <1.0.0 (any 0.x)	satisfiesRange("0.25.0", "^0") → false (npm true)
^0.0	>=0.0.0 <0.1.0 (0.0.x)	satisfiesRange("0.0.1", "^0.0") → false (npm true)

So ^0 is a regression — the old code returned true there, matching npm.

Fix: count the components of the original range token, not the coerced target
(coerceVersion pads it, erasing the partial forms):

const parts = trimmedRange.slice(1).split("-")[0].split(".");
if (tMaj > 0) return vMaj === tMaj;                                                // ^1, ^1.2, ^1.2.3
if (tMin > 0) return vMaj === tMaj && vMin === tMin;                                // ^0.1, ^0.1.x
if (parts.length >= 3) return vMaj === tMaj && vMin === tMin && vPatch === tPatch;  // ^0.0.3 exact
if (parts.length === 2) return vMaj === tMaj && vMin === tMin;                      // ^0.0  -> 0.0.x  <-- new
return vMaj === tMaj;                                                               // ^0    -> all 0.x  <-- new

I applied this on top of your branch and re-ran the differential across 19 caret
ranges × 29 versions (including ^0, ^0.0 and the "^ 0.25.0" forms) — 0
mismatches, full suite still passes. Worth adding ^0 / ^0.0 rows to the caret
tests.

Minor (optional): the docstring at src/utils/version.ts:222 still says "^ caret: same
major, >= specified, < next major", now stale for the 0.x branches you added.

[prx-my]

sure @MRX-72 im raising a pr in few mins, thanks for the edge case, i missed it ... hope it will get covered by the next commit

[prx-my]

@sonukapoor if any issue with the pr, let me know, i will get it done by today