In a CVE 5 record, mark each version as affected, unaffected or unknown, give ranges a versionType such as semver or maven, and use lessThan to name the release that contains the fix. Zero means no lower bound. An asterisk in an upper bound means infinity, not a wildcard.
The building blocks
The CVE Project's version guide describes these rules:
| Concept | Rule |
|---|---|
| Status | affected, unaffected, or unknown for each entry |
| Default | Versions matched by no entry take the product's defaultStatus, which defaults to unknown |
| Single version | Needs only version and status |
| Range | Needs versionType and either lessThan or lessThanOrEqual |
| Lower bound | 0 means no lower bound |
| Upper bound | An asterisk means infinity |
| Custom version type | Discouraged, because tools cannot evaluate it |
A worked example in plain words
Say your library 2.x line broke in 2.3.0 and was fixed in 2.7.4, while the 1.x line never had the bug. You would describe it like this:
- Product default status: unaffected, since most versions are fine.
- One range entry: version 2.3.0, lessThan 2.7.4, versionType semver, status affected.
- Nothing for 1.x, because the default already covers it.
A reader and a tool can now answer "am I on 2.5.1" without guessing.
Why lessThan beats lessThanOrEqual
The guide notes that ranges use lessThan more often, because it can name the exact fixing version. A lessThanOrEqual value only names the last release you tested, and implies the next one is fixed. If you later skip a release, you have made a claim you cannot support. Name the real fix.
Pick the right version type
Each numbering system orders versions differently, which is why a range needs a type. Semver, maven, python and rpm are examples the guide lists. Git commit hashes can serve as versions too, with a repository field, and then ordering follows commit ancestry. Use the type your users' tools understand.
Common mistakes
- Leaving the default as unknown on a product where nearly everything is unaffected, which makes tools flag everything.
- Writing a range with no versionType.
- Forgetting a backport. If you fixed the 2.6 line in 2.6.9 as well, add that. See fixed versions and backports.
- Listing only one branch when several are affected.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a fixed version turns into a concrete upgrade step.
Quick check
What does 0 mean as a lower bound?
No lower bound. The range starts at the earliest version.
Is an asterisk a wildcard in an upper bound?
No. The guide says it means infinity.
Safeguard's dependency scanning and autonomous remediation can propose fix PRs, off by default with every category on Manual. A free scan shows which fixed versions apply to you.
Sources
Last reviewed: 19 October 2026.
