Skip to content

fix(security): vuln-scan false positive from declared semver range vs resolved version - #229

Merged
Wolfvin merged 1 commit into
mainfrom
fix/vulnscan-bun-lock-declared-range-false-positive
Jul 12, 2026
Merged

fix(security): vuln-scan false positive from declared semver range vs resolved version#229
Wolfvin merged 1 commit into
mainfrom
fix/vulnscan-bun-lock-declared-range-false-positive

Conversation

@Wolfvin

@Wolfvin Wolfvin commented Jul 12, 2026

Copy link
Copy Markdown
Owner

Found while auditing security --check vuln-scan against KDS backend.

jsonwebtoken was flagged with installed_version: "^9.0.0" against vulnerable_range: "<9.0.0" — but 9.0.0 is not less than 9.0.0, so this is a false positive. Root cause: _parse_bun_lock() collected packages from workspaces.dependencies (declared semver RANGES like ^9.0.0) in addition to packages (resolved concrete versions). _compare_versions()'s digit-extraction regex silently parses ^9 as 0 (no leading digit), making ^9.0.0 compare as 0.0.0 — matching any <X.Y.Z range regardless of actual installed version.

Fix: remove the workspaces.dependencies collection — only packages (resolved) has concrete versions suitable for vulnerability matching.

Verified: total findings 22 → 13, jsonwebtoken false positives (4) eliminated.

@Wolfvin
Wolfvin merged commit c12d760 into main Jul 12, 2026
@Wolfvin
Wolfvin deleted the fix/vulnscan-bun-lock-declared-range-false-positive branch July 12, 2026 05:05
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

… range instead of resolved version

_parse_bun_lock() collected packages from TWO sources: workspaces.dependencies
(declared semver ranges from package.json, e.g. '^9.0.0') AND packages
(resolved concrete versions from the lockfile, e.g. '9.0.2'). Both were fed
into the same vulnerability-matching loop as if they were equally valid
'installed versions'.

_compare_versions()'s _parse_ver() extracts leading digits per dot-separated
segment via regex ^(\d+) — for '^9.0.0', the first segment '^9' has no
leading digit (the caret isn't stripped), so it silently parses to 0. This
makes '^9.0.0' compare as if it were '0.0.0', matching ANY '<X.Y.Z'
vulnerable_range regardless of the real installed version.

Found via real-codebase validation (Coretax-Auto-Downloader KDS backend):
jsonwebtoken reported 'installed_version': '^9.0.0' against
'vulnerable_range': '<9.0.0' — 9.0.0 is not less than 9.0.0, so this was a
false positive purely from checking the declared range string. Fix: only
collect from the 'packages' (resolved) section — remove the
workspaces.dependencies collection entirely, since it duplicates data
already present (correctly, as concrete versions) in 'packages'.

Verified: total vuln findings 22 -> 13, jsonwebtoken false positives (4)
eliminated entirely.
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant