TL;DR: A rejected CVE means "this ID was wrong," not "this bug is gone" - the same flaw often gets re-issued under a fresh ID. When the new ID appears, pull its alias list from OSV and its references from NVD, match them against your closed tickets, and reopen the original ticket instead of triaging from zero. Then add an alias-watch so the next re-issue reopens automatically.

```text
a rejected CVE came back under a new CVE ID for the same bug - the agent's "closed" ticket never got reopened
```

## Steps

1. Fetch the alias list for the new CVE ID from OSV: `curl -s https://api.osv.dev/v1/vulns/CVE-2026-XXXXX | jq '.aliases'`
   Expected: the aliases array contains the old rejected CVE ID (possibly among others).
2. If aliases are empty, pull the new ID from NVD and read its reference URLs; re-issued CVEs usually share advisory links or patch commits with the original.
   Expected: one or more reference URLs identical to the ones recorded on the old ticket.
3. Search your ticket backlog for the old CVE ID, its aliases, and its reference URLs - not just the ticket title.
   Expected: exactly one closed ticket matches the same bug.
4. Reopen that ticket, link the new CVE ID to it, and copy the new ID's severity and score over.
   Expected: the finding is tracked once, under the new ID, with the old evidence attached.
5. Add the alias-watch rule: every new finding's alias list is checked against closed tickets, and a hit reopens instead of creating.
   Expected: the next re-issue reopens a ticket within one pipeline run instead of sitting closed.

## Use this when

- A finding closed as rejected is flagged again under a different CVE ID
- The same advisory URL or patch commit appears under two CVE IDs
- Your backlog has closed tickets for bugs the scanner still reports as open
- NVD shows a CVE as REJECTED but the underlying flaw was re-assigned

## Not for this skill when

- The new CVE is genuinely a different bug (different code path, different patch) - treat it as new
- Two scanners report the same vuln under different IDs - that is a dedup problem, not a re-issue
- The CVE was rejected because the product was never vulnerable - verify scope before reopening anything

## Variant phrasings

- rejected CVE reissued under a new CVE number, old ticket stayed closed
- CVE rejected then reassigned - how to link the old and new IDs
- NVD rejected CVE came back as a different CVE ID for the same vulnerability

## Why it happens

A REJECTED CVE means the identifier was withdrawn (duplicate, wrong product, bad report). It says nothing about whether the underlying bug exists. If the bug is real, someone reports it again and it gets a fresh ID. Most triage pipelines key tickets on the CVE ID string, so the new ID looks like a brand-new finding and the closed ticket is never linked. OSV's aliases array and shared NVD references are the bridge between the two IDs - but only if the pipeline checks them.

## Edge cases

- The re-issue can itself be rejected later; keep the full alias chain on the ticket, not just the latest ID.
- Re-issues sometimes narrow the scope (the new CVE covers fewer versions) - re-check affected versions before reopening with the old verdict.
- If the old ticket was closed as "not vulnerable" rather than rejected, the same alias check applies, but re-verify the product is still in scope first.

## Provenance

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