Vulnerability Prioritization Is Broken: Your Mediums Are Chaining Into Criticals

A few years back I was testing a web app and found three bugs in an afternoon: an SSRF that could only hit internal IPs, an information disclosure that leaked internal hostnames, and an overly permissive cloud role attached to the app server.

On paper they were a medium, a low, and an informational. Chained together, I had credentials for their cloud environment. The final report contained one critical finding built from three bugs that no scanner would have found.

That experience is why I've become increasingly skeptical of how most teams do vulnerability prioritization. The standard playbook is to sort the queue by severity score and start from the top, which feels rigorous and holds up nicely in an audit but it also buries the exact class of risk that gets companies breached, because severity scores rate findings one at a time while attackers exploit them as chains.

Last year I would have told you this was a tolerable flaw in an otherwise reasonable system. Chaining took skill and time, but now it doesn't. AI can do it.

CVSS Is Doing Its Job (Describing Vulnerabilities)

Before I really stick the boot in, I want to be fair to CVSS, because the usual "CVSS is dead" takes are a bit lazy in my opinion. CVSS does what it was designed to do: describe the technical characteristics of a vulnerability in a consistent, comparable way. Attack vector, complexity, privileges required, impact. As a shared language between researchers, vendors, and security teams, it works.

The problem is that we've started relying on it too heavily to guide our decisions. We've moved from using CVSS to describe a vulnerability, to using it to decide what to fix first. A CVSS base score is calculated in a vacuum. It knows nothing about your environment, your compensating controls, what data sits behind the vulnerable system, or what other findings exist in your queue.

FIRST, the organization that maintains CVSS, says as much in the v4.0 specification: consumers "should enrich the Base metrics with Threat and Environmental metric values" to produce a meaningful input to risk assessment. Almost nobody does the enrichment. Teams take the base score, sort descending, and call it vulnerability prioritization.

To their credit, the industry has built better signals on top:

• CVSS environmental scores adjust severity for your actual deployment context: exposure, compensating controls, and what the affected asset means to your business.
• EPSS estimates the probability that a vulnerability will be exploited in the wild in the next 30 days, based on real-world exploitation data.
• CISA's KEV catalog tells you which vulnerabilities already do have confirmed exploitation in the wild, which is about as strong a "fix this" signal as you can get.

If you're combining all three, you're ahead of most programs, and I wrote about how these fit into a triage workflow in a previous piece with HackerOne. It's actually quite a robust system. But notice what all three signals have in common: each one scores the finding in isolation. CVSS describes one vulnerability. EPSS predicts exploitation of one CVE. KEV lists individual entries. Nothing in the stack has any concept of what happens when finding #4, finding #17, and finding #31 exist on the same network at the same time.

Ask anyone who does offensive work for a living and they'll tell you real compromises are usually a sequence of unremarkable bugs rather than a single critical one. Chaining is the whole game.

AI Has Made Chaining Cheap, and Easy

Chaining used to be expensive. It took a human with intuition, context, and time, which meant attackers reserved the effort for targets worth it. That scarcity is what made severity-sorted queues survivable.

Now an agent can map an environment, catalogue its small weaknesses, and test combinations at a speed and cost no human team can match. The tedious part of offensive work, holding a mental map of hundreds of small weaknesses and probing how they compose, is exactly the kind of thing that AI excels at. I use these tools in my own testing. The chains they surface from piles of "low value" findings are still surprising to me.

The data backs up how fast this is moving. HackerOne's 2025 Hacker-Powered Security Report recorded a 540% year-over-year surge in prompt injection reports, a 233% rise in excessive agency findings, and a 212% increase in insecure plugin design.

Image

Those three classes are worth pausing on. On its own, a prompt injection in an internal chatbot is a medium at best. Excessive agency, an AI integration with more permissions than it needs, often gets triaged as a hardening recommendation. Insecure plugin design might not even make the report.

Now chain them: inject a prompt into the model, abuse the over-permissioned integration the model has access to, and pivot through the badly isolated plugin into systems that were never supposed to be reachable from a chat window. Three findings your severity-sorted queue put near the bottom are suddenly the worst incident of the year. Traditional scoring would never flag any of them as critical, because traditional scoring can't see the chain.

Image

I don't think this has landed with most program leaders yet. The 540% number is alarming on its own, but the bigger story is that these are composable vulnerability classes being deployed into environments where AI agents, defensive and offensive, are learning to compose them.

What Risk-Based Vulnerability Management Actually Requires

If severity-sorted queues are the wrong model, what replaces them? Risk-based vulnerability management answers that question differently. Prioritization is a question about your environment: what's exposed, what connects to what, and what an attacker could do from here. Answering it requires validation as well as measurement, and any risk-based vulnerability management program worth the name needs three capabilities that static scores can't provide.

Continuous, contextual scoring

Findings should be scored against signals that reflect real-world exploitability: asset exposure, vulnerability class, historical exploitation patterns, and business context. This is CVSS environmental thinking plus EPSS plus KEV, applied automatically and re-applied as your environment changes, rather than a base score assigned once and never revisited. A finding's priority depends on the environment it sits in, and your environment changes weekly.

Proof of exploitability

A score, however contextual, is still a prediction. The strongest prioritization signal available is a demonstration that a finding is actually exploitable in your environment, tested against your real controls and configurations. When you can hand your remediation team documented proof of exploitation instead of a number, the argument about what to fix first tends to end quickly. Findings that can't be exploited in your environment drop down the queue where they belong, which matters just as much, because every hour spent patching a theoretical is an hour not spent on a real exposure.

Chain-aware analysis

Confirmed findings need to be analysed for how they connect: root cause, attack paths, and chainability with everything else in the queue. This is the piece the CVSS/EPSS/KEV stack can't give you at any price, and it's the one that would have caught my SSRF-to-cloud-credentials chain. A medium that chains with two others into a critical path should surface at the top of the queue instead of being buried at position 200 by its base score.

Scoring and validating at this scale and cadence is machine work now, but deciding what your crown jewels are, which business risks you'll accept, and whether a confirmed chain justifies notifications on a weekend requires a human who understands the organisation. The teams getting this right use automation to shrink the queue to what's proven and let their experienced people spend their judgment there, instead of burning it on triaging useless bugs.

Sort by Risk (Or Someone Else Will)

Severity scores aren't going away, and they shouldn't. But the era where a base score could stand in for a prioritization decision is over, because the assumption that made it survivable, that chaining low-severity findings is expensive, no longer holds. Attackers get the benefit of AI-driven chaining whether you plan for it or not.

Moving to risk-based vulnerability management means accepting that your queue should be ordered by validated, contextual, chain-aware exploitability rather than by a number assigned in isolation. Teams that make that shift will fix fewer vulnerabilities and stop more breaches, while the ones that don't keep dutifully patching criticals as three mediums quietly compose into the incident report.

If you want to see what continuous, validated triage looks like in practice, take a look at how HackerOne approaches triage.

Your mediums are chaining. Here's how continuous validation keeps up.