Low Severity Doesn’t Mean Low Risk

One thing that can be misleading in penetration testing is looking at every finding as if it exists by itself.

A report might contain several Low or Informational findings and nothing rated Critical or High.

That can sound reassuring.

Sometimes it is.

But attackers don’t work one finding at a time.

They combine weaknesses.

And sometimes several relatively minor issues create a legitimate attack path.

Severity describes the finding, not necessarily the path

When we assign severity, we’re generally evaluating the impact and exploitability of that specific issue.

Maybe usernames can be enumerated.

Maybe an API exposes more metadata than necessary.

Maybe rate limiting is inconsistent.

Maybe a development environment exposes documentation.

Maybe a service reveals its exact software version.

Individually, none of those may justify a High or Critical rating.

The question a pentester asks is what happens when they’re combined.

That’s one of the main differences between vulnerability scanning and penetration testing.

A scanner is trying to identify vulnerability X.

A pentester is asking

“What can I do with this?”

And then

“What does that let me do next?”

A simple example

Suppose a web application has several relatively minor weaknesses.

Usernames can be enumerated through the password-reset flow.

API responses expose internal account identifiers.

Authentication endpoints have inconsistent rate limiting.

A staging environment exposes API documentation.

None of those necessarily compromises the application.

But together they give an attacker valid usernames, identifiers, additional opportunities for automated testing, and information about endpoints that may not otherwise be obvious.

Now another authorization or account-recovery weakness that was difficult to exploit may suddenly become practical.

The value of the first weakness was that it helped expose the next one.

That’s the attack path.

Internal networks work the same way

We see this constantly during internal assessments.

A standard domain user can read a shared folder they don’t really need.

The folder contains an old deployment script.

The script references a service account.

That service account has local administrator rights on several servers.

One of those systems has a privileged user session.

None of those observations individually says “Domain Admin.”

Together, they may provide a path to it.

The original finding may have looked like excessive read permissions on a file share.

In reality, it was the first step in a privilege escalation chain.

Context matters

This is why vulnerability severity shouldn’t be treated as the entire risk story.

An information disclosure issue exposing employee email addresses may have very limited impact.

The same type of issue exposing privileged administrative usernames can be considerably more useful to an attacker.

An internal hostname may mean very little to an external attacker.

Once that attacker gains internal access, the same information may suddenly help them navigate the environment.

The vulnerability didn’t change.

The attacker’s position did.

That doesn’t make every Low secretly Critical

There’s an important balance here.

We shouldn’t inflate severity simply because a vulnerability could theoretically be chained with something else.

Security teams already have enough noise.

Some Low findings really are Low.

Some Informational findings are simply observations.

The important distinction is whether the attack path can actually be demonstrated.

If several Low findings create a validated path to sensitive data or privileged access, the report should explain that relationship.

If they don’t, we shouldn’t pretend they do.

That’s one of the places where manual testing provides value beyond vulnerability scanning.

Don’t remediate by severity alone

Sorting findings by severity is a reasonable place to start.

It just shouldn’t be the only consideration.

When I review an assessment, I also want to know

• Which findings make another weakness easier to exploit?

• Which systems or identities connect otherwise unrelated findings?

• Can fixing one weakness break an entire attack path?

• Are several findings symptoms of the same underlying control problem?

Sometimes the most valuable fix isn’t the vulnerability with the highest CVSS score.

It’s the control that breaks the most attack paths.

Attackers don’t care whether something was labeled Informational, Low, Medium, or High.

They care whether it gets them closer to what they want.

So when reviewing a pentest, don’t only ask

“What are our highest-severity findings?”

Also ask

“Which of these findings can be connected together, and where does that path lead?”

That’s often where the more interesting risk is hiding.