A Linux kernel CVE record answers “is my kernel affected?” in two places at once: a list of git commit ranges and a list of kernel version ranges, each in its own product entry with a different defaultStatus. Read the version entry from top to bottom, stop at the first match, and fall back to affected for anything unlisted. Then check the git entry too, because in about one record in eight it carries version ranges the other entry does not.

We read every record the Linux kernel CNA published in 2026 (7,987 records, January 21 to November 6) from the CVE Program’s cvelistV5 bulk export of November 7, 2026, and counted how they are built. This article covers the kernel-specific layout. For the general rules of version, lessThan, lessThanOrEqual and defaultStatus in any CVE record, see our guide to CVE affected versions.

What a kernel CVE record contains

The kernel’s CVE process document sets the ground rules. CVEs are assigned “after a fix is available and applied to a stable kernel tree”, and are tracked “by the git commit id of the original fix”. No CVEs are assigned for kernel versions that are not “currently being actively supported by the Stable/LTS kernel team”. And applicability is yours to decide: “the applicability of any specific CVE is up to the user of Linux to determine, it is not up to the CVE assignment team.”

That produces a very regular structure. Across the 7,987 records:

Every record has the two entries. In 7,923 of them the order is the same: the git entry (defaultStatus unaffected) first, the version entry (defaultStatus affected) second. In the remaining 64, both entries have defaultStatus unaffected, so only explicitly listed versions are affected. The checker below handles both shapes because it evaluates every entry.

Entry 1: git commit ranges

The first product entry has "defaultStatus": "unaffected" and a list of commit ranges. Here is CVE-2026-99190 (gpiolib, published October 28, 2026), trimmed to the version list:

{"version": "d73d2a569e6212f58d89efc6e66ffbb2386a47b1", "lessThan": "68a2cd5381b8d89dc80bd16dd9cc9ca2d5c25e7f", "status": "affected", "versionType": "git"},
{"version": "9b407312755fd5db012413ca005f0f3a661db8dd", "lessThan": "78189c0e35abbcdab3b8ab0b764d578c02900734", "status": "affected", "versionType": "git"},
{"version": "9b407312755fd5db012413ca005f0f3a661db8dd", "lessThan": "890c3bf08e0fc09eff788a6cfeded7d21b4d3e9d", "status": "affected", "versionType": "git"},
{"version": "9b407312755fd5db012413ca005f0f3a661db8dd", "lessThan": "c28846ca1ac6134881114d272314623c8433e372", "status": "affected", "versionType": "git"},
{"version": "6.12.114", "lessThan": "6.12.115", "status": "affected", "versionType": "semver"}

Each git range reads “from the commit that introduced the bug, up to but not including a commit that fixed it”. The fix commits are the same ones listed in the record’s references as git.kernel.org/stable/c/<hash> links, one per branch that received the fix. The CVE schema says repo exists “to resolve git hash version ranges”, which is the point: comparing commits is not a string comparison. You need a kernel git checkout to ask whether your build contains the introducing commit and not the fix.

If you build kernels from source, this is the most precise data in the record. Most teams run a released version instead, which is what the second entry is for. But note the last line above: a kernel version range inside the git entry. We come back to it below.

Entry 2: kernel version ranges, first match wins

The second entry has "defaultStatus": "affected". For CVE-2026-99190 it is:

