The practice of treating low severity CVEs as noise should be coming to an end. For most of my career the pattern was mostly the same. Critical, high, and medium CVEs got the lion share of the attention, and low severity CVEs went to the trash bin. With limited headcount, limited hours, and an enormous backlog of CVEs, it's a no-brainer that time and resources get spent where the score says the danger is.
I no longer believe in that practice, and the reason is simple. The scoring system we built our entire prioritization strategy around was designed to measure vulnerabilities one at a time, even though bad actors never attack us one vulnerability at a time. We have always lived with that gap. What's changed now is that AI models are closing the distance between what an attacker could theoretically do and what an attacker can actually do at scale, in a short period, with or without a skilled team behind them.
CVSS already admitted this
Here's the part most people forget. CVSS itself tells you it was built to score vulnerabilities one at a time. The guidance even says that if you want to score a chain, an analyst has to do it by hand, taking the easiest exploitability metrics from one bug and the worst impact metrics from another. So the people who wrote the standard knew about attack chaining. They just left that work to us. The problem is almost nobody does it, because there's not enough time.
Even though studies show that fewer than twenty percent of the CVEs that we rate critical or high ever get exploited in the real world, those ratings land on more than half of everything published. Basically, we've been spending our time on a pile that's mostly theoretical, while the combinations that actually hurt us sit quietly in the pile we told ourselves was safe.
A low score tells you about isolation, not danger
Here's the part I would like security professionals to understand: a low CVSS score does not mean a vulnerability is harmless. It means that on its own, by itself, it does not do much. That "by itself" is doing a lot of work, and we have been ignoring it for years.
Take an info disclosure bug that leaks a memory address. On its own it will rightly be considered a low severity CVE. But pair it with a separate medium severity memory bug and the leak just turned the medium into something far closer to critical.
Chains do not add up, they multiply. Each link knocks out a defense and changes what the next link can reach.
Most of the breaches that actually hurt companies over the last couple of years were not one big flaw. They were a few findings that nobody scored a medium or above, but unfortunately got paired up in the right order.
What grouping actually looks like
The following are some groupings that should change how you score a finding once you stop looking at it alone.
Recon
A verbose error message that leaks stack traces is a classic low. An endpoint that exposes internal service names is another. Put them together and an attacker now has a map of your internal setup, which is the setup work for almost any targeted attack that follows. Even though individually each vuln is a low, together they become a medium because as a pair they're handing an attacker something neither one does alone.
Sessions
A missing security header is a low. A cookie without the right flags is a low. A weak session timeout is a low. But on an internet facing app, those three together can add up to a real session hijack, and now you are looking at account takeover.
Privilege
An information leak that exposes a user ID is a low. A missing access control check on some secondary endpoint is at most a medium. Together you have movement between accounts, and depending on what that second account can reach, you're now looking at privilege escalation. The method is simply to score where the chain ends up, not the doors or paths along the way.
Memory exploitation
A memory disclosure primitive, a sandbox weakness, and a separate corruption bug all get logged as separate findings at different severities. Individually they won't be considered show-stoppers. But together, they're a full exploit that escapes the sandbox. Not long ago we learned Mythos put together exactly that kind of four bug chain overnight.
A method that does not bury your team
I would be wasting your time if my answer was "have your analysts manually map every combination of every low CVE in a backlog of thousands." Manual chaining does not scale, so it's useless going there. Here is a strategy that scales that I would put in front of a team:
First, stop scoring lows only by severity and start tagging them by function. The question is not how bad is this vulnerability, it is what does this vulnerability give an attacker. A short list of tags such as: info disclosure, access control weakness, session or auth weakness, memory or execution primitive, config exposure, etc should cover most of it. This can be mostly automated from data you already have, and then let everything else build on it.
Second, group by exposure context, not severity. Vulnerabilities on the same public facing asset, or within the same trust boundary are the ones that an attacker can realistically chain. Two low severity vulnerabilities on two separate, unconnected systems do not chain and should not be grouped together. This is where graph thinking helps. Instead of looking at findings as a flat list, you should model your environment as nodes and edges where the nodes are assets, accounts, and findings, and the edges are the relationships and access paths between the nodes. A malicious actor moves along the edges, so a chain is basically a path through the graph from where an attacker lands to where your high value target is located. Most modern tooling that performs asset and exposure mapping builds this type of graph for you, so a lot of the heavy lifting is already done.
Third, this is a job for LLMs. Take a group of low CVEs that share an exposure context and a useful mix of tags. Hand the CVE group over to an AI model with the following task: "tell me if these CVEs chain, and if they do, walk me through it and propose a fix." Yes, the model will be wrong sometimes. It will even invent chains that do not work and suggest fixes that do not fully hold. That's ok. I expect it to hallucinate some of the time. If you're wondering why I'm ok with it, just look at what we're comparing it to. Right now we do nothing with these findings at all. The bar is not perfection. The bar is doing better than ignoring low severity CVEs, which is mostly what we've been doing so far. That's a very low bar.
Fourth, and this one is not optional. You must test the fixes from an LLM before you trust them. The model does the tedious combinatorial work nobody has time for, surfaces the handful of chains worth caring about, and drafts the fixes. Your engineers verify and ship the ones that hold. The human stays in the loop where judgment matters and steps out of the part that was never getting done anyway.
Why now and not five years ago
Chaining is not new, so why did this not matter a decade ago? Because back then the cost and skill to chain a bunch of low severity bugs was high enough that only well funded attackers bothered, and only for targets worth the effort. That cost is falling fast. The same capability that found hundreds of bugs in one browser and built working chains without anyone steering it does not care if you are a Fortune 500 or a forty person startup. When chaining gets cheap for the attacker, the comfort we took from a low score goes with it.
I am not saying treat every low severity like a show-stopper, doing that will just rebuild CVE exhaustion and alert fatigue. I am saying stop treating the low tier CVEs as the place findings go to be forgotten, and start treating it as a supply of ingredients that a skillful attacker is learning to assemble faster than we're learning to block. Tag by function, group by exposure, and let AI assess the chains, then test every fix.
The low severity backlog has sat there for years and we disregarded it and called it noise. I think it is worth asking out loud whether it ever was. Maybe it was just waiting for something, a tool, an LLM model, that could finally put the pieces together.
Written by Sam. Sam is a Computer & Electrical engineer, Security Architect, and the co-founder of RedBlue Cyber LLC.