A CVE record from the assigning CNA can describe affected products with version ranges and optional CPE values. NVD separately adds configurations, which are CPE based applicability statements. They are two descriptions of the same thing, written by different parties at different times, and they can disagree.
The CVE side
The CVE record format has a product object with versions and cpes. The schema says versions help meet the CNA rules, and that versions or a default status may be omitted, but not both. CPEs are described as an array of values, vulnerable and not, so several statements can be made about the same version without overlapping. There is also a CPE node type for applicability statements.
In practice, this means the CNA's statement can be phrased as "versions below 2.4.1 are affected" or "affected by default, unaffected from 2.4.1".
The NVD side
An NVD record has a configurations field, as the 2021 record we fetched on 18 October 2026 shows. Configurations use CPE naming, which describes vendor, product and version text. Our post on the CPE naming convention explains the format.
Side by side
| Aspect | CNA version data | NVD configurations |
|---|---|---|
| Written by | The assigning CNA | NVD analysts, or imported |
| Style | Version ranges, default status, optional CPEs | CPE match criteria |
| Timing | At publication | Often after analysis |
| Good at | Precise ranges per product | Broad product identification |
| Weak at | Different CNAs vary in quality | Name matching to real packages |
Why packages complicate things
OSV exists because CPEs are hard to match automatically to package names and versions, as its FAQ puts it. A package called by one name in a registry may be a product named differently in CPE data. If a scanner depends on CPE only, it may miss a match or raise a false one.
What to do when they disagree
- Fetch the CVE record and the NVD record for the ID.
- Write down the affected range each one states.
- Read the vendor advisory and decide which matches the shipped code.
- Check a package level record in OSV or the ecosystem database.
- If your version is on the border, test it.
- Log the decision.
Version ranges to read carefully
Read the boundaries: introduced, fixed and last affected. The OSV schema says fixed is preferred over last_affected, because the latter can create false negatives. See OSV fixed versus last affected.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the exact version of each component, since that is the value compared with affected ranges.
Safeguard SBOM and dependency scanning records exact component versions, and reachability analysis adds whether the code is used. A free scan takes a few minutes.
Quick check
Which description should a scanner prefer?
For packages, a package level record with explicit ranges is usually easier to match than CPE text. Verify against the vendor advisory.
Can a CVE record omit its versions?
The schema says versions or a default status may be omitted, but not both.
Sources
Last reviewed: 19 October 2026.