{"version": "6.15", "status": "affected"},
{"version": "0", "lessThan": "6.15", "status": "unaffected", "versionType": "semver"},
{"version": "6.12.115", "lessThanOrEqual": "6.12.*", "status": "unaffected", "versionType": "semver"},
{"version": "6.18.59", "lessThanOrEqual": "6.18.*", "status": "unaffected", "versionType": "semver"},
{"version": "7.2.13", "lessThanOrEqual": "7.2.*", "status": "unaffected", "versionType": "semver"},
{"version": "7.3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}

The CVE schema gives the rule: walk the list, return the status of the first entry that matches, and return defaultStatus if none do. Applied here:

1. 6.15 is affected. A bare version with no range is an exact match. This is the release that introduced the bug.
2. Anything before 6.15 is unaffected. 0 is the schema’s convention for “the earliest possible version”.
3. One unaffected range per fixed stable branch. 6.12.115 to 6.12.* means 6.12.115 and every later 6.12 release. The schema says a trailing * means “an arbitrarily large number in the version ordering”, so 6.12.* closes the range at the end of the 6.12 branch without touching 6.13.
4. The mainline fix onward is unaffected. The 7.3 ... * entry covers 7.3 and every later release.
5. Everything else is affected. 6.18.58, any 6.19 kernel, or 7.2.12 matches no entry and takes defaultStatus.

Point 5 is the reason the order and the default both matter. A branch that does not appear at all, such as 6.19 here, has no fix listed and falls through to affected. The kernel’s releases page currently lists 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10 as longterm branches. If your kernel sits on a branch that a record does not list, the record gives you no fixed version on that branch; the way out is moving to a branch that has one.

The original_commit_for_fix type is not defined

The last entry’s versionType is original_commit_for_fix. It is not among the schema’s versionType examples (“custom”, “git”, “maven”, “python”, “rpm”, “semver”), and the kernel’s CVE process document does not mention it. From the records, the value looks like the first mainline release containing the original fix, and every one we saw was a release number such as 7.3 or 7.4-rc1. That is our reading of the data, not a published definition.

The practical effect: a parser that refuses unknown version types stops at this entry for every version not matched earlier, which in practice means “unknown” for any kernel above the newest fixed stable branch. Our generic affected-versions guide shows a strict evaluator doing exactly that on a kernel record. If you choose to compare it as a normal kernel version, which is what the checker below does, make that a documented decision.

Why you must read both entries

The 6.12.114 lessThan 6.12.115 line in the git entry is the trap. In CVE-2026-99190, the bug arrived in mainline at 6.15, so the version entry says every 6.12 kernel is “before 6.15” and unaffected. But the git entry marks 6.12.114 as affected and the version entry lists a 6.12.115 fix. The commit ranges hint at why: the first range starts from a different commit (d73d2a5...) than the other three (9b40731...), consistent with the bug reaching 6.12 as a stable backport. Read only the version entry and 6.12.114 comes out clean.

This is not rare. In 1,084 of the 7,987 records, the first (git) entry also contains semver ranges. In 1,056 records (3,136 ranges), at least one of those ranges marks a stable release affected that the version entry, evaluated alone, calls unaffected.

Running the checker below against the record:

$ python3 kernel_affected.py CVE-2026-99190.json 6.12.113 6.12.114 6.18.58 6.18.59 6.19.10 7.3 6.12.114-1-amd64
CVE-2026-99190 6.12.113: unaffected
CVE-2026-99190 6.12.114: affected
CVE-2026-99190 6.18.58: affected
CVE-2026-99190 6.18.59: unaffected
CVE-2026-99190 6.19.10: affected
CVE-2026-99190 7.3: unaffected
CVE-2026-99190 6.12.114-1-amd64: distribution kernel suffix; use your distro's tracker

(Per-entry lines trimmed; for 6.12.114 the checker reports entry[0] affected via the 6.12.114-6.12.115 range and entry[1] unaffected via 0-6.15.)

Why CPE matching over-flags fixed kernels

Every 2026 kernel record also has a cpeApplicability block. For CVE-2026-100075, it is one OR node of eight ranges on cpe:2.3:o:linux:linux_kernel, each starting at 4.7 and ending before one fixed version: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6, and 7.3. OR’d together, those ranges collapse to “4.7 up to 7.3”, so 5.10.300, a fixed 5.10 kernel, still matches the 7.3 range.

We checked this across the corpus. The version entries name 36,296 fixed stable releases (the start of each X.Y.N to X.Y.* unaffected range). The OR’d CPE ranges in the same records match 35,340 of them (97.4%) as vulnerable, in 7,917 records. CPE ranges have no way to say “fixed on the 6.12 branch at 6.12.110”; the affected block does. We covered this limit with one example in our cpeApplicability guide; the corpus count shows it is the norm for kernel records, not an edge case.

If your scanner or SBOM tool matches kernel CVEs by CPE and reports patched LTS kernels as vulnerable, this is the first thing to check.

Distribution kernels: stop here

kernel.org is direct about this: “If you see anything at all after the dash, you are running a distribution kernel”, and “kernel developers can provide no support for them”. A RHEL, Ubuntu or Debian kernel version reflects the distribution’s base plus its own backports, so 5.14.0-... or 6.8.0-... cannot be compared to the kernel.org ranges in a CVE record. The kernel’s CVE document also says issues only present in a distribution’s kernel get CVEs from that distribution, not from the kernel team.

For those kernels, use the distribution’s security tracker or its VEX/CSAF data. Our VEX explainer covers how to read a “not affected” statement from a vendor.

A tested checker for kernel.org versions

The script below implements the schema’s first-match algorithm over both product entries, skips git commit ranges (they need a kernel checkout), and reports affected if either entry says so. It refuses versions with a distribution suffix. We ran it with Python 3.12 against CVE-2026-99190 (output above) and across all 7,987 2026 records to produce the counts in this article.

#!/usr/bin/env python3
"""Evaluate a kernel.org version against a Linux kernel CNA record (CVE JSON 5).
usage: kernel_affected.py CVE-record.json VERSION [VERSION ...]"""
import json, re, sys

def key(v):
    """Kernel version -> comparable tuple. '*' sorts above any number; -rcN sorts before final."""
    if v == "*":
        return ((float("inf"),),)
    m = re.fullmatch(r"(\d+(?:\.\d+)*)(?:\.(\*))?(?:-rc(\d+))?", v)
    if not m:
        raise ValueError(f"not a kernel.org version: {v}")
    nums = tuple(int(p) for p in m.group(1).split("."))
    if m.group(2):                                   # "6.12.*" -> 6.12.<infinity>
        nums += (float("inf"),)
    rc = int(m.group(3)) if m.group(3) else float("inf")  # 7.4-rc1 < 7.4
    return (nums + (0,) * (4 - len(nums)), rc)

def status(product, v):
    k = key(v)
    for e in product.get("versions", []):
        if e.get("versionType") == "git":
            continue                                 # commit ranges need a kernel git checkout
        if "lessThan" not in e and "lessThanOrEqual" not in e:
            if key(e["version"]) == k:
                return e["status"], e
            continue
        lo = key(e["version"])
        if "lessThan" in e and lo <= k < key(e["lessThan"]):
            return e["status"], e
        if "lessThanOrEqual" in e and lo <= k <= key(e["lessThanOrEqual"]):
            return e["status"], e
    return product.get("defaultStatus", "unknown"), None

rec = json.load(open(sys.argv[1]))
cve = rec["cveMetadata"]["cveId"]
prods = rec["containers"]["cna"]["affected"]       # kernel records carry two product entries
for v in sys.argv[2:]:
    if "-" in v and not re.search(r"-rc\d+$", v):
        print(f"{cve} {v}: distribution kernel suffix; use your distro's tracker")
        continue
    verdicts = []
    for i, p in enumerate(prods):
        s, e = status(p, v)
        why = "defaultStatus" if e is None else json.dumps({k: e[k] for k in e if k != "status"})
        verdicts.append(s)
        print(f"  entry[{i}] defaultStatus={p.get('defaultStatus')}: {s} (matched {why})")
    final = "affected" if "affected" in verdicts else "unaffected" if all(x == "unaffected" for x in verdicts) else "unknown"
    print(f"{cve} {v}: {final}")

Limits: it treats original_commit_for_fix as a kernel version comparison (see above), ignores git ranges, and only understands kernel.org version strings. It is a reference for reading the data, not a vulnerability scanner.

Turning the answer into a decision

“Affected” in a kernel record means the code is in your build, not that it is reachable. The kernel team says plainly that “large numbers of assigned CVEs are not relevant for their systems”, and the programFiles list (here drivers/gpio/gpiolib.c) is a quick first filter against your kernel config. After that, the usual signals apply: is it in KEV, what does EPSS say, what is exposed. Our vulnerability prioritization workflow walks through that decision from the CVE record to a ticket.

The kernel team’s own advice is to take whole stable releases rather than cherry-pick: “it is best to take all released kernel changes, as they are tested together in a unified whole”. For most teams, staying on a current LTS point release answers more of these records than evaluating them one by one.

Limits of this article

The counts cover Linux kernel CNA records with IDs CVE-2026-* in the PUBLISHED state, from the cvelistV5 export of November 7, 2026. The CNA updates records, so counts will drift. We did not check git ranges against a kernel tree, so the backport explanation for CVE-2026-99190 is an inference from the record. The meaning of original_commit_for_fix is our reading of the data, not a published definition.

Sources and verification

Scope. This is a specification explainer with measurements from public data. We read the CVE Record Format schema on the CVEProject/cve-schema main branch (default dataVersion 5.2.0), RFD 0002 in the same repository, and the Package URL specification in the package-url/purl-spec repository. We counted fields across every record in the cvelistV5 release cve_2026-11-05_0400Z (the “all CVEs at midnight” bundle for 5 November 2026) with Python 3.13, and ran the join script below against that data. The script is illustrative.

The short answer

Since CVE Record Format 5.2.0, each entry in a record’s affected array can carry a packageURL:

{
  "vendor": "fast-uri",
  "product": "fast-uri",
  "packageURL": "pkg:npm/fast-uri",
  "defaultStatus": "unaffected",
  "versions": [
    {"versionType": "semver", "status": "affected", "version": "2.4.2", "lessThan": "2.4.8"}
  ]
}

That fragment is from CVE-2026-110180 (trimmed to its first version range). Three rules decide how you use it:

1. No version in the purl. The schema says the Package URL “MUST NOT include a version”. Strip the version from your SBOM purl before you look it up.
2. The versions array still decides. A purl match finds the records about your package. Whether your version is affected comes from versions and defaultStatus, read with the record’s versionType.
3. It is optional and still rare. 1.6% of published records carry it today, from 12 CNAs. Treat it as a fast, precise path where it exists, and keep your CPE and name-based matching for the rest.

What the schema says

The field definition in the 5.2.0 schema:

“A Package URL, a unified URL specification for identifying packages hosted by known package hosts. The Package URL MUST NOT include a version.”

The schema types it as a URI and lists examples such as pkg:deb/debian/curl?arch=i386&distro=jessie, pkg:npm/%40angular/animation and pkg:golang/google.golang.org/genproto#googleapis/api/annotations. So qualifiers and subpaths are allowed; only the version is out.

packageURL does not satisfy the identifier requirement on its own. The product definition still requires either vendor and product or collectionURL and packageName, plus either versions or defaultStatus. In our scan, every one of the 7,324 entries with a purl also had one of those identifier pairs.

Why it was added

RFD 0002, “Supporting Package URLs in CVE”, is the design record. It argues that the existing identifier fields “are of limited value for automated applicability matching” and that Package URLs “are better suited than CPEs for capturing distinctions between different distributions of particular open source software”.

Two design choices in the RFD matter to consumers:

• Validation is mostly outside the schema. The JSON schema only checks that the value is a URI; the RFD says it “would be further constrained by CVE Services” to ensure the values are valid purls, because encoding purl rules in a regular expression “would be excessive and difficult to maintain”. Do not assume the schema has validated purl syntax for you.
• Versions live in one place. “All version information should only be included within the existing versions field.” That keeps one version-matching code path for consumers.

The cve-schema repository tags v5.2.0; the tagged commit is dated 3 September 2025. Records that declare dataVersion 5.1 cannot use the field. In our snapshot, 144,619 published records (36.1%) declared 5.2 and 255,826 declared 5.1.

What the data shows

We read every record in the 5 November 2026 bundle: 400,445 published and 18,890 rejected. Only CNA containers carried the field; no ADP container had a packageURL.

Who writes it

VulnCheck accounts for 78.8% of records with a purl. If you build matching around this field, most of your hits will come from one CNA’s conventions, so test against its records.

Which purl types

The most common types across the 7,324 entries: github 2,371, npm 1,729, pypi 805, maven 533, golang 498, composer 314, hex 309, cargo 242, cpan 210, otp 82, software-id 72, nuget 40, gem 31, generic 31.

Two of those need care:

• pkg:github identifies a source repository, not a registry package. VulnCheck wrote 1,917 of the GitHub entries and EEF 413. Your SBOM will usually describe the same software as pkg:npm/... or pkg:pypi/..., so a pkg:github record will not match it directly. You need a mapping from repository to registry package, or a fallback on collectionURL and packageName.
• pkg:software-id appears 72 times (for example pkg:software-id/erlang.org/otp), but the purl-spec decision record that registers it, dated 21 October 2026, still has the status “proposed”. Expect parsers to reject it until the type is registered.

How fast it is growing

By the month each record was first published (as the records stand today, so later updates are included):

October’s 2,000 are 11.7% of the 17,058 records first published that month.

Normalize before you join

The purl specification makes the type case-insensitive with lowercase as the canonical form, and some types go further. The type definitions say a GitHub namespace and name are “not case sensitive and shall be lowercased”, and a PyPI name “shall be lowercased and underscore _ replaced with a dash -”. npm names are case-sensitive.

CVE records do not always follow those rules:

• 756 of the 2,371 pkg:github entries (31.9%) contain uppercase letters, for example pkg:github/Finsys/dockhand.
• 9 pkg:pypi entries have uppercase letters and 24 contain an underscore.
• GitPython is a concrete case. In the 34 records we found for it, 28 use pkg:pypi/gitpython and 6 use pkg:pypi/GitPython. An exact string join misses one set or the other, depending on how your SBOM tool spells it.

So normalize both sides the same way before comparing: lowercase the type; lowercase github and pypi paths; replace _ with - for pypi; drop the version and qualifiers from the SBOM purl. Leave npm, Maven and other case-sensitive types alone.

A tested join

Two scripts. The first builds an index from the cvelistV5 bundle; the second joins a CycloneDX SBOM to it and applies the versions ranges.

#!/usr/bin/env python3
"""build_index.py: index CNA affected[] entries that carry packageURL,
keyed by a normalized purl (no version, no qualifiers)."""
import json, sys, zipfile

def norm(purl):
    core = purl.split("#")[0].split("?")[0]
    if "@" in core.rsplit("/", 1)[-1]:                 # drop a version (SBOM side)
        core = core.rsplit("@", 1)[0]
    scheme, rest = core.split(":", 1)
    ptype, _, path = rest.partition("/")
    ptype = ptype.lower()
    if ptype in ("github", "pypi"):                     # case-insensitive types per purl-spec
        path = path.lower()
    if ptype == "pypi":
        path = path.replace("_", "-")
    return f"pkg:{ptype}/{path}"

def main(zip_path, out_path):
    z = zipfile.ZipFile(zip_path)
    with open(out_path, "w") as out:
        for n in z.namelist():
            if not n.endswith(".json") or "/CVE-" not in n:
                continue
            rec = json.loads(z.read(n))
            meta = rec["cveMetadata"]
            if meta.get("state") != "PUBLISHED":
                continue
            for a in rec["containers"].get("cna", {}).get("affected", []):
                if a.get("packageURL"):
                    out.write(json.dumps({"key": norm(a["packageURL"]), "cve": meta["cveId"],
                        "defaultStatus": a.get("defaultStatus"), "versions": a.get("versions", [])}) + "\n")

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

#!/usr/bin/env python3
"""join_sbom.py: join CycloneDX component purls to the CVE packageURL index, then apply versions[] ranges.
Illustrative: only semver-like versionType values are compared; everything else is flagged for review."""
import json, sys
from packaging.version import Version, InvalidVersion
from build_index import norm

def status_for(ver, entry):
    try:
        v = Version(ver)
    except InvalidVersion:
        return "review: unparseable version"
    for r in entry["versions"]:
        if r.get("versionType") not in ("semver", "maven", "python", None):
            return f"review: versionType={r.get('versionType')}"
        try:
            lo = Version(r["version"]) if r["version"] not in ("0", "*") else Version("0")
            if "lessThan" in r:
                inside = lo <= v < Version(r["lessThan"])
            elif "lessThanOrEqual" in r:
                inside = lo <= v <= Version(r["lessThanOrEqual"])
            else:
                inside = v == lo
        except InvalidVersion:
            return "review: unparseable range"
        if inside:
            return r["status"]
    return entry.get("defaultStatus") or "unknown"

def main(index_path, sbom_path):
    index = {}
    for line in open(index_path):
        e = json.loads(line)
        index.setdefault(e["key"], []).append(e)
    for c in json.load(open(sbom_path))["components"]:
        for e in index.get(norm(c["purl"]), []):
            print(f'{c["purl"]}\t{e["cve"]}\t{status_for(c["version"], e)}')

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

Test run

python3 build_index.py cves.zip purl-index.jsonl took about 30 seconds and wrote 7,324 lines, one per entry. We then ran python3 join_sbom.py purl-index.jsonl sbom.cdx.json (packaging 26.3) with a three-component CycloneDX 1.6 SBOM:

GitPython 3.1.62 comes out affected by the six records whose ranges end at lessThan: 3.2.0, and unaffected by the 28 whose fixes landed at or before 3.1.62. Without normalization, the SBOM spelling GitPython would have matched 6 records and missed 28. The ?type=jar qualifier on the Maven purl is dropped before lookup.

What this does not handle: versionType values such as custom, git or distribution schemes (it flags them for review), changes arrays inside version ranges, purl types that need a repository-to-package mapping, and the order sensitivity of overlapping ranges. The CVE affected versions guide covers those rules in detail.

When the CVE has no purl

For the other 98% of records, you still need the older paths. The cpeApplicability explainer covers CPE-based matching, and collectionURL plus packageName is often enough to build a purl yourself: https://www.npmjs.com/package/x with packageName x is pkg:npm/x. Record which path produced each match, because a purl match and a name match deserve different confidence.

A match is only the start of the patch decision. In our vulnerability prioritization workflow, the purl join is the “does this apply to us” step; KEV, EPSS and SSVC decide how fast. If your supplier also ships VEX, apply it after the join; our CSAF VEX guide shows how to resolve its product IDs to purls.

Limits of this article

The counts describe one snapshot (the 5 November 2026 midnight bundle); CNAs update records, so the numbers will move. Month counts use each record’s original datePublished, so a purl added later to an old record is counted in the month the record was first published. We checked purl spelling only for the github and pypi rules; other types have their own normalization rules we did not test. We did not check how CVE Services validates purls at submission time. The join script uses Python’s packaging version ordering, which is close to, but not the same as, every ecosystem’s own ordering.

Sources and verification

Scope. This is a specification explainer with measurements from public data. We read the CVE Record Format schema on the CVEProject/cve-schema main branch (default dataVersion 5.2.0) and its advanced example record, sampled 2,000 random 2026 records from the cvelistV5 repository at commit f0b25a9 (November 4, 2026), and ran the Python script below with Python 3.13 against real records. We did not test commercial scanners or NVD’s own matching engine.

The short answer

cpeApplicability is where a CNA can say, in CPE terms, which configurations a CVE applies to. Each array element is one statement:

1. A statement has nodes, and optionally an operator and negate for combining them.
2. Each node has a required operator (AND or OR), an optional negate, and a cpeMatch list.
3. Each cpeMatch has a CPE 2.3 criteria string, a required vulnerable boolean, and optional bounds: versionStartIncluding, versionStartExcluding, versionEndIncluding, versionEndExcluding.
4. A host is in scope when the logic evaluates true against its CPE inventory and at least one matched entry has vulnerable: true.

If you already parse NVD configurations, the shape is familiar. The schema says so directly: the block is “mostly copied/forked from the NIST NVD CVE API v2.0 schema”.

Where the block lives

The schema defines cpeApplicability as an optional array on both the published CNA container and the ADP container. It was added in CVE Record Format 5.1.1 (the v5.1.1 tag in CVEProject/cve-schema dates from October 2024), which the release notes describe as adding “support for Common Platform Enumeration (CPE) Identifiers using the CPE Applicability Language”.

It is separate from the older cpes array inside each affected[] product. That array is a flat list of CPE names; its own schema description now ends: “Consider using the newer cpeApplicability block for defining CPE data using the CPE Applicability Language which includes more options for defining CPE Names.”

The schema adds one instruction that matters for consumers: “it is recommended that it align with (as much as possible) the product data provided within the affected block.” Recommended, not required. If you already read the affected block with the rules in our guide to lessThan, defaultStatus and versionType, treat cpeApplicability as a second encoding of the same claim, and expect the two to disagree sometimes.

The fields, one by one

Two details trip people up.

Version bounds apply only when the CPE’s version field is a wildcard. A criteria string such as cpe:2.3:a:ibm:mq_operator:3.4.1:*:... names one exact version; a string with * in the version position plus bounds names a range. Our evaluator treats a specific version in the criteria as an exact match and ignores bounds in that case.

There is no versionType. The affected block tells you whether versions are semver, git commits, or a custom scheme; cpeMatch does not. Whatever compares 6.18.9 with 6.19 has to guess the ordering, and for strings like alpha_0.3 or 1.3-beta there may be no safe guess.

AND, OR and vulnerable: false

The schema’s advanced example record shows the pattern that makes this block more expressive than a flat list. Its single element has "operator": "AND" and two nodes:

• Node 1 (OR): example_org:example_enterprise from 1.0.0 up to (excluding) 1.0.6, or from 2.1.6 up to 2.1.9, each with vulnerable: true.
• Node 2 (OR): Windows, macOS or a hardware model xt-4500, each with vulnerable: false.

Read it as: the application is vulnerable in those ranges when running on one of those platforms. The platform CPEs are conditions, not affected products. A tool that flags every host whose inventory contains cpe:2.3:o:microsoft:windows:... has misread the record.

What a sample of 2026 records contains

We took a seeded random sample of 2,000 files from the 84,849 2026 records in cvelistV5 at commit f0b25a9; 1,969 were published. The counting script parsed each record’s CNA and ADP containers.

Three practical readings. First, most records have no CPE statement from the CNA at all, so a CPE-only matcher misses most of the corpus. Second, the real-world block is simpler than the spec allows: almost everything is one OR node of ranges, and AND with platform CPEs is rare. Third, coverage depends on a handful of CNAs, so your hit rate will swing with your vendor mix. An earlier 1,000-record sample we took for the affected-versions guide found 29.5%; treat the figure as a range, not a constant.

The absence in ADP containers fits CISA’s stated policy. The Vulnrichment README says: “as of December 10, 2024, CISA will no longer be adding CPE strings to the enriched dataset.” See our explainer on CVE ADP containers for what CISA-ADP does still add.

A tested evaluator

The script takes one CVE record and every CPE installed on one host, and answers True, False or unknown. It is illustrative: it compares only dotted numeric versions, handles the \:-style escaping in CPE 2.3 names only for splitting, and matches part, vendor and product but ignores the remaining CPE fields.

"""Evaluate a CVE record's cna.cpeApplicability against one host's CPE inventory.
Illustrative: numeric-dotted versions only; anything else is reported as 'unknown'."""
import json, re, sys

def split_cpe(cpe):
    # split on ':' not preceded by a backslash (CPE 2.3 formatted-string escaping)
    return re.split(r'(?<!\\):', cpe)

def vkey(v):
    if not re.fullmatch(r'\d+(\.\d+)*', v):
        raise ValueError(v)
    return tuple(int(x) for x in v.split('.'))

def cmp(a, b):
    a, b = vkey(a), vkey(b)
    n = max(len(a), len(b))
    a, b = a + (0,) * (n - len(a)), b + (0,) * (n - len(b))
    return (a > b) - (a < b)

def match(m, installed_cpe):
    want, have = split_cpe(m['criteria']), split_cpe(installed_cpe)
    # compare part, vendor, product (fields 2-4); '*' is ANY
    for i in (2, 3, 4):
        if want[i] != '*' and want[i] != have[i]:
            return False
    ver = have[5]
    if want[5] not in ('*', '-'):            # exact version in the criteria
        return want[5] == ver
    checks = [('versionStartIncluding', lambda c: c >= 0), ('versionStartExcluding', lambda c: c > 0),
              ('versionEndIncluding', lambda c: c <= 0), ('versionEndExcluding', lambda c: c < 0)]
    return all(test(cmp(ver, m[k])) for k, test in checks if k in m)

def present(m, inventory):
    return any(match(m, c) for c in inventory)

def node(n, inv):
    hits = [present(m, inv) for m in n['cpeMatch']]
    r = all(hits) if n['operator'] == 'AND' else any(hits)
    return not r if n.get('negate') else r

def element(el, inv):
    res = [node(n, inv) for n in el['nodes']]
    r = all(res) if el.get('operator') == 'AND' else any(res)  # no operator: OR
    r = not r if el.get('negate') else r
    # the statement must also hit at least one entry flagged vulnerable
    vuln = any(m['vulnerable'] and present(m, inv)
               for n in el['nodes'] for m in n['cpeMatch'])
    return r and vuln

def evaluate(record, inventory):
    cna = record['containers']['cna']
    try:
        return any(element(el, inventory) for el in cna.get('cpeApplicability', []))
    except ValueError as e:
        return f'unknown (cannot order version {e})'

if __name__ == '__main__':
    rec = json.load(open(sys.argv[1]))
    inventory = sys.argv[2:]          # every CPE installed on one host
    print(' + '.join(inventory), '->', evaluate(rec, inventory))

Saved as cpe_eval.py, we ran it against three records from the sample and the schema’s example (output trimmed to the verdict):

$ python3 -I cpe_eval.py CVE-2026-74994.json 'cpe:2.3:a:erlang:erlang\/otp:28.5.0.5:*:*:*:*:*:*:*'
... -> True
$ python3 -I cpe_eval.py CVE-2026-74994.json 'cpe:2.3:a:erlang:erlang\/otp:28.5.0.6:*:*:*:*:*:*:*'
... -> False
$ python3 -I cpe_eval.py full-record-advanced-example.json cpe:2.3:a:example_org:example_enterprise:1.0.5:*:*:*:*:*:*:*
... -> False
$ python3 -I cpe_eval.py full-record-advanced-example.json cpe:2.3:a:example_org:example_enterprise:1.0.5:*:*:*:*:*:*:* cpe:2.3:o:microsoft:windows:11:*:*:*:*:*:*:*
... -> True
$ python3 -I cpe_eval.py CVE-2026-115975.json cpe:2.3:a:cervantessec:cervantes:v.1.4.0-beta:*:*:*:*:*:*:*
... -> unknown (cannot order version v.1.4.0-beta)

The Erlang/OTP record (CVE-2026-74994) is the common case: three ranges in one OR node, one per release line, with versionEndExcluding set to the fixed release. The example record shows the AND rule working: the application version alone is not enough; the platform must be present too. The Cervantes record (CVE-2026-115975) uses version strings like alpha_0.3 and 1.3-beta, and the honest answer is “cannot decide”.

Where cpeApplicability and affected disagree

CVE-2026-23122 is a Linux kernel record (published February 14, 2026). Its cpeApplicability block has one OR node with two ranges on cpe:2.3:o:linux:linux_kernel: 6.16 up to (excluding) 6.18.8, and 6.16 up to (excluding) 6.19. Its affected block for the semver product says 6.16 is affected, below 6.16 is unaffected, 6.18.8 through 6.18.* is unaffected, and 6.19 onwards is unaffected.

Our evaluator, run on kernel versions (output trimmed to the version and verdict):

6.15.4 -> False
6.18.7 -> True
6.18.9 -> True     # affected block: unaffected (6.18.8 to 6.18.*)
6.19   -> False

The second CPE range (6.16 to before 6.19) swallows the stable-branch fix, because a CPE range has no way to say “fixed in the 6.18 branch at 6.18.8 but not in mainline until 6.19”. The affected block can, through ordered entries and a 6.18.* upper limit. A scanner that trusts only CPE here raises a false positive on every patched 6.18 kernel.

That is the general lesson: CPE ranges are a lossy projection of branch-aware version data. Use them for discovery (which records mention a product I run?) and as a cross-check, then decide with the affected block.

Common mistakes

• Treating every matched CPE as vulnerable. Entries with vulnerable: false are context. In our sample they were rare (10 of 2,667), which is exactly why code that ignores the flag passes tests and fails later.
• Applying bounds to an exact-version criteria string. If the CPE’s version field is not *, compare it directly.
• Assuming the element operator. 84% of sampled elements omit it. With a single node it does not matter; with several, decide and document what your tool does. Our script treats a missing element operator as OR.
• Comparing versions as strings. "6.9" > "6.18" is true as text. Use a scheme-aware comparator and return “unknown” when the scheme is unknown.
• Mixing sources silently. CNA cpeApplicability, the older affected[].cpes, and NVD’s configurations are three different statements. Store which one produced a match.

Where this fits in triage

CPE matching answers “does this CVE apply to an asset I run?”. It does not answer “how urgently?”. Once a record matches, the next questions are whether it is in CISA KEV, its EPSS probability and its SSVC decision values; our vulnerability prioritization workflow walks that path from record to ticket, and the KEV JSON feed guide covers the exploitation check.

Limits of this article

• The counts come from one random sample of 2026 records at one commit; CNA behaviour changes, so rerun the count on your own snapshot before relying on a share.
• The evaluator is illustrative. It does not implement the full CPE 2.3 name-matching specification (NISTIR 7696), wildcard characters inside fields, or version schemes beyond dotted integers.
• We describe NVD configurations only by the schema’s own statement that this block was forked from the NVD CVE API v2.0 schema; we did not compare NVD’s published configurations for these CVEs.

Sources and verification

Scope. This is a specification explainer with measurements from public data. We read the CVE JSON schema (CVE_Record_Format.json, default dataVersion 5.2.0, CVEProject/cve-schema main branch), the cvelistV5 README and the CISA Vulnrichment README, then sampled 2,000 random 2026 record files from cvelistV5 at commit 1a44d59 (November 3, 2026). The script below was run with Python 3.13.

The short answer

A CVE record is not one author’s statement. Under containers there is exactly one cna object, written by the CVE Numbering Authority that assigned the ID, and an optional adp array. Each adp entry is written by an Authorized Data Publisher and names its author in providerMetadata.shortName.

In 2026 records you will mostly meet three kinds:

The rule that matters for tooling: read the CNA container and the CVE Program Container every time, read CISA-ADP for prioritization signals, and treat supplier ADPs as extra affected-product data for that supplier’s builds. Keep every value tagged with who published it.

What the schema says about ADP containers

The schema describes containers as “a set of structures (called containers) used to store vulnerability information related to a specific CVE ID provided by a specific organization participating in the CVE program.” It goes on: “There can only be one ‘cna’ container, as there can only be one assigning CNA. However, there can be multiple ‘adp’ containers.”

Three details shape how you parse them:

• Only providerMetadata is required. The adpContainer definition lists providerMetadata as required with minProperties: 2, so an ADP container can be just a publisher plus one other field. Code that assumes affected, descriptions or metrics will exist breaks.
• The fields mirror the CNA container. An ADP container can carry affected, cpeApplicability, problemTypes, metrics, references, solutions, workarounds, exploits, timeline and more. The schema notes that “for the most part, the ‘cna’ and ‘adp’ containers contain the same properties. The main differences are the source of the information.”
• Extensions are allowed. adpContainer permits properties matching ^x_[^.]*$. Supplier ADPs use this: every redhat-SADP and siemens-SADP container in our sample had "x_adpType": "supplier", and Red Hat’s also carried x_generator. These are not schema-defined fields, so treat them as hints.

providerMetadata holds orgId (a UUID, required), shortName and dateUpdated. Match publishers on orgId if you need certainty; shortName is what humans read.

The three kinds you will see

CISA-ADP: prioritization signals

The cvelistV5 README says the CISA ADP provides three things: SSVC, KEV catalog data, and “Vulnrichment” updates such as “missing CVSS, CWE, CPE information for CVE Records that meet specific threat characteristics, and for when CNAs do not provide it themselves.”

What that looked like in our sample of 1,963 published records:

Every CISA-ADP container in the sample carried SSVC. CVSS and CWE were mostly gap-fills: 381 of the 389 CVSS entries (97.9%) and 326 of the 336 CWE entries (97.0%) sat on records whose CNA container had none. That matches the Vulnrichment README: “For those CVEs that do not already have these fields populated by the originating CNA, CISA will populate the associated ADP container with those values when there is enough supporting evidence to do so. At no point will CISA overwrite the originating CNA’s data in the original CNA container.”

The exceptions matter. In 8 records both the CNA and CISA-ADP carried a CVSS score, and they did not always agree: in CVE-2026-70373 the CNA (TuranSec) published CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8) while CISA-ADP published .../C:H/I:N/A:N (6.5). We did not check which came first. The point is that a parser which picks “the first CVSS it finds” will produce different answers depending on container order.

