# Guide: Preserve CVE identity and timestamps in an incident note with AirnodeHub

Canonical: https://chainincident.com/news/a38b516c-197c-4e31-bbb7-9132dcafd2fc
Published: 2026-10-17T00:36:26.507Z
Publisher: Chain Incident

Use the documented NVD interface to preserve CVE identifiers, record timestamps and original advisory references, while keeping relay attestation separate from incident evidence.

An incident note needs a traceable record of what a vulnerability advisory said and when its supporting data changed. AirnodeHub’s NVD listing provides a documented route to NIST’s vulnerability records. It can support that recordkeeping without deciding whether a particular wallet, application or deployment is affected.

This is a documented template, not an executed CVE lookup or an assessment of a deployment.

### Build the note around the CVE identifier

Start with the exact CVE identifier in the original advisory. The Hub’s current contract documents `getCve` with a `cveId` parameter. In NVD’s response structure, the record sits under `vulnerabilities[].cve`. Preserve `cve.id` rather than replacing it with a shortened headline.

For a note being assembled from a vendor advisory, use a template such as:

- CVE: the exact `cve.id`.
- NVD publication: the unchanged `cve.published` value.
- NVD modification: the unchanged `cve.lastModified` value.
- Primary reference: the advisory publisher and original URL.
- Observation time: when the record was retrieved.

NIST defines `published` as publication to NVD and `lastModified` as modification of the CVE record. Neither field supplies the date of an attack. Keep them separate from the vendor advisory’s date and the note’s observation time.

### Follow the references before describing an incident

NVD’s `references` collection can contain vendor advisories, third-party reporting and other material. Open the original reference and identify its publisher before calling it a primary source. Preserve its URL alongside the CVE identifier, and attribute each substantive claim to the document that supports it.

A later `lastModified` value is a reason to compare records, not evidence of a new exploit. The Hub also documents `getCveHistory` for change events; NIST notes that older histories may have less detail. Keep an earlier snapshot when updating a note instead of silently replacing its dates.

### Keep the relay provenance separate

The [NVD listing](https://airnodehub.api3.org/explore/nvd) is published by API3 and categorized as third-party. Its current Airnode identifies signer `0x41dd84D5B6503D9aA3c374a49F546e335423a1b8`. That is the relay’s attestation, not NIST’s signature or endorsement. The documented `x-airnode-sign=false` passthrough option omits attestation.

On 13 October 2026, the listing displayed Free for its operations. Recheck that status before use. A signature records the serving Airnode’s response provenance; it does not establish exploitation, product applicability or the truth of every referenced claim.

## Sources

- [NVD API listing on AirnodeHub](https://airnodehub.api3.org/explore/nvd) — API3 / AirnodeHub
- [NVD API over Airnode: static self-description](https://airnode-nvd.fly.dev/) — API3-listed third-party Airnode
- [AirnodeHub API catalogue](https://airnodehub.api3.org/llms.txt) — API3 AirnodeHub
- [JSON Schema for NVD Vulnerability Data API version 2.2.4](https://csrc.nist.gov/schema/nvd/api/2.0/cve_api_json_2.0.schema) — NIST
- [NIST CVE API and Change History API documentation](https://nvd.nist.gov/developers/vulnerabilities) — NIST / NVD

- [Editorial policy](https://chainincident.com/editorial-policy)
- [Request a correction](https://chainincident.com/corrections)