There's a ritual that plays out in security teams every single day. A scan finishes. A report lands in someone's inbox. And there, next to a finding titled "Reflected XSS in Search Parameter," sits a number: 9.1. Critical. Red banner. Slack alert fires. A ticket gets created with a P0 label before anyone has actually read past the score.
Nobody asks why it's a 9.1. Nobody asks whether that XSS is reachable without authentication, whether it requires a victim to click a very specific link while logged in during a leap year, or whether it even survives contact with the application's actual architecture. The number did the thinking. The number always does the thinking.
This is the quiet failure mode of the Common Vulnerability Scoring System, and it's worth talking about honestly, because CVSS isn't malicious, but it is frequently misleading, and in a few specific, describable ways, it can be shaped by people who have a financial or reputational interest in the number coming out a certain way.
What CVSS Actually Measures (and What It Doesn't)
CVSS, in its current form (3.1, with 4.0 slowly making its way into vendor advisories), is a formula. You feed it inputs attack vector, attack complexity, privileges required, user interaction, scope, and impact to confidentiality, integrity, and availability and it spits out a number between 0.0 and 10.0.
It was never designed to answer the question everyone uses it to answer, which is: how urgently should I fix this, in my environment, right now?
CVSS answers a narrower question: in a generic, theoretical deployment, with no compensating controls, how bad could this be if everything about the attack goes perfectly? That's a meaningfully different question, and the gap between them is where most of the bad decisions happen.
A vulnerability scored as 9.8 assumes network attack vector, low complexity, no privileges required, no user interaction, and total impact across confidentiality, integrity, and availability. It does not assume your WAF sits in front of it. It does not assume the endpoint is only reachable from an internal VPN. It does not know that the "impact" it's modeling requires an attacker to already have pivoted three systems deep into your network to even reach the vulnerable service. CVSS has no concept of your architecture, because CVSS was built to be portable across every architecture, which means it is, by design, blind to yours.
Where the Score Gets Gamed
Here's the part that makes people uncomfortable, so let's just say it directly: CVSS scoring is not always assigned by a neutral third party doing careful analysis. Often, it's assigned by the vendor whose product has the vulnerability, or by a researcher whose bug bounty payout is directly tied to severity, or by a security tool trying to justify its own alert volume.
A few patterns worth watching for:
Vendor-assigned scores tend to drift low. If a vendor scores its own CVE, there's a quiet incentive to understate impact. A "high" that should be "critical" doesn't trigger the same emergency patch cycles, doesn't generate the same press coverage, and doesn't invite the same customer scrutiny. This isn't universal, but it's common enough that experienced analysts routinely re-score vendor CVEs before trusting them.
Bug bounty submissions tend to drift high. The incentive runs the opposite direction here. A researcher reporting a finding through a bounty program benefits from a higher severity rating, because payout tables are almost always tied to CVSS bands. A self-XSS with a contrived interaction chain gets described in the report as requiring "minimal user interaction" instead of "the victim must paste attacker-controlled text into their own address bar while disabling three browser protections."
Scanner vendors tend to inflate everything. This one is structural rather than personal. A commercial or open-source scanner that reports everything as "medium" doesn't renew well. A dashboard full of red critical banners looks like the tool is working hard and justifies the subscription. The result is severity inflation baked into the tooling layer, before a human even looks at the finding.
None of this means CVSS is worthless. It means CVSS is an input, not a verdict, and treating it as a verdict is how organizations end up burning three sprints patching a theoretical 9.8 while a genuinely exploitable 6.5 sits untouched in a business logic flow nobody scored at all because CVSS, notably, has no good way to score business logic flaws in the first place.
The Metric CVSS Can't Model: Business Logic
This is the blind spot that matters most for anyone running modern web applications and APIs. CVSS was designed in an era dominated by memory corruption bugs, buffer overflows, and clearly defined technical flaws with predictable exploit mechanics. It has never been comfortable scoring the vulnerabilities that actually dominate real-world breach reports today: broken authentication flows, IDOR chains, privilege escalation through parameter manipulation, and OTP or token logic that falls apart under close inspection.
Consider an IDOR vulnerability that lets an authenticated low-privilege user access another user's invoice data by incrementing an ID in a URL. Under CVSS, this might land somewhere in the "medium" range, because it requires authentication and technically only affects confidentiality for a single object type. In practice, that same flaw, chained across an API with sequential IDs, can enumerate an entire customer database in an afternoon. The score says medium. The blast radius says catastrophic. CVSS was never built to see the chain, only the single link.
This is precisely why authentication and authorization testing keeps producing the most damaging findings in penetration tests and bug bounty programs, year after year, while consistently scoring lower than flashier, more "textbook" vulnerabilities. A SQL injection with a proof-of-concept screenshot photographs well. A subtle authorization bypass that requires understanding how three microservices trust each other's tokens does not, even though the second one is usually more dangerous.
Reading a Score Like a Skeptic
So what does a healthier relationship with CVSS actually look like? A few habits, in practice:
Ask what CVSS assumed, not what it concluded. Pull up the vector string the string of letters and numbers that looks like AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and read it as a set of assumptions rather than a black box. Does attack vector actually match your exposure? Is the endpoint really reachable over the network from an untrusted source, or is that theoretical?
Re-score internally against your own architecture. Many mature security teams maintain an internal severity adjustment layer, sometimes informally, sometimes as a documented policy, where the base CVSS score gets modified by environmental factors: is this internet-facing, is it behind authentication, does it touch regulated data, is there a compensating control already in place. The temporal and environmental metrics exist within the CVSS spec for exactly this reason, and almost nobody uses them.
Weight exploitability evidence over theoretical severity. A 7.5 with a public, working exploit and active scanning traffic in the wild deserves more urgency than a 9.1 that requires a rare configuration and has no known proof of concept. CISA's Known Exploited Vulnerabilities catalog exists precisely because CVSS alone doesn't reliably predict what attackers are actually using.
Treat business logic and auth flaws as a separate risk category entirely, not something you wait for a CVSS score to justify. If a workflow lets a user manipulate a request to act outside their intended permissions, that's a serious problem regardless of what number a scanner assigns it, because in most real breaches, that's exactly the door attackers walked through.
The Tooling Problem Underneath the Scoring Problem
Part of why CVSS gets over-trusted is that most vulnerability scanning tools still operate the way scanners did a decade ago: they crawl known signatures, check for outdated libraries, and flag things against a CVE database. That approach is useful, but it produces exactly the kind of context-free severity number this whole piece has been describing — a score with no understanding of whether the flaw is actually reachable, chainable, or exploitable in your specific application.
The vulnerabilities that consistently cause real damage authentication bypasses, IDOR chains, business logic abuse, token and OTP weaknesses are precisely the ones that require a scanner to actually behave like an attacker: signing up for real accounts, walking through multi-step flows, testing what happens when a request is replayed or a parameter is altered, rather than just pattern-matching against a signature database. That's a fundamentally different kind of testing than checking a version string against a CVE feed, and it's the gap where a static severity score becomes most dangerous, because it's the gap where the score is least likely to reflect reality.
This is the exact terrain Axeploit was built for. Instead of stopping at "this endpoint responded like it might be vulnerable," Axeploit's AI agents actually behave like a real user and a real attacker at once: signing up with real contact details, walking through OTP and email verification flows, discovering APIs organically the way a person would, and testing whether authorization actually holds when identifiers are manipulated or requests are replayed. The output isn't a generic severity number pulled from a lookup table it's a report that shows exactly how a flaw was reached and what it would take to reach it again, which is the context CVSS alone can never give you.
Closing the Loop
CVSS isn't broken because it's a bad idea. It's broken because it's being asked to do a job telling you what to fix first, in your specific environment, today that it was never designed to do, and because the people feeding numbers into it don't always share your incentives. Vendors under-score to protect reputation. Researchers over-score to protect payouts. Scanners inflate to protect renewal rates. None of that makes the framework useless, but all of it makes blind trust in a single number a genuinely risky habit.
The fix isn't to abandon CVSS. It's to read it the way you'd read any other secondhand claim: understand what assumptions produced it, check those assumptions against your own reality, and go looking for the vulnerabilities the auth flaws, the business logic gaps, the chained IDORs that a static score was never built to see in the first place.
