more eyes

What Can You Check About a Vulnerability Report?

Questions to ask before you decide it applies to you

This note sets out what a vulnerability report would have to show before it applies to one system. It does not rate any vulnerability or any project.

Document	what-can-you-check-about-a-vulnerability-report.md
Version	0.3 — draft
Audience	People who hear that software they use has a vulnerability and must decide what to do: read Start here. Technical reviewers: read the full note.
Method	Separate four questions that a report can answer. Read the public formats that carry vulnerability reports, and the stated practice of one project and one distributor, against those questions. Tie each statement to a pinned source.
Changes	See the changelog.
Scope	The CVE record format 5.2.0, CVSS versions 4.0 and 3.1, the OpenVEX specification 0.2.0, the Linux kernel’s CVE process document at tag v7.3, and the Debian security FAQ, read on 1 November 2026. This is not a finding about any vulnerability, a review of any project’s security work, or a survey of how often reports are wrong.

Contents

• Start here
• 1. What the note establishes
  • 1.1 Evidence
  • 1.2 Terms
• 2. Four questions for one report
• 3. Public records
  • 3.1 The CVE record format
  • 3.2 CVSS version 4.0
  • 3.3 The Linux kernel’s CVE process
  • 3.4 A distributor’s advisories: Debian
  • 3.5 OpenVEX status and justifications
• 4. Who answers which question
• 5. From a headline to one system
• 6. Questions that make a claim reviewable
• 7. Limits and source use
• 8. References
• Changelog

Start here

This section is for anyone who reads that software they rely on has a security flaw. You do not need to read code to use it. The rest of the note is the record behind each question.

What a vulnerability report is. A report says that some software has a flaw that an attacker could use. It can be a short public record with an ID number, such as a CVE (a public catalog number for one vulnerability). It can be a project’s own advisory, a severity score, or a news story that retells all of these.

Why it matters. A report about a piece of software is not yet a report about your machine. Large programs have many optional parts. A flaw can sit in a part that your copy leaves out, or that your settings never turn on. Some flaws need an attacker who already has an account on the machine. A headline usually drops these conditions. The conditions decide whether the flaw applies to you.

The questions that matter.

1. What exactly is the flaw? Ask for the fix: the code change, and the versions before and after it. A report with a fix can be checked. See §2.
2. Is the flawed code in your copy? Your copy may come from a distributor, such as a Linux distribution, that builds the software its own way. Ask whether that build includes the flawed part. See §3.4.
3. Can an attacker reach it on your system? Ask what the attacker needs: a network path, an account, a setting that is turned on. See §3.2.
4. What has anyone shown? A crash, a working demonstration, and attacks seen in use are different evidence. Ask which one the report has. See §3.2.
5. Who said it? The project that fixed the flaw, the scorer, your distributor, and a news story answer different questions. Ask whose statement you are reading. See §4.

How to judge an answer. A good answer names something you can check: a fix, a version, a build setting, a condition. A weak answer repeats “critical” or “everyone is affected” in different words. A weak answer does not show that the flaw is harmless. It shows that its reach to your system is not shown yet.

What this note does not do. It does not tell you to skip an update. The Linux kernel’s own document recommends taking every released fix, not choosing among them (§3.3). The note helps you read a report so you can judge how urgent it is for you. It does not judge any report.

1. What the note establishes

A claim that a vulnerability affects a system needs a defined object: one flaw, in one piece of software, at one version, built one way, configured one way, and reachable by an attacker in a stated position. “There is a CVE”, “it scores 9.8”, and “your system is exposed” describe different things. None follows from the others.

This note reads the formats that carry vulnerability reports and the stated practice of one project and one distributor. It does not assess any vulnerability, test any system, or check any report against its fix. Formats and practices change, so a later reading can differ.

1.1 Evidence

Each record in §3 has: claim; object and date; public source; what was read; result; unresolved. The fixed entries “Not applicable” and “Not read for this note” have the meanings in the release note §1.1. A statement by a project or a distributor about its own practice is recorded as that party’s statement.

1.2 Terms

Terms from the release note §1.2 keep their meaning, and presence and reachability keep the meaning in Which Code Actually Runs? §1.2. This note adds the following.

