## TL;DR
Dependabot picks the newest version satisfying your constraints using the advisory data it had at selection time. If the advisory database had not yet flagged that version, dependabot happily PRs you into a CVE. Do not merge it. Check the advisory's patched versions, close or supersede the PR with a bump past the vulnerable range, and add the bad version to the ignore list so it is not proposed again.

## The query

```text
dependabot opened a PR bumping a package to a version that already had a published CVE - advisory metadata lag
```

## Use this when

- A dependabot PR bumps a package to a version with a published CVE
- The CVE was published recently (days, not months, before the PR)
- You need to land the security fix without taking the bad version

## Not for

- Dependabot PRs to versions that are genuinely clean (just merge those)
- CVEs published long before the PR (that is a different data problem)
- Resolver conflicts in the PR (a version-range problem, not advisory lag)

## Steps

### 1. Confirm the version is actually affected

Look up the CVE in the GitHub Advisory Database and check the affected version range against the version dependabot proposed.

Expected output: confirmation that the proposed version falls inside the vulnerable range, and the patched version that fixes it.

### 2. Do not merge the bad PR

Close it unmerged, or leave it open but blocked, so nobody merges it by habit. If your merge queue auto-merges dependabot PRs, pause that for this package now.

Expected output: the vulnerable version cannot land through this PR.

### 3. Open the correct bump yourself

Create a PR bumping past the vulnerable range to the patched version (or the nearest safe version your constraints allow). Run the test suite on it like any dependency change.

Expected output: a green PR targeting a non-vulnerable version.

### 4. Ignore the bad version in dependabot.yml

Add an ignore entry for the affected version or range so dependabot does not propose it again on the next run.

```yaml
ignore:
  - dependency-name: "[package]"
    versions: ["[bad-version-range]"]
```

Expected output: the next dependabot run skips the vulnerable version.

### 5. Check whether the lag is systemic

If this keeps happening, your dependabot runs are racing advisory publication. Consider a scheduled audit step (npm audit, pip-audit, or equivalent) after dependabot PRs, so a second source catches what the advisory DB missed. Verify: the next few dependabot PRs all target clean versions.

## Variant phrasings

### dependabot PR vulnerable version CVE
The short symptom search.

### dependabot bumped to version with known CVE advisory lag
The cause-first search.

Compatibility: dependabot version updates for any ecosystem backed by the GitHub Advisory Database.

## Why it happens
Advisory publication is a pipeline: CVE assigned, details researched, affected ranges computed, database updated. Dependabot reads the database at PR creation time. When a CVE is published between the database snapshot and the PR, or the affected range is expanded after the PR, the PR predates the knowledge. It is a race, not a bug in your config.

## Edge cases / pitfalls

- The patched version may not exist yet. Then the right move is the ignore entry plus a tracking issue, not a bump to a different vulnerable version.
- Auto-merge makes this dangerous. A bad-version PR that auto-merges at 3am is a self-inflicted incident; gate security PRs on the audit step.
- Do not assume the CVE is a false positive just because dependabot proposed the version. Verify against the advisory; "dependabot chose it" is not evidence of safety.
- If the package is a transitive dependency, bump the direct parent or add an override; the ignore entry alone does not fix the tree.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LMg7kRh0HW4jdzzBYwQ8rg