fix: scope the reported fix version to the installed version's range - #1085
Merged
Conversation
…'s range findFirstFixedVersion collected every fixed event for a package and returned the global minimum, without checking which range the installed version actually falls in. When an advisory patches two release branches, the other branch's fix won. minimist@1.2.5 against GHSA-xvch-5gv4-984h is the concrete case. OSV declares [1.0.0, 1.2.6) fixed in 1.2.6 and [0, 0.2.4) fixed in 0.2.4. The installed version is on the first branch, so the fix is 1.2.6, but 0.2.4 sorted lower and was reported instead: a downgrade across a major boundary that would break any consumer. The remediation resolver already got this right, so a single scan contradicted itself. Compact output and the HTML report's Fixed column said 0.2.4 while the fix command directly beneath said 1.2.6. findFirstFixedVersion now takes the installed version and walks each range's events in order, pairing introduced with fixed so a range that reintroduces a vulnerability is handled. Fixes whose window contains the installed version win; when no window contains it the previous lowest-fix behaviour is kept so a finding's remediation stays visible. This is distinct from the pre-release ordering bug in compareVersions: even with a correct comparator the global minimum is still the wrong branch. It is also distinct from the cross-package leak, which was the right range on the wrong package.
sonukapoor
force-pushed
the
bugfix/fixed-version-range-scoping
branch
from
September 5, 2026 19:59
3f69cc9 to
b016ec1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
findFirstFixedVersioncollected everyfixedevent for a package and returned the global minimum, without checking which range the installed version actually falls in. When an advisory patches two release branches, the other branch's fix won.minimist@1.2.5against GHSA-xvch-5gv4-984h is the concrete case. OSV declares[1.0.0, 1.2.6)fixed in 1.2.6 and[0, 0.2.4)fixed in 0.2.4. The install is on the first branch so the fix is 1.2.6, but 0.2.4 sorted lower and was reported instead: a downgrade across a major boundary that would break any consumer.The remediation resolver already got this right, so a single scan contradicted itself. Compact output and the HTML report's Fixed column said 0.2.4 while the fix command directly beneath said 1.2.6.
The function now takes the installed version and walks each range's events in order, pairing
introducedwithfixedso a range that reintroduces a vulnerability is handled. Fixes whose window contains the installed version win. When no window contains it, the previous lowest-fix behaviour is kept so a finding's remediation stays visible rather than disappearing.Known limitation, recorded on the issue: this is incomplete for pre-release installed versions, because the window check depends on
compareVersions, which #1077 shows is wrong for pre-releases. That case resolves automatically once #1077 lands, with no further change here. Every release install is correct now and pre-release installs are no worse than before.Found by dogfooding while building the Open Source Friday demo, where a critical finding was about to recommend a downgrade on air.
Closes #1083