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 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.