The KEV block is small: dateAdded and a link to the catalog. Treat it as a pointer, and use the KEV catalog itself for dueDate, requiredAction and ransomware use. Our KEV JSON feed field guide covers those fields, and the Vulnrichment SSVC guide covers the three SSVC values.

The CVE Program Container: references you must not skip

The cvelistV5 README is explicit. The container has title “CVE Program Container” and shortName “CVE”, and “all CVE Program-added references after 7/31/2024 for a CVE Record will be stored in the CVE Program Container of that Record. CNA-provided references will continue to be stored in the CNA Container.”

It also says what tools must do: “to retrieve all information about a reported vulnerability in the CVE Repository, tool vendors and community users will need to examine the CVE Record CNA Container and the CVE Program Container (if one exists). These two containers are minimally required to obtain the core information required by the Program. All other ADP containers remain optional from a Program perspective.”

Two practical consequences:

• References tagged x_transferred were copied from the CNA container on July 31, 2024, so expect duplicates. The README says downstream users “will have to determine the appropriate way to resolve potential reference duplications.” Deduplicate on URL.
• New records only get this container if the Program adds something. In our 2026 sample, 43 records (2.2%) had one.

Supplier ADPs: a vendor’s view of someone else’s CVE

Supplier ADP containers let a vendor that ships an upstream component add its own product data to a CVE that a different CNA assigned. Siemens describes its SADP as useful when “a supplier like Siemens wants to add information to a vulnerability” in an upstream dependency, and says it was introduced in April 2026 after a pilot. Its stated aim is better scanner matching for affected Siemens products, with “known-not-affected” product data planned later.