Term	Meaning here
Vulnerability	A flaw in software that an attacker could use to do something the software should not allow.
Report	Any public statement that a vulnerability exists: a CVE record, a project advisory, a distributor advisory, a score, or a retelling of one of these.
CVE record	The public entry for one CVE ID, in the CVE record format.
Assigner	The party that created a CVE record. The CVE record format calls it the CNA, CVE Numbering Authority.
Fix	The code change that removes the flaw, identified by a commit or a version.
Affected range	The versions that contain the flaw, as a report states them.
Build	One compiled copy of the software, with the options chosen when it was compiled. Two builds of one version can include different code.
Configuration	The settings of one running system, including which optional features are turned on.
Attacker position	What an attacker needs before the attack starts: network access, an account, local access, or physical access.
Exploit	Code or instructions that use a vulnerability. A proof of concept shows the flaw can be triggered. Exploitation in use means attacks against real systems have been reported.
Severity score	A number that rates a vulnerability under stated assumptions. This note reads CVSS versions 4.0 and 3.1.
Applicability	Whether a vulnerability affects one system. The Linux kernel’s document uses this word.

2. Four questions for one report

A report can answer up to four questions. Each one has its own evidence. An answer to one does not answer the next.

Question	What it asks	What would answer it
1. Defined	Is there a specific flaw?	A fix commit, an affected range, and the files or functions changed
2. Present	Is the flawed code in this build?	The build options, the distributor’s statement for its package, or the package’s changelog
3. Reachable	Can an attacker in a stated position reach the flawed code on this system?	The configuration the attack needs, the attacker position, and whether this system matches both
4. Shown	What has been demonstrated?	A crash report, a proof of concept, or a report of exploitation in use, each with its conditions

The questions follow the path from a project to one system. Question 1 is about the source code. Question 2 is about one build. Question 3 is about one running system. Question 4 is about evidence, and its answer holds only under the conditions in which the evidence was produced.

A severity score is not a fifth question. It combines answers to these questions under assumptions, and §3.2 records what those assumptions are.

3. Public records

3.1 The CVE record format

Claim. A CVE record must name affected products, a description, and references. It can also state the configurations an attack needs, the affected files and functions, exploits, and scores, but none of these is required.

Object and date. The CVE record format schema, version 5.2.0, in the CVEProject/cve-schema repository at commit ce5f5c8. Read 1 November 2026.

Public source. Listed in §8.

What was read. The schema’s definitions of the CNA container, the affected product, version status, configurations, exploits, metrics, and impacts.

Result.

• Required fields. The schema requires four fields in the assigner’s container: providerMetadata, descriptions, affected, and references. The fields for configurations, exploits, workarounds, impacts, and metrics are optional.
• Configurations. The schema defines configurations as “Configurations required for exploiting this vulnerability.” It is free text.
• Where the flaw is. A product entry can list modules, programFiles (“A list of the affected source code files”), and programRoutines, the affected functions. All three are marked optional.
• Version status. A version is affected, unaffected, or unknown. The schema says unknown “indicates that it is unknown or unspecified whether the given version is affected.” For versions not listed, “If not specified, defaultStatus defaults to ‘unknown’.”
• Scores and their scenario. A metrics entry can carry a CVSS score in version 4.0, 3.1, 3.0, or 2.0, as the fields cvssV4_0, cvssV3_1, cvssV3_0, and cvssV2_0, and a scenarios field. If no scenario is given, “GENERAL is used as the default and applies when no more specific metric matches.”
• More than one author. The schema allows one assigner container per record, and further containers from Authorized Data Publishers. Each container names its provider. One CVE record can therefore hold statements from more than one party.

Unresolved. The note read the schema, not the CVE Program’s rules for assigners. It did not read how often records use the optional fields. It did not read any CVE record.

3.2 CVSS version 4.0

Claim. A CVSS Base score assumes the reasonable worst case across deployments, and assumes any configuration that an attack needs. Adjusting a score to one environment, and to known exploitation, is the consumer’s job. Version 3.1 makes the same assumption about configuration, but uses different metrics, so a score is read with its version.

Object and date. The CVSS version 4.0 specification document, document version 1.2, published by FIRST on its website, and the CVSS version 3.1 specification document, also on FIRST’s website. Neither page has a fixed version link. Both read 1 November 2026, from the pages’ HTML.

Public source. Listed in §8.

What was read. For version 4.0: the introduction, the nomenclature section, the Base metrics guidance, the Attack Vector, Attack Requirements, and Privileges Required metrics, and the Threat metrics. For version 3.1: the introduction, the Base metrics guidance, the Exploit Code Maturity metric, and the vector string section.

Result.

