osvVulnerabilityAlerts skips a workspace member's range-declared dependency even though the root workspace lockfile resolves a vulnerable version

[dwertent]

How are you running Renovate?

LOG_LEVEL=debug renovate <package name>

Renovate config:

const fs = require('fs');
const path = require('path');

// RENOVATE_REPOSITORIES (comma-separated) overrides the list for a one-off targeted run.
const repositories = process.env.RENOVATE_REPOSITORIES
  ? process.env.RENOVATE_REPOSITORIES.split(',').map((r) => r.trim()).filter(Boolean)
  : JSON.parse(fs.readFileSync(path.join(__dirname, 'repos.json'), 'utf8'));

module.exports = {
  platform: 'github',

  autodiscover: false,
  repositories,
  onboarding: false,     
  requireConfig: 'optional', 

  dependencyDashboard: true,
  labels: ['renovate'],

  packageRules: [
    { matchPackageNames: ['*'], enabled: false },
    { matchManagers: ['gomod'], matchDepTypes: ['indirect'], enabled: false },
  ],

  osvVulnerabilityAlerts: true,
  vulnerabilityAlerts: {
    enabled: true,
    groupName: 'security updates',
    labels: ['security', 'cve-management'],
  },

  prHourlyLimit: 0,
  prConcurrentLimit: 0,
  branchConcurrentLimit: 0,
};

Which platform you running Renovate on?

Github

Which version of Renovate are you using?

43.222.0

Please tell us more about your question or problem

In an npm workspaces monorepo, a workspace member declares a dependency as a range (e.g.
form-data: ^4.0.0). The member has no co-located lockfile — the resolved versions live in the
root package-lock.json, which is the correct npm-workspaces layout. The root lock resolves
that dependency to a version with a known advisory.

Renovate does not flag or remediate it. The debug log shows:

DEBUG: Skipping vulnerability lookup for package form-data due to unsupported version ^4.0.0

Renovate appears to evaluate the member's range for the OSV lookup instead of the
resolved version from the root workspace lockfile, so it skips the lookup and opens nothing —
even though the fix is within the declared range (a lockfile-only bump would resolve it).

Renovate version: 43.222.0 (self-hosted CLI)
Platform: Github
Config (minimal):

{ "osvVulnerabilityAlerts": true }

Real-world example

• Workspace member declares form-data: ^4.0.0.
• Root package-lock.json resolves node_modules/form-data to 4.0.5.
• form-data 4.0.5 is affected by CVE-2026-12143 (fixed in 4.0.6 / 3.0.5 / 2.5.6).
• 4.0.6 satisfies ^4.0.0, so a lockfile-only update fixes it — but Renovate skips on the range.

Minimal reproduction

package.json
{
  "name": "repro-root",
  "private": true,
  "workspaces": ["pkg-a"]
}

pkg-a/package.json
{
  "name": "pkg-a",
  "version": "1.0.0",
  "dependencies": { "form-data": "^4.0.0" }
}

package-lock.json   (committed; generated by `npm install`, resolves form-data to a vulnerable 4.0.x such as 4.0.5)

Steps:

1. npm install at the root (produces the root package-lock.json; pkg-a has no lockfile).
2. Run Renovate with { "osvVulnerabilityAlerts": true }, LOG_LEVEL=debug.
3. Observe Skipping vulnerability lookup for package form-data due to unsupported version ^4.0.0
   and that no branch/PR is created for it.

Expected behavior

For a workspace member's dependency, Renovate uses the resolved version from the root workspace
lockfile for the OSV lookup, detects the advisory, and opens a (lockfile-only, in-range) fix PR
— the same as it would for a non-workspace repo with a co-located lockfile.

Actual behavior

The dependency is skipped (unsupported version <range>); no vulnerability is reported and no PR
is opened, despite the root lock pinning a vulnerable version.

Question

Is this expected for workspaces? If so, it would help to document that osvVulnerabilityAlerts
does not use the root workspace lock for a member's range-declared deps (so those need a
co-located lockfile or are out of scope). If not, can the OSV lookup use the root workspace lock's
resolved version for workspace members?

Logs (if relevant)

No response