Home / Knowledge hub / Exploited finding
Knowledge hub
Exploited finding
A finding confirmed by actually using it, not one that only looks likely.
What it means
An exploited finding is a weakness that a tester has actually used against the running application, in a way that shows the harm. It is different from a suspected finding, where a tool or a person says that something looks vulnerable but has not shown it. The test is simple: did it work?
Exploiting does not mean causing damage. A careful tester takes the smallest step that proves the point, such as reading one test record belonging to another account, then stops. The result is evidence that the flaw is real and that the impact is what the report says.
Why it matters
Suspected issues are cheap to produce and costly to check. A long list of maybes sends developers on searches that end nowhere, and teaches them to doubt the next report. An exploited finding removes that doubt. Nobody needs to argue about whether it is real, only about when it will be fixed.
It also sharpens priority. The difference between a flaw that could be used and one that was used is the difference between a hypothesis and a fact. That changes how you weigh exploitability and how quickly leadership acts on the result. It also helps when a customer asks how sure you are.
How it shows up
In a report, look for what was done: the request sent, the response received, a screenshot and the data reached. Compare that to a finding that says only that a version is outdated or a header is missing. Both may be true, but only one has been shown.
Be careful of two things. First, proof must be safe, so exploitation should follow the agreed scope and use test data where possible. Second, no proof does not mean no flaw. Mark unproven items clearly as suspected, with their confidence level, rather than hiding or inflating them. See evidence of exploitation.
Questions people ask
Exploited finding, answered
Does exploited mean the tester caused damage?
No. A careful tester proves the flaw with the smallest safe action and stops, within the agreed scope. Reading one test record is enough.
Rules of engagement set what is allowed.
What is the difference between exploited and suspected?
Exploited means the flaw was used and the result observed. Suspected means a tool or analyst thinks it is present but has not shown it.
Suspected items should carry a lower confidence.
Why are exploited findings less likely to be false positives?
Because the flaw has been seen working, not inferred from a pattern or version number. That removes most guesswork.
They can still be rated wrongly, so severity still needs checking.
Can every flaw be exploited safely in production?
Not always. Some, such as denial of service, risk breaking things, so they are tested only with care or in a staging copy.
Agree what is out of bounds before testing starts.
Should unproven issues be left out of reports?
They can be included if clearly labelled as unconfirmed, with a confidence level. Passing them off as confirmed is the problem.
Some teams keep them in a separate list. What matters is that readers can tell the proven from the suspected at a glance.
Sources
Where this comes from
Related
Terms that sit next to this one
Security finding
One confirmed weakness in a report, with the evidence to show it is real.
Proof of exploit
Evidence that a flaw can be used to cause real impact, not just that it exists.
Proof of concept
The smallest demonstration that a vulnerability is genuinely real.
False positive
A reported issue that turns out not to be real.
Severity vs confidence
How bad a finding is, kept apart from how sure the tester is that it is real.
Did anyone actually break it?
This is how we work: if we did not break it, we do not report it. Each finding shows the request, the response and the line of code. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.