• What the Base score assumes. The Base score “assumes the reasonable worst-case impact across different deployed environments.”
• Configuration. The specification says that “if a specific configuration is required for an attack to succeed, the vulnerable system should be assessed assuming it is in that configuration.” A Base score therefore does not lower for a feature that is off by default.
• Attack requirements. The Attack Requirements metric “captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack.” Its values are None and Present.
• Attacker position. The Attack Vector metric has four values: Network, Adjacent, Local, and Physical. Privileges Required records what access the attacker needs first.
• Who adjusts the score. “The application of Environmental and Threat metrics is the responsibility of the CVSS consumer.” The specification says assessment providers “typically provide only the Base Scores”.
• Exploitation by default. When no threat information is given, the Exploit Maturity value Not Defined “is equivalent to Attacked (A) for the purposes of the calculation of the score by assuming the worst case.”
• Labels. The specification defines the labels CVSS-B, CVSS-BT, CVSS-BE, and CVSS-BTE, which name the metric groups used. It says the labels “should be used wherever a numerical CVSS value is displayed or communicated.”
• Versions. A score belongs to one version of the specification. A vector string starts with its version: version 3.1’s “begins with the label “CVSS:” and a numeric representation of the current version, “3.1””, and version 4.0 vectors begin CVSS:4.0/. The CVE record format accepts scores in CVSS versions 2.0, 3.0, 3.1, and 4.0 (§3.1), so one record can carry scores in more than one version. A number given without its vector does not show which version produced it.
• What differs in version 3.1. Version 3.1 has three metric groups: Base, Temporal, and Environmental. It has no Attack Requirements metric and no Supplemental group, and its exploit metric sits in the Temporal group. The two versions compute scores from different metrics, so a 3.1 score and a 4.0 score for one flaw are not the same measurement.
• What stays the same. Version 3.1 gives the same rule on configuration: “the vulnerable component should be scored assuming it is in that configuration.” Its Exploit Code Maturity value Not Defined also “has the same effect on scoring as assigning High.”

Unresolved. The note did not read CVSS versions 2.0 or 3.0. It did not read how many records, or which assigners, use each version. It did not read the score formulas of either version, the version 4.0 Supplemental metrics, or the version 3.1 Scope metric in detail. Both pages were first read as HTML through a text extraction, not through a summarizer. On 1 November 2026 each quote in this section was checked against the text of the rendered pages, and each matched.

3.3 The Linux kernel’s CVE process

Claim. The Linux kernel’s own assigner gives a CVE to any bug fix it identifies, and states that only the user can decide whether a kernel CVE applies to a system.

Object and date. Documentation/process/cve.rst in the Linux kernel source at tag v7.3, commit c03c1a1. Read 1 November 2026.

Public source. Listed in §8.

What was read. The whole document.

Result.

• What gets a CVE. The document says the assignment team “is overly cautious and assign CVE numbers to any bugfix that they identify.” It gives the reason: at the kernel’s layer, “almost any bug might be exploitable”, and this is often not evident when the bug is fixed.
• When. Assignment happens after a fix is in a stable kernel tree, and each CVE “will be tracked that way by the git commit id of the original fix.”
• Applicability. “the applicability of any specific CVE is up to the user of Linux to determine, it is not up to the CVE assignment team.” The document gives the reason: “any one system only uses a small subset of the source tree”.
• Volume. The document says users “should be aware that large numbers of assigned CVEs are not relevant for their systems.”
• Taking fixes. The same section says “it is best to take all released kernel changes”, tested together, rather than individual fixes. It adds that some changes without a CVE “might be relevant to take.”
• Disputes. Only the maintainers of the affected subsystem can dispute or modify a kernel CVE.

Unresolved. The note did not read the linux-cve-announce archive or any kernel CVE record. It did not read the kernel’s separate security bug reporting process. It did not read how kernel CVE records fill the optional fields in §3.1.

3.4 A distributor’s advisories: Debian

Claim. Debian fixes security issues in a stable release by applying the fix to the version it shipped, so an upstream version number alone does not show whether a Debian package is fixed. Debian does not use CVSS scores when it triages.

Object and date. The Debian security FAQ on the Debian website, last modified 17 September 2026 according to the page. Read 1 November 2026, from the page’s HTML.

Public source. Listed in §8.

What was read. The answers on fixing old package versions, on version numbers, on CVSS scores, and on the security tracker.

Result.

• Backported fixes. “Instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release.” The FAQ’s reason is that a release should change as little as possible.
• How to check. The FAQ says to check the package changelog, or to compare the exact version number “with the version indicated in the Debian Security Advisory.”
• Scores. “Debian does not provide CVSS scores and doesn’t use CVSS scores from external sources when triaging security issues.”
• Per-CVE status. The FAQ says the state of each CVE ID can be checked in the Debian Security Tracker. Its notes can say that an issue “doesn’t warrant a Debian security update”.

