No. In the CVE Record Format, each version is marked affected, unaffected or unknown, and unknown means the publisher did not say. It is not a statement that your version is safe. The defaultStatus field also defaults to unknown, so a version not listed in a record is unknown, not unaffected.
How the format describes versions
The CVE Program's documentation on product and version encoding explains the model:
- Each version in a product's versions list is given a status: affected, unaffected or unknown.
- A defaultStatus field covers every version not matched by the list. Its default value is unknown.
- A single version uses a version and status pair. A range adds a version type, such as semver, maven, python, rpm or git, plus a lessThan or lessThanOrEqual bound.
- A lower bound of "0" means no minimum, and an asterisk means infinity, not a wildcard.
- The page discourages custom ordering, and also discourages splitting one vulnerability into several CVEs by branch.
Why "unknown" trips people up
Take a record that lists version 2.4.1 as affected and 2.4.5 as unaffected, and sets defaultStatus to unknown. What about 2.4.3? Unless a range covers it, it is unknown. A scanner that treats "not listed as affected" as "fine" will miss it. A scanner that treats unknown as affected will raise findings for versions that may be safe.
Neither is right by default. The honest output is a third state.
What a good scanner or process does
| Record says | Reasonable treatment |
|---|---|
| affected | Finding; confirm with reachability or exposure |
| unaffected | No finding |
| unknown | Review state: show it, label the reason, set an owner |
| defaultStatus unknown, version not listed | Do not auto-pass; check other sources |
Cross-check with ecosystem advisories, which often carry explicit fixed versions. Our post on OSV fixed vs last affected, which event to use shows how another format expresses the same idea.
A routine for an unknown result
- Identify the record's CNA and read its own advisory page.
- Check whether the project has a fixed release after your version.
- Look for a second source, such as a package ecosystem advisory.
- If the vendor confirms your version, record the result as unaffected with a link.
- If nobody confirms, treat it as a risk decision: upgrade, or document the exception with an expiry.
Gate policy
Avoid a binary pass or fail on missing data. A simple pattern:
- Block on affected versions that are KEV listed.
- Warn on affected versions otherwise.
- Route unknown to a review queue with a time limit.
This ties to our post on how to ignore a dependency advisory without hiding real risk.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and policies and gates. Reachability helps decide whether a flagged component's vulnerable code is used. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an exploitability check helps when version data alone is unclear.
Quick check
What is the default value of defaultStatus?
Unknown, according to the CVE Program's version encoding documentation.
Does a version missing from the list count as unaffected?
No. It falls under defaultStatus, which is unknown unless the record sets it otherwise.
Does an asterisk in a version range mean a wildcard?
No. The documentation says it means infinity.
Sources
- CVE Program, CVE 5.0 product and version encodings, fetched 19 October 2026.
Last reviewed: 19 October 2026.
