versionType should use an enum, not free text
The Problem
The versionType field in affected[].versions[] is a free-text string. There's no validation on it, and the result is a mess. We pulled every versionType value across the full CVEList V5 corpus (342,789 files) and found 415 distinct values where there should realistically be about 8.
What the data actually looks like
Eight values cover 99.3% of all 358,335 versionType occurrences:
| Count |
versionType |
% of Total |
| 176,511 |
custom |
49.3% |
| 103,211 |
semver |
28.8% |
| 56,015 |
git |
15.6% |
| 10,539 |
original_commit_for_fix |
2.9% |
| 7,609 |
rpm |
2.1% |
| 1,732 |
maven |
0.5% |
| 295 |
python |
0.1% |
| 33 |
dpkg |
<0.1% |
The other 407 values are junk. Here's what we're seeing:
Typos and case variants — semvar (25), semv (1), SEM (1), Custom (45), Patch (115), firwmare update (2). CNAs clearly mean the right thing but the schema doesn't catch the mistake.
Literal version numbers instead of version types — 2.7.1, 6.3.0, 4.4.10, 7.0 U3m, 8.0 U1b (10), and hundreds more. These CNAs are confusing "what kind of versioning" with "what version."
Product names — LoadMaster (9), Portal for ArcGIS (19), Secret Server (1), Spring LDAP (5), Radiometer Customized Windows Operating System (6). Wrong field entirely.
Data from other fields leaking in — One record has customLack of file validation in Avast Business Antivirus for Linux allows writing untrusted update files. as the versionType. Another has semverCWE-693: Protection Mechanism Failure. These look like concatenation bugs in CNA tooling.
Meaningless values — * (23), 0 (16), all (34), N/A (4), a single space character (5). Also operators that belong in other fields: LessThan (5), <= (2).
Browser and OS names — Chrome, Firefox, Edge, Safari, Windows, Linux, macOS, Android.
Why this matters
The whole point of versionType is to tell consumers how to compare version strings. When it contains a product name or a literal version number, version range matching breaks. Anyone consuming CVE data either has to write normalization logic to deal with 415 different values, or just ignore the field. Neither is great.
What we'd suggest
Make it an enum. The schema should restrict versionType to an approved list. Based on actual usage, this covers 99.3% of records:
custom, semver, git, rpm, maven, python, dpkg
Note: original_commit_for_fix (10,539 uses) is really just a commit hash — the same thing git already describes. These should be consolidated under git, or if a distinction is needed, something like commit would be clearer and more general (not all source control is git).
Worth considering for the list too, based on lower but legitimate usage:
date, cpe, otp, npm, go, rust, php
Validate at submission time. CVE Services should reject records with values not on the list.
Tell CNAs what the field is for. A lot of these errors look like CNAs don't understand that versionType describes the versioning scheme, not the version number or the product. A short note in the CNA onboarding docs or the schema description would help.
Clean up existing records. Normalize the easy cases (case variants, obvious typos) and flag the rest for CNA review.
Date
April 8, 2026
Submitted By
Scott Moore - VulnCheck
versionTypeshould use an enum, not free textThe Problem
The
versionTypefield inaffected[].versions[]is a free-text string. There's no validation on it, and the result is a mess. We pulled everyversionTypevalue across the full CVEList V5 corpus (342,789 files) and found 415 distinct values where there should realistically be about 8.What the data actually looks like
Eight values cover 99.3% of all 358,335
versionTypeoccurrences:customsemvergitoriginal_commit_for_fixrpmmavenpythondpkgThe other 407 values are junk. Here's what we're seeing:
Typos and case variants —
semvar(25),semv(1),SEM(1),Custom(45),Patch(115),firwmare update(2). CNAs clearly mean the right thing but the schema doesn't catch the mistake.Literal version numbers instead of version types —
2.7.1,6.3.0,4.4.10,7.0 U3m, 8.0 U1b(10), and hundreds more. These CNAs are confusing "what kind of versioning" with "what version."Product names —
LoadMaster(9),Portal for ArcGIS(19),Secret Server(1),Spring LDAP(5),Radiometer Customized Windows Operating System(6). Wrong field entirely.Data from other fields leaking in — One record has
customLack of file validation in Avast Business Antivirus for Linux allows writing untrusted update files.as the versionType. Another hassemverCWE-693: Protection Mechanism Failure. These look like concatenation bugs in CNA tooling.Meaningless values —
*(23),0(16),all(34),N/A(4), a single space character (5). Also operators that belong in other fields:LessThan(5),<=(2).Browser and OS names —
Chrome,Firefox,Edge,Safari,Windows,Linux,macOS,Android.Why this matters
The whole point of
versionTypeis to tell consumers how to compare version strings. When it contains a product name or a literal version number, version range matching breaks. Anyone consuming CVE data either has to write normalization logic to deal with 415 different values, or just ignore the field. Neither is great.What we'd suggest
Make it an enum. The schema should restrict
versionTypeto an approved list. Based on actual usage, this covers 99.3% of records:Note:
original_commit_for_fix(10,539 uses) is really just a commit hash — the same thinggitalready describes. These should be consolidated undergit, or if a distinction is needed, something likecommitwould be clearer and more general (not all source control is git).Worth considering for the list too, based on lower but legitimate usage:
Validate at submission time. CVE Services should reject records with values not on the list.
Tell CNAs what the field is for. A lot of these errors look like CNAs don't understand that
versionTypedescribes the versioning scheme, not the version number or the product. A short note in the CNA onboarding docs or the schema description would help.Clean up existing records. Normalize the easy cases (case variants, obvious typos) and flag the rest for CNA review.
Date
April 8, 2026
Submitted By
Scott Moore - VulnCheck