Start with the identifier

A scanner hands your agent CVE-2021-44228. Your ticket needs enough context for someone to decide what to investigate. cve-lookup, part of Prooflayer, turns that identifier into a structured vulnerability record for $0.005 USDC per call through x402 on Base mainnet.

Send one JSON field: 

{
  "cve_id": "CVE-2021-44228"
}

The endpoint accepts POST. The identifier is case-insensitive, and surrounding spaces are trimmed. The accepted format has a four-digit year followed by four to seven digits.

Route here when you've already got a CVE ID and need details for a dependency alert or a security ticket. A hostname alone doesn't identify which vulnerability record to retrieve.

Read severity with its scoring version

The response includes description and published, plus last_modified for tracking changes to the record.

For sorting, start with score and severity. The primary score prefers CVSS v3.1 and falls back to CVSS v2. Missing scores remain null; your agent shouldn't convert them to zero.

Keep the scoring version attached. The cvss_v3_1 object includes base_score and vector, with separate fields for attack conditions and impact. For example, privileges_required and user_interaction help a reviewer understand the conditions described by the assessment. The cvss_v2 object carries the older score and vector when available.

What does the number tell you? CVSS base scoring describes a vulnerability's severity independently of your particular deployment. Your asset's exposure still needs a separate assessment. FIRST's CVSS v3.1 specification explains the score and vector format.

So keep both the score and the evidence used to judge local exposure in your ticket.

Match products before assigning work

affected_cpes contains CPE 2.3 product identifiers. Use those entries to find candidate matches in your inventory, then check the affected versions against the linked advisory.

Check version boundaries separately. The returned CPE strings don't carry every version-range condition from the full vulnerability record. A wildcard in a product identifier isn't enough to decide whether your installed release needs a patch.

The response returns up to 50 CPE entries. Compare the array's length with affected_cpe_count to spot a truncated list.

The cwe array answers a different question: what kind of weakness does the record describe? Keep these identifiers for grouping related findings or routing a ticket to the team responsible for that class of bug. An empty array means the lookup supplied no weakness classification.

And preserve the original CVE ID alongside those fields. It's the join key between your scanner finding and the triage record.

Inspect the exploit evidence

public_exploit_known gives your agent a flag to inspect. exploit_references supplies the supporting reference objects, including their URLs and tags.

Treat the flag as bounded evidence. It's based on exploit-tagged references or recognized exploit-link patterns among the first 20 references returned. A false value doesn't establish that no public exploit exists. A true value doesn't establish that attackers have compromised your system.

The broader references array contains source links for further review. Each entry has a url, a source, and a tags array. Preserve the URL when writing a claim into a ticket so a human can open the supporting material.

exploit_summary gives you a plain-language account of exploitation and practical impact. Use it as the ticket's opening explanation, with linked evidence available for review.

Give the next agent a usable record

Before lookup, your workflow has an identifier. After lookup, it can attach severity data to a candidate product match and give the reviewer direct access to supporting sources.

Keep unknowns visible. If score is null, record “severity unavailable” and leave the finding open for review. If the product match is unresolved, store that as a separate status instead of treating the CVE lookup as proof of exposure.

For repeated findings, group identical CVE IDs before requesting enrichment. Keep each affected asset attached to its own finding, since two machines with the same CVE can need different follow-up.

A malformed identifier receives HTTP 400; a record absent from NVD receives 404. Handle those outcomes separately from a successful lookup. A missing record belongs in a follow-up queue, with the submitted identifier preserved so the next agent can check it again.