What is the difference between medium-severity and critical-severity vulnerabilities in a bug bounty context?

Medium-severity vulnerabilities usually need more conditions, more steps, or stronger assumptions before exploitation succeeds. Critical issues typically allow direct compromise, broad data exposure, or high-impact system abuse with fewer barriers. In practice, severity should reflect realistic impact and ease of exploitation, not just the label assigned during triage.

Why the severity labels mean different things

In bug bounty program, CVSS is usually the common language for severity, but the label itself is only a shorthand for impact and exploitability. A medium finding often matters because it is real and fixable, yet it still depends on extra conditions. A critical finding usually crosses a threshold where the attacker needs less setup and the likely blast radius is much larger.

The practical difference is not just technical difficulty. Medium issues often sit behind user interaction, special privileges, weak assumptions, or a narrow target path. Critical issues tend to expose a direct route to sensitive data, broad privilege abuse, remote compromise, or large-scale service impact. That is why triage should be tied to realistic exploitation, not the headline score alone.

For a published severity baseline, practitioners often compare internal triage to a canonical record such as the NIST National Vulnerability Database, then adjust for the exact environment and exposure. In a bug bounty setting, the same flaw can move up or down depending on whether it is reachable, authenticated, chained, or protected by compensating controls.

What usually separates medium from critical in practice

Medium-severity vulnerabilities generally have at least one limiting factor: the attacker may need a valid account, a narrow timing window, a second bug, a specific configuration, or a user action. The impact can still be meaningful, but it is often localised, partial, or conditional. In bounty programs, these findings are often important because they show weakness, but not every weakness creates immediate systemic risk.

Critical-severity vulnerabilities usually remove one or more of those barriers. They often enable direct compromise, unauthorised access to sensitive data, privilege escalation into an administrative path, or a reliable attack path against many users or tenants. The more the issue can be weaponised without unusual assumptions, the more likely it belongs at the top end of severity.

For teams that want a consistent yardstick, the current CISA Known Exploited Vulnerabilities Catalog is useful context, because active exploitation often signals that an issue is more than a theoretical finding. A vulnerability can still be medium in a specific program if the exploit path is constrained, but active exploitation should trigger a hard recheck of the assumptions behind the initial score.

How bug bounty teams should judge severity fairly

Bug bounty severity should be based on the strongest credible attack path, not the most optimistic interpretation for either side. The right question is: if an attacker has the bug, what can they realistically do next, and how many extra conditions are needed before that becomes harmful? That means scoring should account for reachability, required privileges, chaining potential, and the sensitivity of the affected asset.

When the report is about access control, authentication, or credential exposure, the distinction becomes sharper. A flaw that only leaks low-value information or requires significant follow-on steps may stay medium. A flaw that exposes secrets, grants broad access, or enables takeover of a high-value account can justify critical severity because the downstream effect is immediate and difficult to contain.

For reporters and program owners alike, the most defensible approach is to describe impact in concrete terms and avoid relying on the label alone. A clear write-up should show what the attacker gains, what they still need, and whether the issue affects one user, one system, or the whole environment. That is what makes severity review repeatable instead of subjective.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V8 — Authorization	Bug bounty severity often turns on whether a flaw enables unauthorized access or privilege abuse.
Recommendation — Check whether the reported issue changes authorization boundaries or exposes protected actions.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Severity drives remediation priority and exploitability assessment for discovered vulnerabilities.
	RA-5 — Vulnerability Monitoring and Scanning	Bug bounty findings are vulnerability assessment inputs that need repeatable triage and tracking.
Recommendation — Prioritise remediation based on exploitability, impact, and affected assets. Track discovered flaws through a defined vulnerability monitoring and triage process.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Medium versus critical is fundamentally a prioritisation problem in vulnerability management.
Recommendation — Rank findings by realistic impact and exploitability, then remediate the highest-risk issues first.
OWASP API Security Top 10	API5 Broken Function Level Authorization	Critical bounty findings often involve authorization failures that unlock powerful actions.
Recommendation — Verify that sensitive functions are inaccessible to unauthorized users or roles.

Practitioner Guidance

Decision rule: If the report can only become dangerous after extra prerequisites are met, treat it as medium until the evidence shows otherwise. If the issue can plausibly lead to direct compromise, broad data exposure, or reliable privilege abuse with little resistance, reassess it as critical.

What to verify: Confirm the real attack path, not just the theoretical one. Check whether the exploit needs authentication, user interaction, chaining, special timing, or a rare configuration, and then test whether those constraints are actually present in production.

Practitioner takeaway: Severity in bug bounty is an exposure judgement, not a status label, and the most important test is whether the vulnerability changes the attacker’s ability to reach meaningful impact with minimal friction.