In our sample, 24 published records (1.2%) carried one: 18 from redhat-SADP, 6 from siemens-SADP. Their shapes differ:

• redhat-SADP containers looked like a full advisory: affected entries per Red Hat product stream with CPEs, package names and RPM versionType, plus Red Hat’s severity rating, CVSS, solutions, workarounds and references.
• siemens-SADP containers were lean: affected entries for Siemens products, references to the Siemens advisory, and nothing else. All had defaultStatus set to unknown.

Two traps. First, supplier affected data describes the supplier’s product names and version strings, not the upstream project’s. A Red Hat entry such as defaultStatus: affected with lessThan: "*" and status: unaffected from a fixed RPM version is a statement about that Red Hat package, which is how our affected-versions guide explains these encodings. Second, supplier severity ratings and CVSS are the supplier’s assessment for its builds and can legitimately differ from the CNA’s.

One record, four publishers

CVE-2026-46300 is a Linux kernel flaw assigned by the Linux CNA and added to the KEV catalog on October 28, 2026. Its record shows why you need a per-provider view. This is the output of the script in the next section against the cvelistV5 file at commit 1a44d59:

CVE-2026-46300 PUBLISHED dataVersion 5.2

[cna] Linux (updated 2026-08-05)
  cvss: ['3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H']
  affected_products: 2
  references: 8

