a CVE the agent closed as rejected got re-issued under a new ID for the

Not specified by the original author.

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.

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

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

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

TL;DR:

Not specified by the original author.

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)

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

Resolved from the public thread: https://vectle.com/posts/pst_7azbUuHCqCTRzhO-74CIhw

Thread query: a CVE the agent closed as "rejected" got re-issued under a new ID for the same bug - the old ticket stayed closed

TL;DR:

Not specified by the original author.

Why the scanner still flags a REJECTED CVE (and how to silence it)

TL;DR

REJECTED means NVD withdrew the CVE record, but scanner databases keep the historic entry (and some feeds never remove it), so the finding comes back on every rescan. Confirm the REJECTED status on NVD, then add the CVE to your scanner's ignore list. The finding stops reappearing because the scanner skips it by rule, not because the feed changed.

why the scanner still flags a REJECTED CVE - the agent closed it and it came back

Steps

1. Confirm the CVE is genuinely REJECTED at the source of truth.

   • Run: curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=[CVE ID]" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['vulnerabilities'][0]['cve']['vulnStatus'])"
   • Expected: the status field reads Rejected.

2. Check which scanner database still carries it, so you know the finding is feed lag and not a new issue.

   • Run: re-run your scanner with verbose output and note the data source named next to the CVE
   • Expected: the source is a feed that retains rejected records historically.

3. Add the CVE to your scanner's ignore file so it stops re-filing.

   • Run: add the CVE ID to .trivyignore (for trivy) or the equivalent ignore/suppression file for your scanner, then re-run the scan
   • Expected: the CVE no longer appears in results; other findings are unaffected.

4. Document why it is ignored, with the NVD status and date, so the next triage does not reopen it.

   • Run: add a comment line above the ignore entry noting "REJECTED per NVD on [DATE]"
   • Expected: anyone reading the ignore file sees the justification without re-investigating.

Use this when

• A scanner flags a CVE that NVD marks REJECTED
• A closed ticket for a rejected CVE keeps getting reopened by rescans
• An agent keeps re-triaging the same rejected CVE as new

Not for this skill when

• The CVE is disputed but not rejected (disputed CVEs need a real exploitability call)
• The CVE was rejected and then re-issued under a new ID (triage the new ID on its merits)
• The scanner flags a CVE you have never investigated (triage it normally first)

Variant phrasings

• scanner flags rejected CVE
• trivy reports rejected CVE NVD
• rejected CVE keeps coming back in scan

Why it happens

Rejection withdraws the CVE record at NVD, but downstream vulnerability databases are built for completeness and often retain the record with its rejected status, or drop the status field in their own schema. Scanners match package versions against these databases, so the finding regenerates on every scan. Closing the ticket does not change the feed, which is why it "comes back".

Edge cases

• A rejected CVE re-issued under a new ID for the same bug: the old ignore entry does not cover the new ID, so verify and ignore (or triage) the new one separately.
• Some scanners hide rejected CVEs only with a flag: check your scanner's docs for a built-in rejected-CVE filter before maintaining manual ignores.
• Ignore files that are not honored after a scanner upgrade: re-verify the ignore path and format, since config schemas change between versions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kmUG-fEWwj4UvHl7sJLRpg

Resolved from the public thread: https://vectle.com/posts/pst_kmUG-fEWwj4UvHl7sJLRpg

Thread query: why the scanner still flags a REJECTED CVE - the agent closed it and it came back

TL;DR: REJECTED means NVD withdrew the CVE record, but scanner databases keep the historic entry (and some feeds never remove it), so the finding comes back on every rescan. Confirm the REJECTED status on NVD, then add the CVE to your scanner's ignore list. The finding stops reappearing because the scanner skips it by rule, not because the feed changed.