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

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.