[adp] CVE (updated 2026-05-23)
  references: 4

[adp] redhat-SADP (updated 2026-09-01)
  other: ['Red Hat severity rating: Important']
  cvss: ['3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H']
  cwe: ['CWE-123']
  affected_products: 39
  references: 36
  solutions: 33
  workarounds: 1
  x_adpType: supplier

[adp] siemens-SADP (updated 2026-10-15)
  affected_products: 10
  references: 2
  x_adpType: supplier

[adp] CISA-ADP (updated 2026-10-29)
  ssvc: Exploitation=active, Automatable=no, Technical Impact=total
  kev: dateAdded=2026-10-28
  cwe: ['CWE-456']
  references: 1

Read it as five separate statements:

• The CNA says what the kernel project considers affected and scores it 7.8. It gives no CWE.
• The CVE Program added four references a tool reading only the CNA container would miss.
• Red Hat lists 39 affected product entries for its own streams with 33 solutions, rates it Important, and maps it to CWE-123.
• Siemens lists 10 affected product entries for its own devices.
• CISA says exploitation is active, records the KEV date, and maps it to CWE-456, a different CWE from Red Hat’s.

None of these overrides the others. A kernel team, a RHEL fleet owner and an OT engineer running Siemens PLCs each need a different slice of the same record.

