TLDR: Your scanner flagged three findings — verbose error messages (low), no rate limiting on password reset (medium), weak token strength (medium). No criticals. You deprioritised the report. Six weeks later, an attacker chained those three findings into a complete account takeover of your most privileged user. Vulnerability chaining is how real attacks work. Individual severity ratings are misleading because CVSS scores vulnerabilities in isolation. Attackers never attack in isolation.
"No Critical Findings"
Those three words are responsible for more breaches than any zero-day exploit.
Not because the organisation didn't care — they did. Not because the scanner was broken — it wasn't. But because the report rated three separate findings as low and medium severity, the security team made a rational prioritisation decision: fix the criticals first, queue the rest for next sprint.
The problem is that an attacker had already read the same three findings — by probing the application themselves — and saw something the scanner couldn't: a path. Three steps, each individually unremarkable, that together produced a complete account takeover in under 20 minutes.
This is vulnerability chaining. And understanding it changes how you read every security report you'll ever receive.
The Account Takeover — Step by Step
Let's walk through the exact scenario from the opening hook, because the mechanics matter.
Finding 1 — Verbose error messages (Low severity). The password reset flow returns different error messages depending on whether an email address exists in the system. "User not found" versus "Reset email sent". A scanner flags this as low severity information disclosure. The developer made a UX decision — helpful error messages. The security implication barely registers.
What this gives an attacker: a way to enumerate which email addresses have accounts. They now know that ceo@company.com is a valid account in the system.
Finding 2 — No rate limiting on password reset (Medium severity). The password reset endpoint accepts unlimited requests. The scanner flags this as medium — a denial-of-service risk if abused, potentially annoying. No critical risk in isolation.
What this gives an attacker: the ability to request password resets for any account as many times as they want, as fast as they want.
Finding 3 — Weak reset token entropy (Medium severity). The password reset tokens are six characters long, alphanumeric, generated with a weak random function. The scanner flags it as medium — weak cryptography, should be strengthened.
What this gives an attacker: reset tokens with a search space small enough to brute-force.
Now chain them.
The attacker identifies ceo@company.com via the verbose error message. They hammer the password reset endpoint — no rate limiting — triggering hundreds of reset emails per minute. For each reset request, they simultaneously brute-force the token space against the reset endpoint. Because tokens are short and weakly random, they find a valid token within minutes. They use it. They set a new password. They're in — as the CEO.
Three medium and low findings. One complete, privileged account takeover. The scanner gave each finding a severity score between 3 and 5 out of 10. The attack path they formed together was a 10.
Why Automated Tools Cannot See Chains
The reason is architectural. Automated scanners test endpoints. They test inputs. They test responses. They evaluate each finding against a scoring rubric — CVSS (Common Vulnerability Scoring System) — that was designed to rate the severity of individual vulnerabilities.
CVSS has no mechanism for "this vulnerability, when combined with that vulnerability, enables this attack path." It was never designed for that. It rates issues in isolation because isolation is the only mode a signature-based scanner can operate in.
A human tester, on the other hand, builds a mental model of the application. They see the verbose error message and immediately ask: what else is there in this authentication flow that might make this useful? They find the rate limiting gap. They find the weak token. And the chain assembles itself — not through any sophisticated technique, but through the attacker's fundamental question: what can I do with what I have?
This is the gap we described in why automated scanners miss most real vulnerabilities. Chaining is the sharpest illustration of it.
Three More Chains Worth Understanding
Open Redirect + Reflected XSS → Phishing with legitimate domain trust.
A scanner finds an open redirect (low) — a URL parameter that redirects users to an arbitrary external site. It also finds a reflected XSS (medium) on the same domain. XSS is still widespread and dangerous. Together: send a victim a link on the legitimate domain that redirects to a page injecting script into their session. The trust of the real domain bypasses their suspicion. The XSS steals their session token.
SSRF + Cloud Metadata Endpoint → Cloud Credential Theft.
A Server-Side Request Forgery vulnerability (medium) allows the application to make requests to internal addresses. On its own, limited impact. But most cloud environments expose a metadata endpoint at a well-known internal IP that returns IAM credentials for the instance. SSRF to that endpoint retrieves credentials with whatever permissions the instance carries. From a medium-severity SSRF to complete cloud environment access — one hop.
IDOR + Information Disclosure → Targeted Account Takeover.
An IDOR vulnerability leaks user profile data including email addresses and partial phone numbers. An information disclosure in an error message confirms which users have admin privileges. Combined: identify admin email addresses, then use them as targets for a precisely crafted spear phishing campaign. The IDOR and the information disclosure each score as medium. Their combination enables a targeted attack on your highest-privilege accounts.
The Severity Miscalculation Problem
CVSS scores are not wrong. They're just answering a different question than you think they are.
A CVSS score answers: how severe is this individual vulnerability, assuming optimal conditions for an attacker exploiting it in isolation?
What you actually need to know is: what can an attacker accomplish in my specific environment, using any combination of the weaknesses that exist here?
Those are different questions with different answers. A pen test report that lists findings by individual CVSS score without documenting attack paths is giving you the right answer to the wrong question. It tells you which vulnerabilities are serious in the abstract. It doesn't tell you how you'd actually get breached.
A good pen test report — the kind worth acting on — documents attack chains explicitly. It shows the path: finding A enables finding B, finding B in combination with finding C produces this outcome. It presents risk in the context of your application, not in the abstract of a scoring rubric.
This is one of the most significant differences between a tool-generated report and a report written by a tester who has spent hours thinking adversarially about your specific system. The broken authentication patterns that enable many chains are exactly the kind of thing a skilled tester looks to combine.
What This Means for How You Read Security Reports
Next time you receive a vulnerability report — whether from an automated scanner, a bug bounty submission, or a pen test — read it differently.
Don't just look at the severity column. Look at which findings touch the same surface. Which findings involve the same user flow. Which low-severity information disclosures might make a medium-severity issue exploitable. Ask the person who wrote the report: are there any combinations here that concern you?
If they've thought about it, they'll have an answer. If the report was auto-generated, there won't be one.
How Kuboid Secure Layer Thinks About This
Every web application assessment we deliver at Kuboid Secure Layer explicitly documents attack paths — not just individual findings. If we find three medium-severity issues that chain into a critical outcome, the report reflects that. The executive summary reflects the actual risk, not the average CVSS score.
Because the board doesn't need to know that you have a 4.3 and two 5.1s. They need to know that an attacker can take over your CEO's account in 20 minutes — and here's exactly how.
Book a free consultation and we'll walk you through what attack-path-aware testing looks like for your application.
Have you ever received a "no criticals" report and later found something serious hiding in the medium findings? Or spotted a chain that a scanner completely missed? Drop a comment — this pattern is far more common than the industry admits.
Top comments (0)