We all do it. A vulnerability scanner flags something with a CVSS score of 3.2. "Low severity," it says. We put it at the bottom of the backlog and forget about it.
Until that "low severity" issue becomes part of an attack chain that costs you millions.
The Low Severity Trap
Security teams are drowning in vulnerabilities. When you're triaging hundreds or thousands of findings, you need to prioritize. CVSS scores seem like an objective way to do that.
High and Critical? Fix immediately. Medium? Schedule for next quarter. Low? Maybe someday.
The problem? Attackers don't care about your CVSS scores.
Real-World Examples
Case 1: The Information Disclosure Chain
A financial services company ignored a "low severity" information disclosure bug. The vulnerability leaked software version numbers in HTTP headers.
"Who cares about version numbers?" they thought.
Attackers cared. They used those version numbers to:
- Identify other vulnerabilities present in that specific version
- Craft targeted exploits
- Bypass security controls calibrated for different versions
That information disclosure was step one in a chain that led to a $10M breach.
Case 2: The Race Condition Nobody Worried About
A tech company had a race condition bug flagged as "low severity" because:
- It required precise timing to exploit
- The impact was limited to a single user session
- Exploitation was considered "difficult"
Then a researcher demonstrated an automated exploit that could trigger it reliably. Combined with another vulnerability, it led to privilege escalation.
CVSS doesn't account for automation. "Difficult" for humans might be trivial for scripts.
Case 3: The Path Traversal "Feature"
An e-commerce platform had a path traversal issue in a legacy API endpoint. Low severity because:
- The API was "internal only"
- It required authentication
- No sensitive files were in the traversable path
Except:
- "Internal only" APIs are often internet-accessible if you know where to look
- Authentication was bypassed using another low-severity bug
- The "non-sensitive" path included configuration files with cloud credentials
Two low-severity bugs plus a misconfiguration equals full cloud account compromise.
Why Low Severity Doesn't Mean Low Risk
CVSS measures theoretical impact in isolation. It doesn't consider:
1. Attack Chains Individual low-severity issues can chain together for high impact.
2. Context A low-severity bug in a DMZ system is different from the same bug in a payment processor.
3. Compensating Controls CVSS assumes certain security controls exist. If they don't, severity changes.
4. Exploit Availability Public exploit code makes "difficult" bugs trivial to exploit.
5. Attacker Motivation Your threat model matters more than generic severity scores.
What Makes a "Low Severity" Bug Dangerous
Watch out for these characteristics:
Information Disclosure
Seems harmless, but attackers use reconnaissance. Version numbers, internal paths, user enumeration - all useful for targeted attacks.
Verbose Error Messages
Stack traces and detailed error messages leak information about architecture, frameworks, and potential weaknesses.
Minor Authorization Flaws
"Users can see other users' profile pictures." Sounds trivial. But if you can enumerate users, test for account existence, or map organizational structure, that's valuable intel.
Denial of Service
"It just crashes one worker process." Until an attacker crashes all of them simultaneously, taking down your service.
Low-Privileged User Issues
"Requires a valid user account." Cool, but authenticated users can be attackers too. Think malicious insiders, compromised accounts, or social engineering.
The Economics of Low Severity Bugs
From a pure cost-benefit perspective, should you fix low-severity vulnerabilities?
Cost of Fixing:
- Developer time
- Testing effort
- Deployment overhead
- Risk of introducing new bugs
Cost of Not Fixing:
- Potential breach impact
- Regulatory fines
- Reputation damage
- Customer churn
- Incident response
For most low-severity bugs, the fix cost is minimal. A few lines of code, maybe an hour of testing. But the potential downside - if that bug is part of an attack - is massive.
The math usually favors fixing them.
A Better Approach to Prioritization
Instead of relying solely on CVSS:
1. Apply Context
- Is the vulnerable component internet-facing?
- Does it process sensitive data?
- What other security controls exist?
- What's your threat model?
2. Consider Exploit Availability
- Is exploit code public?
- Are attacks observed in the wild?
- How difficult is exploitation really?
3. Look for Chains
- Could this bug combine with others?
- Does it bypass a security control?
- Does it make other vulnerabilities more severe?
4. Factor in Business Impact
- What system is affected?
- What's the worst-case scenario?
- How quickly could you detect and respond?
5. Check Remediation Effort
- Is this an easy fix?
- Can you mitigate without patching?
- What's the risk of the fix itself?
Practical Strategies
You can't fix everything. Here's how to be smarter about low-severity issues:
Quick Wins First Some low-severity bugs have trivial fixes. Knock those out fast.
Bulk Remediation Group similar low-severity issues and fix them together. Updating a library might resolve 20 vulnerabilities at once.
Defense in Depth Even if you don't fix the vulnerability, can you make it harder to exploit? Add monitoring, implement rate limiting, enhance authentication.
Security Patches Over Feature Releases When you're already deploying changes, include low-severity fixes. The marginal cost is near zero.
Automated Fixes Tools like Dependabot can automatically address many low-severity dependency vulnerabilities.
When to Explicitly Accept Risk
Sometimes, not fixing a low-severity bug is the right call:
- The fix would break critical functionality
- The vulnerable component is being retired soon
- Effective compensating controls exist
- The vulnerability is theoretical with no realistic attack path
Just make sure you're explicitly accepting the risk after analysis, not ignoring it by default.
Measuring What Matters
Track metrics beyond just CVSS scores:
- Time to remediate by criticality AND exploitability
- Percentage of vulnerabilities with public exploits
- Mean time to detect exploitation attempts
- Vulnerability density in critical vs non-critical systems
- Coverage of security controls
The Cultural Shift
The best organizations don't just prioritize by severity. They build a culture where:
- Security is part of the development process, not an afterthought
- "Low severity" doesn't mean "ignore"
- Context matters more than scores
- Defense in depth is the default
- Continuous improvement beats periodic fire drills
Bottom Line
Low-severity vulnerabilities aren't going to cause a breach on their own. But they're often the first step in an attack chain that does.
Stop treating CVSS scores as the final word on risk. Apply context, consider attack chains, and remember: attackers are creative. They'll use whatever works.
That 3.2 CVSS bug you're ignoring? It might be exactly what an attacker needs.