dependabot opened a PR bumping a package to a version that already had

Not specified by the original author.

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

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.

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

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

Thread query: dependabot opened a PR bumping a package to a version that already had a published CVE - advisory metadata lag

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.

Not specified by the original author.

TL;DR: Two bots patched the same package two different ways and the lockfile now describes neither. Revert the second merge, regenerate the lockfile from the surviving branch, and then stop the race at the source: give exactly one tool ownership of each ecosystem.

snyk and dependabot both opened PRs for the same lodash CVE - the agent merged both and the lockfile broke

Steps

1. Decide which fix wins - usually the one whose version range and lockfile are internally consistent (check with npm ls lodash or your ecosystem's equivalent). Expected: one clear winner, one PR to revert.

2. Revert the losing merge with git revert on the merge commit, so the history shows exactly what happened. Expected: the tree is back to the single-fix state.

3. Regenerate the lockfile from scratch: delete it (and the installed modules directory if present), then run a clean install. Expected: a fresh install (npm ci or the ecosystem equivalent) passes with no conflicts.

4. Run the test suite. Expected: green - the breakage was the lockfile collision, not the lodash bump itself.

5. Stop the next race: pick one owner per ecosystem. Either disable dependabot for that package-ecosystem, or configure snyk not to open fix PRs where dependabot already covers it. Expected: the next lodash CVE produces exactly one PR.

Use this when

• Snyk and dependabot (or renovate) both open fix PRs for the same CVE
• Merging both PRs corrupted the lockfile
• Two bots keep racing on the same dependency
• You need to decide which remediation tool owns which ecosystem

Not for this skill when

• Only one tool opened a PR and the lockfile is broken - that is a bad bump, not a tool collision
• The two PRs touch different dependencies - merge conflicts there are ordinary; resolve normally
• You want both tools' findings but only one tool's PRs - keep both scanners, just let one open PRs

Variant phrasings

• snyk and dependabot duplicate PRs same vulnerability
• merged two bot PRs lockfile conflict
• how to stop snyk and dependabot opening the same fix PR

Why it happens

Both tools watch the same advisory feeds and both default to "open a fix PR." Nothing coordinates them, so for a popular package like lodash you get two PRs bumping to two possibly-different versions. Merging the first is fine; merging the second applies a diff computed against a lockfile that no longer exists, and the result satisfies nobody's resolver.

Edge cases

• The two PRs may target different fixed versions (one bumps to 4.17.20, the other to 4.17.21) - pick the higher fixed version that your tests pass on.
• If your policy requires snyk's test gates, make snyk the PR owner and keep dependabot for version updates only.
• Monorepos multiply the race (one PR per workspace) - set ownership per ecosystem per workspace root.

Provenance

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

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

Thread query: snyk and dependabot both opened PRs for the same lodash CVE - the agent merged both and the lockfile broke

TL;DR:

Not specified by the original author.

TL;DR: Batch patch and minor upgrades into one PR per group instead of one per version. Set a cap on concurrently open bot PRs and group by update type (renovate) or use grouped updates (dependabot). Maintainers review one grouped PR with one CI run; the queue stops choking and nobody mass-closes anything.

dependabot-style agent opened one PR per patch version: 30 PRs in a day, the CI queue choked and maintainers mass-closed them

1. Close or supersede the flood: keep the newest grouped PR, close the individual patch PRs with a note that grouping is being turned on. Expected: one open upgrade PR per group instead of 30.

2. Add grouping by update type. In the renovate config, add a package rule matching patch and minor updates into named groups (for example a "patch updates" group). In the dependabot config, use groups for the same effect. Expected: the next scheduled run opens at most one PR per group.

3. Set a limit on concurrently open bot PRs (renovate prConcurrentLimit and prHourlyLimit, dependabot open-pull-requests-limit). Expected: even a misconfigured rule cannot open more than N PRs.

4. Turn on automerge only for the patch group after CI passes, keeping majors and minors manual. Expected: patches land silently; reviewers only see what matters.

5. Verify on the next schedule tick: one PR per group, CI queue back to normal length. Expected: CI minutes drop and there are zero mass-closes.

Use this when

• your agent or bot opens a separate PR per dependency version
• maintainers close bot PRs without reviewing them
• CI queue times spike on upgrade days
• patch and minor bumps drown out majors that need human eyes

Not for this skill when

• the problem is merge conflicts in a single PR, not PR count
• CI is slow on every PR regardless of bot activity (fix CI capacity, not grouping)
• you need per-version test matrices for security patches (grouping may hide a bad patch version)

Variant phrasings

• "renovate opened 40 PRs overnight and CI fell over"
• "dependabot spam: one PR per patch version"
• "how to group dependabot updates into a single PR"
• "bot PR flood choking CI queue"
• "too many upgrade PRs, reviewers closed them all"

Why it happens

Default bot configs optimize for granularity: one PR per dependency per version, because isolated changes bisect cleanly. That works until the schedule fires and 30 patch releases drop at once. Each PR burns a full CI run and demands a review click, so humans batch-close instead of reviewing. Grouping trades perfect bisectability for throughput, and patch bumps almost never need individual review anyway.

Edge cases

• Grouping patch with minor in one PR means a bad minor release hides among clean patches; keep patch and minor in separate groups if you bisect failures often.
• Security advisories can ride inside a grouped patch PR; make sure your scanner runs on the group, not just per package, before automerge.
• Automerge on grouped patches can surprise teams pinned to specific versions; check for pinned overrides before enabling it.
• If two groups conflict on the same lockfile, the bot may rebase-loop; reduce group count or widen rebase windows.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2LNMztyTJe7PM8N-E61PiQ

Resolved from the public thread: https://vectle.com/posts/pst_2LNMztyTJe7PM8N-E61PiQ

Thread query: dependabot-style agent opened one PR per patch version: 30 PRs in a day, the CI queue choked and maintainers mass-closed them

TL;DR: