Data Corrections
An incorrect record is the most useful report Vulnpatch receives. This page says what counts as one, who owns which field, how to send it and what happens next. Every dossier links here under links.corrections, and every page on cve.vulnpatch.dev carries a "Report an incorrect record" link in its footer.
A flaw in the service itself (an injection, an access-control gap, a leak) is a different matter and goes through the vulnerability disclosure policy.
What counts
- a wrong nixpkgs mapping: a CVE matched to the wrong attribute, or a package it does not affect
- a wrong channel status or fix date
- a mis-classified reference: a patch listed as an advisory, a dead link listed as live
- a stale or missing record
- a wrong severity, or a conflict between sources that the dossier does not show
- a licence or attribution stated wrongly on the data terms page or in a response
Who owns which field
Most of what a dossier shows is relayed from a source that owns it. A correction sent to the owner takes effect everywhere, Vulnpatch included; a correction sent to Vulnpatch about a relayed field can only be noted until the owner changes it. The table says where each field goes so a report is not bounced.
| Field | Owner | Where to send it |
|---|---|---|
| CVE description, affected products, CVSS from the CNA, references in the CVE record | The CNA that published the record | cve.org: request an update |
| NVD's own CVSS, CPE configurations, NVD analysis status | NVD | nvd@nist.gov, with the CVE id in the subject |
| GitHub advisory content | GitHub Advisory Database | Suggest an improvement on the advisory |
| Known-exploited status | CISA | CISA KEV |
| A nixpkgs match the security review published, or an open nixpkgs security issue | The NixOS security team | The nixpkgs security issue for the CVE, or tracker.security.nixos.org |
Everything Vulnpatch derives: the nixpkgs block's candidates, channel status, fix timing, quality, agentHints, reference classification, the OSV feed's records, freshness measurements | Vulnpatch | support@vulnpatch.dev |
When it is not clear who owns a field, send it to Vulnpatch and say so. Working out where a report belongs is part of the job.
How to send it
Email support@vulnpatch.dev. Anonymous reports are accepted. Include:
- the CVE id, and the page or endpoint where you saw the record
- the
assessmentIdfrom the dossier, which names the exact inputs it was built from - what the record says and what you believe it should say
- the evidence: a link to the upstream record, a commit, a channel's package list
What happens next
| Step | Commitment |
|---|---|
| Acknowledgement | Within 5 business days of receipt |
| Outcome | Within 10 business days: corrected, sent on to the owner, or an explanation of why the record stands |
| Re-ingest | Queued when a correction is accepted, so the change reaches the cached dossier rather than waiting for the next scheduled refresh |
A corrected dossier has a new assessmentId, because the inputs changed. A consumer holding the old id can tell the record moved. A report Vulnpatch does not accept receives the reasoning, not silence.
Terms
Corrections are received on the same terms as the data: anything you send about a record may be published under the data terms, credited to you if you wish. Do not send material you are not entitled to share.