A tested script: who said what

This Python script prints one block per container. It uses only the standard library and was run with Python 3.13 against the record above and against the 2,000-record sample.

#!/usr/bin/env python3
"""Print who said what in a CVE JSON 5 record: one line per container and field."""
import json, sys

def summarize(container):
    out = {}
    for m in container.get("metrics", []):
        for k, v in m.items():
            if k.startswith("cvss"):
                out.setdefault("cvss", []).append(f"{v['version']} {v['baseScore']} {v['vectorString']}")
            elif k == "other":
                t, c = v.get("type"), v.get("content", {})
                if t == "ssvc":
                    out["ssvc"] = ", ".join(f"{k2}={v2}" for o in c["options"] for k2, v2 in o.items())
                elif t == "kev":
                    out["kev"] = f"dateAdded={c.get('dateAdded')}"
                else:
                    out.setdefault("other", []).append(f"{t}: {c.get('value', c)}")
    cwes = [d["cweId"] for p in container.get("problemTypes", []) for d in p.get("descriptions", []) if d.get("cweId")]
    if cwes: out["cwe"] = cwes
    if container.get("affected"): out["affected_products"] = len(container["affected"])
    if container.get("references"): out["references"] = len(container["references"])
    for k in ("solutions", "workarounds"):
        if container.get(k): out[k] = len(container[k])
    if "x_adpType" in container: out["x_adpType"] = container["x_adpType"]
    return out

