How Bug Severity Is Assigned Through Impact, Exploitability, and Risk Two security teams can review the same flaw and still rate it differently. One treats it as an emergency, while the other
Two security teams can review the same flaw and still rate it differently. One treats it as an emergency, while the other schedules a fix for next month.
That gap is the reason bug severity matters so much. It decides which flaws get fixed first, how large a bounty payout becomes, and how loudly a team has to warn its users.
A bug is a flaw in code that makes software act in ways its builders never planned. Bug severity is the rating that shows how much damage that flaw could cause if someone abuses it.
Severity is not the same as priority. Severity describes possible harm, while priority describes when a team decides to fix the problem, which also depends on staff and deadlines.
Most teams score flaws with CVSS, short for Common Vulnerability Scoring System. Theofficial CVSS specification calls it an open framework that gives a base score from 0 to 10.
TheNational Vulnerability Database turns those scores into labels. Checked on November 6, 2026, its bug severity bands match for CVSS v3.x and v4.0, shown below.
Rating
CVSS Score
Typical Reading
None
0.0
No measurable impact
Low
0.1 to 3.9
Limited harm, hard to use
Medium
4.0 to 6.9
Real impact, but with conditions
High
7.0 to 8.9
Serious harm, fix soon.
Critical
9.0 to 10.0
Severe harm, fix right away.
The "Typical Reading" column is an analyst summary, not official wording. Older CVSS v2.0 records used only three labels, so a legacy entry may show High where a modern one would show Critical.
The base score uses eight metrics, such as attack vector, privileges required, and user interaction. Four ideas do most of the work.
Exploitability measures how easy a flaw is to abuse, and it often moves bug severity the most. A bug reachable over the internet, with no login and no user click, scores far higher than one needing physical access to a device.
Security impact asks what an attacker gains. Reading private data, changing records, or knocking a service offline each count as a loss. In crypto, stolen funds or manipulated price data usually sits near the top.
Affected components decide how far the damage travels. The same weakness is minor on a test page but serious inside a crypto wallet system.
Incidents like acrypto exchange hack tend to be judged by which component was reached, not by how clever the entry point looked.
Vulnerability scope covers whether harm stays inside the broken component or spreads outward. CVSS tracks this through its scope metric, and a scope change makes a flaw more severe.
The NVD states that CVSS measures severity, not risk. A bug severity score describes the flaw itself. It says nothing about whether attackers are using it or how valuable the target is.
Version 4.0 adds Threat, Environmental, and Supplemental groups on top of the base score, so an organization can adjust a rating to its own setup. The NVD also assesses a published flaw with no details as a 10.0, the worst case.
Analyst interpretation: Bug severity works best as a starting point. Attacks often surface in the latest crypto news reports, and a medium flaw under attack can deserve faster action than a critical flaw nobody can reach.
Chainlink describes its approach in its smart contract research program post. Rewards follow the impact of each vulnerability, and the maximum bounty for a critical bug is $3 million.
The program covers node software, Solidity smart contracts, test-network faucets, explorers, and the Data Feeds interface. Smart contract reports need a proof of concept, meaning a working demonstration that the flaw can really be exploited.
Chainlink Price Feeds went live in 2019 to serve applications that need live crypto market data. That reach helps explain the top payout tier, since a flaw in shared data infrastructure can touch many applications at once.
The same post says CCIP went through two crowdsourced audits that awarded more than $340,000 to independent researchers. These are project statements, and an audit lowers risk without guaranteeing safety.
Teams often run a short checklist before assigning a label:
Can an outsider reach the flaw without logging in or tricking a user?
Does it touch funds, private data, or a core service?
Does the damage stay in one component or spread to others?
Is there proof that the attack really works?
A yes to most of these means higher bug severity. A no to most points toward a minor finding.
A minor finding is a flaw with limited harm, such as a display glitch or a weakness needing several unlikely conditions. Minor does not mean ignorable.
Small flaws can combine. A low-rated information leak plus a medium-rated access bug may together open a path to something serious, so careful teams recheck minor items after each major fix.
Some teams also drop the label "trivial," because it can mean a huge issue, an easy fix, or a small annoyance. Rating by real user impact keeps bug severity labels consistent from one report to the next.
Bug severity is a rating of possible harm, built from exploitability, security impact, affected components, and vulnerability scope. Critical findings combine easy access with serious damage, while minor findings cause little harm.
Scores have limits. CVSS measures the flaw, not the risk, and a 10.0 can mean details were missing. Chainlink's published program ties rewards to impact, yet audits and bounties never guarantee a flaw-free system.
The next checks worth making are the score version used, who assigned it, and whether the rating changed after the first report.
Disclaimer:
This article gives general information about security terms and is not financial, legal, or investment advice. Crypto assets carry high risk, and a security rating is not a safety guarantee. Research official project pages before making any decision.
