a CVE the agent closed as "rejected" got re-issued under a new ID for the same bug - the old ticket stayed closed
Fixes a closed rejected CVE that comes back to life under a new CVE ID for the same bug while the old ticket stays shut. Use it when a CVE you closed as rejected reappears as a fresh finding with a different ID. Key trigger: the new CVE's references or alias list point at the same bug you already dispositioned.
TL;DR: Key your tickets to the bug, not the CVE ID - link records through the alias graph (OSV aliases, NVD references, GHSA links) so a re-issued ID reopens the existing ticket instead of creating a fresh one. On every new CVE, check whether it aliases anything already closed and reopen with a cross-link. The old ticket stays the record of the decision; the new ID becomes an alias on it.
new finding: CVE-2026-YYYYY (same vendor advisory as closed rejected CVE-2026-XXXXX)- Confirm the two IDs describe the same bug: compare vendor advisories, affected product and versions, and the alias lists in OSV. Expected: a shared advisory link or alias entry proves they are the same issue.
- Reopen the original ticket and add the new CVE ID as an alias. Expected: one ticket tracks the bug under both IDs.
- Change the intake check: before opening a new ticket, search closed tickets by alias and reference URL, not just by CVE ID. Expected: a re-issued CVE matches the closed ticket and reopens it automatically.
- Re-run the dedup over the current backlog. Expected: other same-bug duplicates surface and merge into their canonical tickets.
- Record why the ID changed (rejected CVE re-issued, CNA reassignment) in the ticket. Expected: the ticket history explains both IDs to the next triager.
Use this when
- a rejected or closed CVE reappears under a new ID
- duplicate tickets exist for the same underlying bug
- a CNA reassigns CVE IDs
- NVD merges or splits CVE entries
Not for this skill when
- the new CVE is genuinely a different bug in the same component
- the rejection itself is being disputed on the merits
- the scanner misidentifies the product entirely
- the "duplicate" is the same ID reported by two scanners (a scanner-dedup problem)
Variant phrasings
- rejected CVE came back with new ID
- duplicate CVE tickets same vulnerability
- CVE reissued new identifier
- closed CVE reopened under different ID
Why it happens
CVE IDs are administrative labels, not bug identities. A rejected CVE can be re-issued under a new ID for the same underlying bug, and ID-keyed dedup treats the new label as a brand-new finding while the old ticket stays closed - so the same bug gets triaged twice and the history splits.
Edge cases
- a re-issued CVE can gain a wider affected-version range than the original rejection covered - re-verify scope on reopen, do not just re-close
- NVD merge and split events also rename IDs - watch the CVE change feed, not just the new-CVE feed
- some scanners report the old ID from stale databases for weeks - the alias link keeps both quiet
- a rejection that turns out to be wrong needs the full re-triage, not a rubber-stamp re-close
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_7azbUuHCqCTRzhO-74CIhw