rec = json.load(open(sys.argv[1]))
c = rec["containers"]
rows = [("cna", c["cna"])] + [("adp", a) for a in c.get("adp", [])]
print(rec["cveMetadata"]["cveId"], rec["cveMetadata"]["state"], "dataVersion", rec.get("dataVersion"))
for kind, cont in rows:
    pm = cont["providerMetadata"]
    print(f"\n[{kind}] {pm.get('shortName')} (updated {pm.get('dateUpdated', '?')[:10]})")
    for k, v in summarize(cont).items():
        print(f"  {k}: {v}")

Run it with python3 containers.py CVE-2026-46300.json, using a record file from the cvelistV5 repository (cves/2026/46xxx/CVE-2026-46300.json). It is a reading aid, not a merge engine; the next section is about merging.

How to merge ADP data without lying to yourself

There is no Program-defined precedence between ADPs. The following policy is our editorial recommendation, built on the rules quoted above:

1. Always read cna and the CVE container. The README calls them the minimum. Union and deduplicate references across both.
2. Store values with their provider. Keep cvss_cna, cvss_cisa_adp and cvss_supplier side by side rather than one cvss column. The same goes for CWE.
3. Prefer the CNA for scoring, fall back to CISA-ADP. Use the CNA’s CVSS when present; use CISA-ADP’s when the CNA gave none (the common case in our sample); flag disagreements for a human when both exist.
4. Take SSVC and the KEV date from CISA-ADP. No other container in our sample carried them. Then confirm KEV details against the catalog.
5. Scope supplier data to the supplier. Use redhat-SADP affected entries only to match Red Hat packages, and siemens-SADP entries only for Siemens products. Never use them to clear or confirm an upstream version.
6. Do not ignore unknown publishers. Log any new shortName so a person can decide how to treat it, rather than dropping it silently.
7. Check the record state first. A rejected record has no ADP data to act on; see our guide to CVE record states.

These steps fit into the record-reading stage of our vulnerability prioritization workflow, which takes a CVE from record to patch ticket.

Common mistakes

• Reading only containers.cna. You lose CISA’s SSVC and KEV signals, about one in five CVSS scores in our 2026 sample, and Program-added references.
• Taking adp[0]. Container order is not a precedence order. In CVE-2026-46300, CISA-ADP came last.
• Merging CWE lists without provenance. Red Hat and CISA mapped the same CVE to different CWEs. A merged list hides that they disagree.
• Matching upstream versions against supplier entries. RPM release strings and Siemens firmware versions are not kernel versions.
• Hard-coding today’s publisher list. Supplier ADP is new. More publishers will appear.

Limits of this article

The sample covers 2,000 of 84,066 2026 record files in cvelistV5 on November 3, 2026, chosen at random, and 2026 records only. Shares will differ for older years, since the README says the CISA-ADP container was launched on June 4 (2024) and applied back to February 2024. We could not load cve.org’s ADP pages (they render with JavaScript), so the description of supplier ADPs relies on Siemens’ own page and on the records themselves. x_adpType is an extension field, not part of the schema. We did not check how NVD or commercial scanners consume ADP data.

Sources and verification

Scope. This is a specification explainer with measurements from public data. We read the CVE JSON schema (version 5.2.0, CVEProject/cve-schema main branch) and its version-encoding guide, sampled 1,000 random 2026 records from the cvelistV5 repository at commit 451e97a (November 2, 2026), and ran the Python script below against real records. We did not test commercial scanners.

The short answer

A CVE record’s affected block does not hand you a list of bad versions. For each product it gives a small decision procedure:

1. Walk the versions list in order.
2. An entry with only version and status matches that exact version.
3. An entry with versionType plus lessThan or lessThanOrEqual matches a range, and an optional changes list can flip the status partway through it.
4. The first matching entry wins. If nothing matches, the answer is defaultStatus, and if that is missing, the answer is unknown.

The possible answers are affected, unaffected and unknown. Your tooling needs a fourth, “I cannot order these versions”, because the record does not always give you enough to decide.

Where the fields live

The CNA (CVE Numbering Authority) writes containers.cna.affected, an array of product objects. The schema requires each product to be identified by either vendor and product or collectionURL and packageName, and to carry versions, defaultStatus or both. A 5.2 record can also carry a packageURL (a purl, which the schema says must not include a version).

{
  "vendor": "GitoxideLabs",
  "product": "gitoxide",
  "defaultStatus": "unaffected",
  "packageURL": "pkg:cargo/gix-fs",
  "versions": [
    {"version": "0", "status": "affected", "versionType": "semver", "lessThan": "0.23.0"},
    {"version": "0.23.0", "status": "unaffected", "versionType": "semver"}
  ]
}

That is the product entry from CVE-2026-100419 (a gix-fs symlink worktree escape), shown in full. Read it as: semantic versions from 0 up to but not including 0.23.0 are affected, 0.23.0 is unaffected, and anything else is unaffected by default.

The fields, one by one

The upper limit can end in *, which the schema defines as “an arbitrarily large number in the version ordering”. {version: 1.0, lessThan: 1.*} describes the whole 1.x branch, and lessThan: * means “and everything after”.

Why versionType is not optional

The schema guide explains that “there is no single definition of ’less than’ for versions” and gives the example that in semantic versioning 1.0.0-cr1 sorts before 1.0.0-m1, while in Maven the opposite is true. If your code compares every version string with one generic routine, it will be wrong for some ecosystems.

The guide is blunt about custom: it “means that the version status algorithm cannot be executed, so its use is discouraged”. It exists to convert older data.

Three records, three encodings

Allow-list style (gix-fs, CVE-2026-100419). The range is affected and defaultStatus is unaffected. Version 0.22.1 is affected, 0.23.0 is unaffected by exact match, and 0.25.4 is unaffected by default.

List without a default (quickjs, CVE-2026-0821). The CNA lists eleven single versions from 0.1 to 0.11.0 as affected and sets no defaultStatus. Version 0.10 is affected. Version 0.12.0 is unknown: the record makes no claim about it. A naive matcher that treats “not listed” as “not affected” would clear it.

Deny-list style (Linux, CVE-2026-100075). The second product entry sets "defaultStatus": "affected" and lists unaffected ranges per stable branch:

