How do you prove a vulnerability fix worked? Re-run the exploit

You prove a vulnerability fix worked by re-running the original proof of concept against the fixed build and showing it now fails, then keeping that input as a permanent regression test. A scanner turning green is a useful signal, but the failed exploit is the evidence.

Why a green scan is not enough

A scanner reports that a vulnerable version is no longer present. That is good, and it covers the common case of a library bump. It does not tell you that the behavior is fixed in your application. Maybe your code copies the vulnerable logic. Maybe a second copy of the library is bundled somewhere. Maybe the vulnerable path was never the dependency but your own use of it.

A proof of concept, even a crude one, tests the thing you actually care about: can the attacker still do what they did before?

Capture the proof of concept early

Most teams lose the original input. It lives in a chat message, a bug report or a researcher's note, and by the time the fix merges nobody can find it. Save it when the finding arrives.

Keep these four things together:

1. The exact input. A request body, a crafted file, a URL, a sequence of calls.
2. The target and version. Which build, which endpoint, which configuration.
3. The expected bad result. What success looked like for the attacker, such as a 200 response with another user's data or a crash.
4. The expected good result. What a fixed system should do: reject, return 400 or 403, or ignore the input.

Do not store live credentials or real user data in the proof of concept. Use test accounts and placeholder values.

Re-run it the right way

1. Re-run against the old build first. Confirm the exploit still works there. If it does not, you cannot learn anything from it failing on the new build. This step catches stale or broken proofs.
2. Re-run against the fixed build. It should fail in the way you wrote down as the good result.
3. Try two or three variations. Change encoding, case, order of fields, or the HTTP method. Fixes that block one exact string and miss its cousin are common.
4. Check the logs. A well fixed system often records the rejected attempt. If your logging shows nothing, note that as a separate gap.

Turn it into a regression test

Convert the proof of concept into an automated test that runs in CI. It should assert the good result. Name it after the finding, so a failure points straight at the history. When someone refactors the code in two years, this test is what stops the bug returning.

This is also cheap evidence for audits and customer questions. A dated record that says "the exploit succeeded on version X and fails on version Y" is much stronger than "we upgraded the package."

Where this is not possible

Some findings cannot be reproduced safely, such as a flaw in a third party service or one that needs production scale. In those cases, record what you did check: the version change, the vendor advisory, and any compensating control. Say plainly that you could not re-run the exploit.

If you want a quick view of whether a vulnerable function is even called by your code before you invest in a test, Safeguard provides reachability analysis, and you can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Walk through the exploitability check and note which questions it asks before it treats a finding as real. The same questions shape a good retest.

Quick check

Last reviewed: 19 October 2026.