Unresolved. The note did not read the Debian Security Tracker itself or any advisory. It did not read how Debian records a CVE as not affecting a package. Other distributors were not read. The page was first read as HTML through a text extraction, not through a summarizer. On 1 November 2026 each quote in this section was checked against the text of the rendered page, and each matched.

3.5 OpenVEX status and justifications

Claim. OpenVEX gives a supplier a fixed way to say that a product is not affected by a vulnerability, and requires a reason. Its five reasons separate presence of the code from reachability of the code.

Object and date. The OpenVEX specification, version 0.2.0, in the openvex/spec repository at commit 93139bd. Read 1 November 2026.

Public source. Listed in §8.

What was read. The statement fields, the status labels, and the status justifications.

Result.

• Four statuses. A statement has one of not_affected, affected, fixed, or under_investigation. The last one means “It is not yet known whether these product versions are affected by the vulnerability.”
• A reason is required. A not_affected statement “MUST include either a status justification or an impact_statement”. An affected statement must include an action statement.
• Five justifications. Two concern presence: component_not_present, and vulnerable_code_not_present. For the second, the specification says the case typically occurs “when source code is configured or built in a way that excluded the vulnerable code.” Two concern reachability: vulnerable_code_not_in_execute_path and vulnerable_code_cannot_be_controlled_by_adversary. One concerns protections: inline_mitigations_already_exist.
• Limits stated in the specification. For the last two, the specification says the justification “could be difficult to prove conclusively.”

Unresolved. The note did not read the CSAF VEX profile or the 2022 status justification document that OpenVEX cites. It did not read whether any project or distributor publishes OpenVEX statements.

4. Who answers which question

Each row is one kind of report. The cells say which of the four questions in §2 that kind of report can answer, according to the records in §3. A cell is a summary; the record has the source.

Report	1. Defined	2. Present	3. Reachable	4. Shown
CVE record	Affected products and versions are required. Files and functions are optional.	Not answered for a build. The record covers a product and versions.	configurations is optional free text.	exploits is optional.
CVSS Base score	Not applicable	Not applicable	Attack Vector, Attack Requirements, and Privileges Required describe the attacker’s needs, scored assuming the configuration is present	Exploit Maturity is a Threat metric, and defaults to the worst case when not set
Linux kernel CVE	Tied to the commit of the fix	The document says this is the user’s to determine	The document says this is the user’s to determine	Not stated; the document says exploitability is often not evident at the fix
Debian advisory or tracker	Refers to the CVE ID	States the fixed package version for Debian’s build	Notes can say an issue does not warrant an update; not read in detail	Not read for this note
OpenVEX statement	Refers to a vulnerability ID	component_not_present and vulnerable_code_not_present	vulnerable_code_not_in_execute_path and vulnerable_code_cannot_be_controlled_by_adversary	Not applicable
News or social post	Not applicable as a source; it retells another report	Not applicable	Not applicable	Not applicable

Four points explain most of the table.

• The assigner and the user answer different questions. The kernel’s assigner answers question 1 and states in writing that it does not answer questions 2 and 3. A kernel CVE is a record of a fix, not a statement that any system is exposed.
• A Base score is a worst case by design. CVSS assumes the configuration the attack needs. A flaw in an optional feature gets the same Base score whether that feature is on in every deployment or in none. The score does not say which.
• Version numbers mislead across builds. A distributor that backports fixes keeps the old version number. Comparing an upstream affected range with a distributor’s version number can give the wrong answer in both directions.
• “Not affected” needs a reason. OpenVEX requires one, and splits the reasons into presence and reachability. A supplier statement without a reason does not show which question it answers.

5. From a headline to one system

This section walks one kind of report through the four questions. It describes a pattern, not an incident.

A headline says that a flaw in a widely used operating system kernel lets a remote attacker take control. The flaw is in an optional network protocol. The project fixed it, and its assigner created a CVE with a high Base score.

Step	What the reader has	What the reader still needs
Headline	A product name and a severity word	Everything below
CVE record	A fix commit and an affected range (question 1)	Whether this system’s build includes the protocol
Base score	A worst-case rating that assumes the protocol is in use	This system’s configuration and attacker position
Distributor’s record	Whether the distributor’s build includes the code, and which package version has the fix (question 2)	Whether the protocol is turned on here
This system’s configuration	Whether the protocol is enabled, and whether an attacker can send it traffic (question 3)	Whether the attack has been shown under these conditions
Exploit evidence	A proof of concept or reports of attacks, with their conditions (question 4)	—

At each step the claim can narrow. “All systems running this kernel” becomes “systems whose build includes the protocol”, then “systems that turn it on”, then “systems an attacker can reach with it”. The flaw in the code is real at every step. What narrows is the set of systems where an attacker can use it.

The narrowing works in both directions. A configuration that is off by default can be on in a particular deployment. A reader who stops at the headline can overstate the risk. A reader who stops at “it’s off by default” can understate it for a system where someone turned it on.

6. Questions that make a claim reviewable

If the claim is	Request	If the artifact is missing
Everyone running this software is affected	The affected range, and the build option or feature the flaw is in	A product name covers every build; a flaw may sit in a part some builds leave out
It’s critical, a 9.8	The full vector, including its CVSS version, and which metric groups were set	A Base score assumes the worst case and any configuration the attack needs; a number without its vector does not show which version produced it
It has a CVE, so it’s a real threat	Who assigned it, and that assigner’s stated policy	Some assigners create a CVE for every fix they identify
Our version is vulnerable	The distributor’s advisory or tracker entry for your package	An upstream version number does not show whether a backported fix is present
We’re not affected	The reason: the code is not in the build, or not reachable, or mitigated	A “not affected” statement without a reason does not say which question it answers
It’s being exploited	The report of attacks, and the conditions of the attacked systems	A worst-case default for exploit maturity is not a report of attacks
It’s not exploitable	The condition that blocks the attack, and how it was checked	OpenVEX notes that a claim that the code cannot be controlled by an attacker can be hard to prove
You don’t need to update	The specific reason this flaw does not reach this system	The kernel’s document recommends taking all released fixes, whether or not they have a CVE

7. Limits and source use

• This note reads formats and stated practices. It is not an assessment of any vulnerability, project, distributor, or scoring practice.
• No report, record, or system is assessed. The example in §5 is a pattern, not an incident.
• The note makes no claim about how often reports overstate or understate risk, or how often CVE records fill their optional fields.
• The note does not advise against updating. Deciding not to apply a fix is a decision the four questions can inform, not one this note makes.
• One project and one distributor were read. Other projects’ assigners, and other distributors, can follow different practices.
• The CVSS specification and the Debian FAQ are web pages without a fixed version link. They were read on the date given, and can change.
• A missing artifact means only that this note does not show the claim.

8. References

Each source is listed once with the version consulted and the sections that cite it.

CVE record format, at CVEProject/cve-schema commit ce5f5c8.

Reference	What it defines	Cited in
CVE_Record_Format.json	The CVE record format, version 5.2.0	§1.2, §3.1, §4

CVSS, published by FIRST.

Reference	What it defines	Cited in
CVSS v4.0 Specification Document, document version 1.2, read 1 November 2026	CVSS version 4.0 metrics, defaults, and labels	§3.2, §4, §6
CVSS v3.1 Specification Document, read 1 November 2026	CVSS version 3.1 metric groups, defaults, and vector string	§3.2, §6

Linux kernel, at tag v7.3, commit c03c1a14507dfaf8b856c2608f9ac216021fc222.

Reference	What it defines	Cited in
Documentation/process/cve.rst	The kernel’s CVE assignment process and its statement on applicability	Start here, §1.2, §3.3, §4, §6

Debian

Reference	What it defines	Cited in
Debian security FAQ, last modified 17 September 2026, read 1 November 2026	Backported security fixes, version checks, and CVSS use	§3.4, §4, §6

OpenVEX, at openvex/spec commit 93139bd.

Reference	What it defines	Cited in
OPENVEX-SPEC.md	OpenVEX version 0.2.0 statuses and justifications	§3.5, §4, §6

This repository

Reference	What it defines	Cited in
What Can You Check About a Software Release?	The fixed entries and terms	§1.1, §1.2
Which Code Actually Runs?	Presence and reachability	§1.2

Changelog

Newest first. Versioning follows STYLE.md. Version tags use the prefix vuln-v, and each version links to its tagged text.

Version	Change
0.3 — 1 November 2026	Records in the §3.2 and §3.4 Unresolved lines that the CVSS and Debian quotes were checked against the rendered pages, and matched. Completes the OpenVEX under_investigation quote in §3.5. Adds §1.2 to the “Cited in” entries for the CVE record format and the Linux kernel document.
0.2 — 1 November 2026	States in the §3.4 Unresolved line that the Debian security FAQ was read as HTML through a text extraction, and that its quotes need a check against the rendered page.
0.1 — 1 November 2026	First draft. Four questions for one report: defined, present, reachable, shown. Records for the CVE record format, CVSS versions 4.0 and 3.1, the Linux kernel’s CVE process, Debian’s security FAQ, and OpenVEX, pinned to commits or dated. A table of which report answers which question, a pattern from headline to one system, and reviewable claims.

This site is open source. Improve this page.