GitHub vulnerability alerts: fix versions from different major lines are merged, producing a cross-major bump

[a544jh]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

main @ 190f8d5 (2026-08-04)

Please tell us more about your question or problem

AI assistance disclosure: the tests and this write-up were produced with Claude Code (model claude-opus-5). The hypothesis and investigation plan were mine; Claude wrote and ran the tests, verified the advisory and npm metadata, and drafted the text. I've reviewed the output and conclusions.

Tests: a544jh/renovate @ claude/renovate-dependabot-grouping-bug-let95a (specs only, no source changes)

Summary

When one package is affected in several disjoint major lines, detectVulnerabilityAlerts() merges its alerts into a single rule keeping the highest first_patched_version. That becomes a hard floor for every dependency of that name, so a dependency on a lower major line is bumped across a major boundary to a version its consumers never asked for — when a fix existed on its own line.

vulnerable_version_range is parsed off the alert payload but never used to scope the rules. The OSV path handles the same case correctly.

Distinct from #42760, which maintainers have called intended. The claim isn't that alerts override config — it's that the version picked belongs to the wrong major line.

What it looks like

A workspace pins brace-expansion under minimatch@3 (which declares ^1.1.7); other chains in the repo resolve ^2 and ^5. GitHub raises one alert per line. Renovate opens Update dependency brace-expansion@^1 to v5 [SECURITY]:

-"overrides": { "brace-expansion@^1": "1.1.15" }
+"overrides": { "brace-expansion@^1": "5.0.7" }

The key still says ^1; the value no longer satisfies it. The correct fix for that line was 1.1.16.

Reproduction

Characterization tests, passing on main. GHSA-3jxr-9vmj-r5cp has three ranges: < 1.1.16 → 1.1.16, >= 2.0.0, < 2.1.2 → 2.1.2, >= 3.0.0, < 5.0.7 → 5.0.7.

Three alerts → one rule (prBodyNotes omitted):

[{ "matchDatasources": ["npm"], "matchPackageNames": ["brace-expansion"],
   "matchCurrentVersion": "< 5.0.7", "vulnerabilityFixVersion": "5.0.7",
   "vulnerabilitySeverity": "LOW", "isVulnerabilityAlert": true,
   "force": { "enabled": true } }]

That rule, on a dependency at 1.1.15 (vulnerabilityFixStrategy at its default lowest):

[{ "bucket": "major", "newVersion": "5.0.7", "newValue": "5.0.7",
   "newMajor": 5, "newMinor": 0, "newPatch": 7, "hasAttestation": false,
   "updateType": "major", "isBreaking": true }]

1.1.16 is in the release list — the floor removes it before lowest runs, so "lowest" means "lowest at or above 5.0.7". A control test confirms the same lookup with vulnerabilityFixVersion: '1.1.16' returns 1.1.16 as a patch.

OSV, same advisory, same dependency — scoped to its own line (force and prBodyNotes omitted):

[{ "matchDatasources": ["npm"], "matchPackageNames": ["brace-expansion"],
   "matchCurrentVersion": "1.1.15", "versioning": "npm",
   "allowedVersions": ">= 1.1.16", "isVulnerabilityAlert": true }]

Mechanism

• init/vulnerability.ts — bucket key is combinedAlerts[ecosystem][depName]; no version, no manifest. Merge keeps the max via isGreaterThan. One rule per bucket, scoped only by matchPackageNames and matchCurrentVersion: '< ' + firstPatchedVersion.
• process/lookup/index.ts — vulnerabilityFixVersion is a hard floor, applied before vulnerabilityFixStrategy picks among survivors.
• platform/github/schema.ts parses vulnerable_version_range and manifest_path; the former is read once in github/index.ts for a debug log. Neither reaches detectVulnerabilityAlerts().
• process/vulnerabilities.ts (OSV) gates each affected on isPackageVulnerable(depVersion, affected); getFixedVersion() takes the lowest fixed above the dependency's current version.

Observed vs inferred

Observed: all test outputs above; the advisory ranges.
Inferred: how often GitHub emits separate alerts per major line rather than coalescing upstream — I reproduced from the alert payload inward, not from a live Dependabot feed. The merge is unconditional either way.

Possible fix

1. Include vulnerable_version_range in the bucket key, emit one rule per range, and set matchCurrentVersion from the range rather than < fixVersion.
2. Route GitHub alerts through the per-affected matching the OSV path already uses.

Logs (if relevant)

No response