agent's dependency-bump PR reintroduced a patched CVE via lockfile merge

Not specified by the original author.

agent's dependency-bump PR reintroduced a patched CVE via lockfile merge

TL;DR

The dependency bump merged a lockfile that predated the CVE patch, resurrecting the vulnerable version. Scan after every merge, not just on PRs, and make the lockfile merge-aware: rebase onto the patched lockfile before merging. Merges do not know about your patches.

agent's dependency-bump PR reintroduced a patched CVE via lockfile merge

Steps

1. Confirm the regression: the merged lockfile pins the vulnerable version again. Expected: The resurrection is visible.

2. Re-apply the patch: bump the dependency past the fixed version and regenerate the lockfile. Expected: The CVE is patched again.

3. Add post-merge scanning: every merge to main gets scanned, not just PRs. Expected: Merges cannot silently regress.

4. Make bump PRs rebase onto the latest lockfile before merging. Expected: The merge base includes the patch.

5. Check other merged PRs for the same pattern. Expected: The full extent is known.

When to use

• a patched CVE reappears after merge
• lockfiles merge across branches
• bump PRs are long-lived

When not to use

• the CVE was never patched (then it is not a regression)
• the lockfile is generated, not merged (check the workflow)
• the scanner is wrong about the version (verify manually)

Tool compatibility

• any lockfile workflow
• dependency scanners

Variant phrasings

• "lockfile merge reintroduced CVE"
• "dependency bump resurrected vulnerability"
• "patched CVE back after merge"

Why it happens

Lockfile merges are textual: git merges the dependency lines without understanding versions. A bump branch created before the CVE patch carries the old version, and the merge happily restores it. The scanner ran on the PR, not on the merge result, so the regression shipped unnoticed.

Edge cases

• the merge queue is the right place for the post-merge scan
• long-lived bump branches are the risk; keep them fresh or recreate
• the scanner must understand the lockfile format to be accurate

Provenance

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

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

Thread query: agent's dependency-bump PR reintroduced a patched CVE via lockfile merge

TL;DR: The dependency bump merged a lockfile that predated the CVE patch, resurrecting the vulnerable version. Scan after every merge, not just on PRs, and make the lockfile merge-aware: rebase onto the patched lockfile before merging. Merges do not know about your patches.

Not specified by the original author.

TL;DR: Run the scanner on the PR branch before merging and treat the gate as part of the fix, not a surprise after it. When the bump introduces a new transitive CVE, either pin the transitive dependency to a clean version, pick a different fixed version of the direct dependency, or take an explicit short-lived exception with an expiry. Never merge past the gate by disabling it.

CI scanner gate: FAIL - new CVE-2026-ZZZZZ in transitive dep [pkg] introduced by this PR

1. Identify which direct dependency pulled in the vulnerable transitive package: check the lockfile diff in the PR. Expected: you see the dependency chain, for example a direct bump from 2.1 to 2.2 dragging in a transitive 0.9 that carries the CVE.
2. Check whether a newer patch of the direct dependency avoids the bad transitive: read its changelog or try the next version. Expected: you find a version whose transitive tree is clean, or confirm none exists yet.
3. If a clean combination exists, pin the transitive dependency to the fixed version in the PR and re-run the gate. Expected: the scanner gate passes.
4. If no clean combination exists, choose deliberately: a different remediation for the original CVE, or a time-boxed gate exception (30 days) with a ticket to revisit. Expected: the decision and its expiry are recorded, not just a bypass.
5. Re-run the full CI including the scanner gate. Expected: green, with the exception (if any) visible in the gate output.

Use this when

• a security PR introduces a new CVE
• the scanner gate fails on transitive dependencies
• the fix is correct in isolation but the merged tree is not clean
• dependabot or snyk PRs keep failing the security gate

Not for this skill when

• the gate flags the original CVE as unfixed (the patch did not work)
• the CVE is a scanner false positive on the fixed version
• the gate itself is misconfigured or scanning the wrong branch
• the failure is a build or test failure, not a scanner finding

Variant phrasings

• dependabot PR fails security scan
• fix introduced new vulnerability CI blocked
• transitive dependency CVE after upgrade
• scanner gate fails on patch PR

Why it happens

Dependency upgrades move the whole transitive tree, and the new tree can contain a different known CVE. The scanner gate evaluates the merged result, so a fix that is correct in isolation still fails the pipeline when the ecosystem has not published a fully clean combination yet.

Edge cases

• pinning a transitive dep can break the direct dep's peer expectations - run the test suite, not just the gate
• exception expiries must re-trigger the gate or they become permanent - automate the revisit
• two agents patching the same tree concurrently can reintroduce the bad transitive - serialize security PRs per repo
• the "new" CVE may predate your PR and only now be visible because the gate started scanning that path - check first-seen dates before blaming the bump

Provenance

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

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

Thread query: the patch PR's CI failed on the agent's own scanner gate - the fix introduced a new CVE in a transitive dependency

TL;DR:

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: