Re-score the report yourself using the same scoring system the researcher used, usually CVSS, write down each assumption, and share the reasoning. A CVSS base score measures severity of the flaw itself, not your actual risk, so differences are normal and can be discussed calmly.
What CVSS does and does not say
The Common Vulnerability Scoring System is an open framework for communicating the characteristics and severity of software vulnerabilities. FIRST, which maintains it, states in the CVSS v4.0 user guide that base scores are designed to measure severity and should not be used alone to assess risk. The base score reflects intrinsic characteristics and is independent of threat and of the environment where the system runs.
That means two honest people can reach different numbers. The difference usually comes from a handful of choices.
Where scores usually diverge
| Question | Why it moves the score |
|---|---|
| Does the attacker need an account? | Required privileges change the vector |
| Does the user have to click something? | User interaction lowers severity |
| Is the vulnerable component exposed by default? | Preconditions affect attack requirements |
| What data or systems are actually affected? | Impact on confidentiality, integrity, availability |
| Is it reachable in your deployment? | Environmental context, applied by the consumer |
The FIRST guide notes that applying Environmental and Threat metrics is the responsibility of the CVSS consumer, and that maintainers typically publish base scores only. So when you score your own product, you are making the base call and your customers will adjust for their setting.
A calm way to handle the disagreement
- Reproduce first, as described in reproducing a report safely.
- Score the issue independently before reading their vector.
- Compare the two vectors metric by metric. Disagreement is often on one or two lines.
- Reply with your vector and one sentence per differing metric.
- Ask whether they saw something you did not, such as a precondition that is easy to meet.
- Fix based on your own priority, not on the argument.
Keep severity out of the fix decision where you can. A medium issue in an internet facing login flow may deserve faster attention than a high issue behind several preconditions.
Words to avoid in the reply
- "Your score is wrong."
- "Nobody could exploit this."
- "That is just theoretical."
Better phrases are "we scored the attack requirements as present because..." and "we would raise this if the default configuration exposes it."
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the check and notice how exploitability context changes how urgent a finding is, even when the headline severity stays the same.
For flaws in a library you ship, Safeguard's reachability analysis can show whether your code path reaches the vulnerable function, which is useful evidence when you explain why your score differs. There is also a free scan.
Quick check
Does a CVSS 9.8 always mean we must drop everything?
No. The base score measures severity of the flaw. Your priority also depends on exposure, whether exploitation is happening, and what the affected component holds.
Should the published advisory use the researcher's score or ours?
Use the score you can defend, include the vector so readers can see the metrics, and credit the researcher for the finding.
Sources
Last reviewed: 19 October 2026.
