The report comes back. Zero criticals, zero highs, a few mediums, a pile of lows and informationals. That feels like a pass, and sometimes it is.

The problem is that attackers do not read your report by severity. They look for a path. Three or four small findings, in the right order, can be that path. This post walks through how that happens, with two examples pulled from the kind of environments we test every week, and what to fix first when the chain matters more than the score.

Severity scores the finding, not the path

Every finding in a pentest report gets rated on its own. How much damage can this one issue do, and how hard is it to pull off. That is useful, and it is also the whole limitation.

A login page that tells you whether an email exists is a low. A forgot-password form with no rate limit is a low. An error page that shows the framework version is informational. An old API version still answering requests is a medium at best. None of those gets you breached by itself, so none of them scores high.

A tester asks a different question. Not "how bad is this finding," but "what can I do with it, and what does that let me do next." That is the difference between a scanner and a pentest. A scanner finds issue X. A tester chains X to Y to Z and shows you where it ends.

Example one: four small findings, one customer database

Say your web app has these findings, none of them above medium.

The login page confirms valid emails. A wrong password and an unknown account return different messages.

No rate limiting on login or password reset. An attacker can make thousands of attempts without a lockout.

The mobile app still uses an older API version. Version 1 is still live, and it never got the authorization fix that version 2 did.

Error pages leak the framework and version. Informational. Nobody is fixing that this quarter.

Now chain them. Harvest a list of valid customer emails off the login page. Spray one common password across all of them, with nothing to stop you. At least one account falls to something like Summer2026. Log in, point your requests at the old version 1 API, and pull records that belong to other customers, because version 1 never checked who owned them.

The report said no criticals. The actual outcome is customer data leaving the building. The first finding did no damage on its own. It just made the next one possible.

Example two: a file share to domain admin

Internal networks work the same way, and this pattern comes up on internal tests all the time.

Every domain user can read an old IT share. Excessive permissions, rated low.

The share holds a backup script with a service account password in it. Hardcoded credentials, medium.

That service account is a local admin on a few servers nobody decommissioned. Medium.

One of those servers has a domain admin logged in. Credentials sitting in memory, ready to be dumped.

One phished employee gets the attacker a regular user account. That account reads the share. The share gives up the script. The script gives up the password. The password gives up the servers. One server gives up domain admin. From there it is every system you own, which is exactly how ransomware crews operate.

Sorted by severity, that is one low and two mediums. Sorted by where it leads, it is the worst day your company has had.

Same finding, different position

Context moves the risk even when the finding stays the same. Employee email addresses on a public page is minor. Admin usernames on a public page is a head start. An internal hostname means nothing to someone on the internet and means a lot once they are inside the network trying to figure out where the good stuff is.

The vulnerability did not change. The attacker's position did. Good reports say that out loud instead of leaving you to guess.

This does not make every low a critical

Do not let anyone inflate severity because a finding could theoretically chain into something. Your team already has enough noise. Some lows are lows. Some informationals are just notes.

The test is simple: can the path be demonstrated? If a tester actually walked the chain to sensitive data or admin rights, the report should show it, step by step, with proof. If they could not, they should not pretend. This is where a manual pentest earns its fee, and where a scanner with a logo on the cover lets you down.

Fix the link, not the score

Sorting findings by severity is a fine place to start. It is a bad place to stop. When you review a report, ask four more questions.

Which finding makes another one easier to exploit? Those are the ones quietly worth more than their rating.

Which account, host or share connects findings that look unrelated? That is the pivot point, and usually the cheapest thing to fix.

Which single fix breaks the whole chain? Rate limiting on one endpoint. Pulling the old API version. Locking down one share. Rotating one service account.

Are five findings really one broken control? Four permissions findings are usually one missing permissions review, not four tickets.

The most valuable fix is often not the one with the highest CVSS score. It is the one that kills the most paths.

What to ask your pentester

Whether you are reviewing a report or deciding who to hire, these questions tell you fast if you are getting a real test.

Did you try to chain findings together, or just list them? Show me the attack path from the first finding to the data. Which one fix breaks the most paths? Will you retest after we fix it?

A report that is a severity-sorted list with no narrative is a scan with better formatting. You paid for someone to think like an attacker. Make sure they did.

How we handle this

Our testers run the chain, not just the checklist. When a path exists, the report shows it start to finish and says what to fix first to break it, and we retest within 90 days at no extra cost. That applies to web app pentesting, external network pentesting, and internal network pentesting.

Got a report that looks clean and you are not sure it is? Get a quote and we will scope a test that looks for the path, not just the findings.

See also our guides on vulnerability scanning vs pentesting and internal network pentesting.

Is a pentest report with no critical findings a clean bill of health?

Not on its own. Severity rates each finding by itself. Several low and medium findings can still chain into a path to sensitive data or admin access. Read the report for attack paths, not just the severity counts.

Why do pentesters chain low-severity findings together?

Because that is what attackers do. A finding that is harmless alone can expose the information or access that makes the next finding practical. Chaining is the main thing that separates a manual pentest from a vulnerability scan.

Should we fix low findings before mediums?

Sometimes. If a low finding is the first link in a demonstrated chain, fixing it can break the whole path for less effort than fixing a medium that leads nowhere. Prioritize by what each finding leads to, then by severity.

Can a vulnerability scanner find attack chains?

No. Scanners match systems against known issues one at a time. They do not reason about how findings combine, and they cannot prove a path is real. That takes a human tester.

What should a good pentest report show about attack paths?

The chain step by step, proof at each step, where it ends, and the single fix that breaks it. If a report is only a severity-sorted list, ask the tester whether chaining was attempted.