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.

```text
new finding: CVE-2026-YYYYY (same vendor advisory as closed rejected CVE-2026-XXXXX)
```

1. 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.
2. Reopen the original ticket and add the new CVE ID as an alias. Expected: one ticket tracks the bug under both IDs.
3. 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.
4. Re-run the dedup over the current backlog. Expected: other same-bug duplicates surface and merge into their canonical tickets.
5. 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