{"version": "4.7", "status": "affected"},
{"version": "0", "lessThan": "4.7", "status": "unaffected", "versionType": "semver"},
{"version": "6.6.157", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"},
{"version": "7.3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}

(Excerpt; the record also lists 5.10, 5.15, 6.1, 6.12, 6.18 and 7.2 branches.) Kernels before 4.7 are unaffected, 6.6.157 and later 6.6 releases are unaffected, and anything not covered, such as 6.6.150 or a 5.4 kernel, falls through to affected. The first product entry in the same record describes the same flaw with versionType: git commit ranges, which you cannot evaluate without the kernel’s commit history.

What a sample of 2026 records contains

We drew 1,000 CVE IDs at random (seeded) from the 83,665 record files under cves/2026 at cvelistV5 commit 451e97a. 16 were REJECTED; the 984 published records held 2,061 product entries, 4,555 version entries and 2,831 ranges. Counts were computed with a Python script over the JSON.

Two numbers matter most for automation. More than half of product entries leave unlisted versions as unknown, and about a third of ranges use custom, so a generic comparator cannot decide them. This is one sample at one point in time; the mix varies by CNA, and a different year or sample would give different shares.

A tested evaluator

The script implements the schema’s algorithm. It handles dotted numeric versions (so 1.2.10 sorts after 1.2.9) and *, and it refuses any range whose versionType it has not been told how to order. It does not implement semver pre-release ordering, RPM epochs or Maven qualifiers; treat it as a reference, not a drop-in matcher. Python 3.10 or later, standard library only.

#!/usr/bin/env python3
"""Decide affected / unaffected / unknown for one product version from a CVE record,
following the algorithm in the CVE JSON 5 schema (product.versions + defaultStatus).
Usage: affected_status.py RECORD.json VERSION [vendor/product filter] [--numeric TYPE,...]
"""
import json, sys

SUPPORTED = {"semver"}  # extend with real comparators (rpm, maven, python...) before use

def key(v):
    parts = []
    for p in v.split("."):
        if p == "*":
            parts.append(float("inf"))
        elif p.isdigit():
            parts.append(int(p))
        else:
            raise ValueError(f"non-numeric version part {p!r} in {v!r}")
    return parts

def cmp(a, b):
    ka, kb = key(a), key(b)
    n = max(len(ka), len(kb))
    # pad: a missing part is 0, except after a wildcard, which stays infinite
    ka += [float("inf") if ka and ka[-1] == float("inf") else 0] * (n - len(ka))
    kb += [float("inf") if kb and kb[-1] == float("inf") else 0] * (n - len(kb))
    return (ka > kb) - (ka < kb)

def status(product, v):
    for e in product.get("versions", []):
        is_range = "lessThan" in e or "lessThanOrEqual" in e
        if not is_range:
            if v == e["version"]:
                return e["status"], "exact match"
            continue
        vt = e.get("versionType")
        if vt not in SUPPORTED:
            return "undetermined", f"range uses versionType {vt!r}; needs that ordering"
        lo_ok = cmp(e["version"], v) <= 0
        hi_ok = (cmp(v, e["lessThan"]) < 0) if "lessThan" in e else (cmp(v, e["lessThanOrEqual"]) <= 0)
        if lo_ok and hi_ok:
            s = e["status"]
            for c in sorted(e.get("changes", []), key=lambda c: key(c["at"])):  # schema: re-sort yourself
                if cmp(c["at"], v) <= 0:
                    s = c["status"]
            return s, "range match"
    return product.get("defaultStatus", "unknown"), "defaultStatus" + ("" if "defaultStatus" in product else " (absent, so unknown)")

if __name__ == "__main__":
    args = sys.argv[1:]
    if "--numeric" in args:  # opt-in: treat these extra versionTypes as dotted numeric
        i = args.index("--numeric")
        SUPPORTED.update(args[i + 1].split(","))
        del args[i:i + 2]
    sys.argv[1:] = args
    rec = json.load(open(sys.argv[1]))
    version = sys.argv[2]
    want = sys.argv[3].lower() if len(sys.argv) > 3 else ""
    if rec["cveMetadata"]["state"] != "PUBLISHED":
        sys.exit(f"{rec['cveMetadata']['cveId']} is {rec['cveMetadata']['state']}")
    for i, p in enumerate(rec["containers"]["cna"].get("affected", [])):
        name = f"{p.get('vendor', '')}/{p.get('product', p.get('packageName', ''))}"
        if want and want not in name.lower():
            continue
        print(f"{rec['cveMetadata']['cveId']} [{i}] {name} {version}: %s (%s)" % status(p, version))

We ran it with Python 3.13 on November 2, 2026 against records downloaded from cvelistV5 (raw.githubusercontent.com/CVEProject/cvelistV5/<commit>/cves/2026/<block>/<CVE>.json). Selected output:

CVE-2026-100419 [0] GitoxideLabs/gitoxide 0.22.1: affected (range match)
CVE-2026-100419 [0] GitoxideLabs/gitoxide 0.23.0: unaffected (exact match)
CVE-2026-100419 [0] GitoxideLabs/gitoxide 0.25.4: unaffected (defaultStatus)
CVE-2026-0821 [0] quickjs-ng/quickjs 0.12.0: unknown (defaultStatus (absent, so unknown))
CVE-2026-100075 [0] Linux/Linux 6.6.150: undetermined (range uses versionType 'git'; needs that ordering)
CVE-2026-100075 [1] Linux/Linux 6.6.150: undetermined (range uses versionType 'original_commit_for_fix'; needs that ordering)
CVE-2026-103345 [0] Shamim Rajani/Pie Register 3.8.4.13: undetermined (range uses versionType 'custom'; needs that ordering)
CVE-2026-23915 is REJECTED

The Linux result is the instructive one. For 6.6.150 the evaluator reaches the 7.3 ... * entry, whose versionType is original_commit_for_fix, a value that is not among the schema’s examples. A strict implementation stops there. If you decide, for this CNA’s data, that those values are ordinary kernel version numbers, you can opt in with --numeric original_commit_for_fix, and the second product entry then gives 4.4.302 unaffected, 4.7 affected, 6.6.150 affected (by defaultStatus), 6.6.157 unaffected and 7.3 unaffected. That opt-in is our judgment about one CNA’s encoding, not something the schema states.

Common mistakes

• Treating “not listed” as “not affected”. Without defaultStatus: unaffected, unlisted versions are unknown.
• Off-by-one on the upper bound. lessThan: 0.23.0 excludes 0.23.0; lessThanOrEqual: 3.8.4.13 includes 3.8.4.13.
• Comparing strings. As text, “0.10” sorts before “0.9”. Parse versions with the ecosystem’s rules.
• Assuming changes is sorted. The schema tells clients to re-sort.
• Reading only the first product entry. The same record can describe a product twice, as the Linux record does with git ranges and version ranges.
• Ignoring the record state. A REJECTED record has no affected block to evaluate; see CVE record states.

Where this fits in triage

Version matching answers “do we run an affected version?”, which comes before any priority signal. If the answer is unknown or undetermined, check the vendor advisory, or a supplier VEX statement that says whether the product is affected (see how to read a VEX not-affected statement). An SBOM with accurate component versions is what makes this lookup possible at scale; our summary of the 2026 SBOM minimum elements covers what to ask suppliers for. Once a finding is confirmed as affected, our vulnerability prioritization workflow takes it from record to ticket using KEV, EPSS and SSVC.

Limits of this article

The sample covers 2026 records only and reflects the repository on November 2, 2026; CNAs update records, so shares will drift. Our evaluator is a reference implementation of the schema’s algorithm for numeric versions, not a full comparator for semver pre-releases, RPM, Maven, Python or git ranges. We did not examine ADP containers, which can carry their own affected data (15 of the 984 sampled records had one), or NVD’s separate CPE configurations.

Sources and verification