Home / Knowledge hub / Exploit
Knowledge hub
Exploit
The specific sequence that turns a suspected weakness into a real one.
What it means
An exploit is the specific sequence that turns a suspected weakness into a demonstrated one. The request that actually got the data out, in the order that made it work.
A vulnerability stays a theory until somebody has one. This endpoint may not check ownership is a suspicion. This request, sent as user A, returned user B's invoice, and here is the response, is a fact.
Why it matters
That difference decides how your week goes. A theory needs an engineer to investigate before anyone knows whether it is real, and most turn out not to be. A proven finding goes straight into the queue with its evidence attached, and nobody argues about whether it counts.
One limit deserves stating plainly. Some real risks cannot be proven safely on a live system, including anything that would destroy data or take the service down. An honest report says so rather than quietly dropping them or dressing a theory up as a finding. Knowing which category each item falls into tells you how much of a report you can act on this week.
How it shows up
In a report it looks like the exact request, the response that came back, a screenshot where the result is visual, and the line of code responsible. Enough for somebody who was not there to reproduce it in a few minutes.
What it should never look like: a description of a risk with no request, or a payload that was sent but whose result nobody confirmed. We report only what we exploited. What a finding contains.
Questions people ask
Exploit, answered
What is the difference between a vulnerability and an exploit?
The vulnerability is the weakness. The exploit is the working method that takes advantage of it.
A flaw can sit in your code for years without an exploit existing. Once one exists, the gap between knowing about the flaw and being harmed by it gets very short.
What is a proof of concept exploit?
It is the smallest thing that demonstrates the flaw is real, without weaponising it. Returning one record belonging to another account proves the check is missing.
A full exploit does the most it can. A proof of concept does the least it can while still being convincing, which is what belongs in a report.
A public exploit exists for something we run. Does that mean we will be attacked?
It raises the odds sharply, because it removes the skill barrier. Automated scanning follows public exploit code within days.
Whether it reaches you still depends on your version, your configuration and whether the path is exposed. Check those three before panicking or relaxing.
Will exploiting our application break production?
It should not, and the scope agreement is where you settle it. We stay away from anything destructive and anything that affects availability.
The tests that prove access control read a record you own with an account that should not have it. That leaves no mess behind.
Can we see the exploit, or just a description of the risk?
You get the request, the response, a screenshot where it helps, and the source line. Your engineer can replay it.
If a report only offers a description and a severity, ask what was actually sent. The answer tells you how much verification work is coming.
Sources
Where this comes from
Related
Terms that sit next to this one
Proof of concept
The smallest demonstration that a vulnerability is genuinely real.
Vulnerability
A weakness that somebody could use to cause harm.
False positive
A reported issue that turns out not to be real.
Remote code execution
Getting a server to run commands of an attacker's choosing.
Penetration test
A time-boxed engagement where skilled people attack your systems by hand.
Proof, or just a maybe?
We report what we exploited, with the request, the response, a screenshot and the source line. Nothing your engineer has to verify first. Ask for a pilot on one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.