How Vexta Verifies a Vulnerability Fix Before You Close the Ticket

Vulnerability fix verification means re-running the original proof against a target after a patch, to confirm the bug is actually gone rather than just marked resolved on a ticket. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its reverify workflow does exactly that: it re-tests a previously discovered vulnerability and updates the finding's status to fixed or still_vulnerable based on what it observes on the target, not on what a changelog says.

What reverify actually checks

Reverify takes a finding Vexta already discovered and runs the check again against the same target. There are exactly two outcomes: the status moves from open to fixed, meaning the condition that produced the finding is no longer reproducible, or it moves from open to still_vulnerable, meaning the same behavior is still there.

That is a narrower, more targeted action than starting a new scan. You are not asking Vexta to go find new problems. You are asking it to answer one specific question about one specific finding: did this patch actually work.

Why a closed ticket is not proof

On any engagement or bounty program with more than a handful of findings, some fraction of "fixed" status changes are wrong. A developer patches the wrong endpoint, a fix ships to staging but not production, a WAF rule masks the symptom without touching the root cause. None of that shows up by reading a comment thread.

Manually re-testing every closed finding is the honest alternative, and it does not scale. A pentester wrapping up a report with sixty findings, or a hunter with a dozen open bounty reports awaiting fixes, cannot re-run each proof-of-concept by hand every time a client says "this is patched now." Reverify turns that manual step into something you can run on demand, finding by finding.

Where reverify fits in the workflow

The typical sequence looks like this: Vexta finds and reports a vulnerability, the client or program patches it, and instead of taking that at face value, you point reverify at the finding. If the check comes back fixed, you close the finding with evidence behind the decision instead of a guess. If it comes back still_vulnerable, you have grounds to push back before the report gets marked resolved.

Because Vexta runs as a single self-hosted binary and keeps scan data and findings on the machine it runs on, a reverify pass against one finding does not require re-exposing the rest of the engagement's data anywhere. Only the license key and hardware ID talk to the license server; the retest itself stays local to your environment.

This also matters for reporting. Findings and their current status are what feed Vexta's report output and its SARIF and JUnit XML exports, so a status that flips from open to still_vulnerable after a claimed fix shows up the same way a fresh finding would, inside the same pipeline-friendly formats a team already consumes.

Here is what that looks like end to end. Say Vexta originally flagged a reflected XSS on a search parameter, with a captured payload and response as evidence. Two weeks later the client says it is patched. Instead of taking that on faith, you run reverify against that same finding. If the parameter now encodes the payload correctly, the status flips to fixed and you close your side of the report with that evidence attached. If the same payload still executes, the status stays open as still_vulnerable, and you have something concrete to hand back rather than an argument about whose testing is wrong. Multiply that by a report with dozens of findings and a client who closes tickets faster than they actually ship fixes, and the value of an automated, repeatable retest becomes obvious: it turns a trust exercise into a checklist.

What reverify does not replace

Reverify is not a substitute for a full rescan. It answers a question about a specific, already-documented finding; it is not designed to catch a new bug introduced by the same patch elsewhere in the application. On any engagement where a patch touches shared code, a fresh scan of the affected area alongside a reverify pass on the original finding is the more complete approach.

It is also worth keeping the two ideas separate when you write up a report. A finding that reverify marks fixed is a statement about that one code path on that one date, not a statement about the whole application's posture. Treat reverify results as a precise, narrow fact you can cite, and let a broader rescan carry the weight of any claim about overall posture. A single fixed status is useful precisely because it does not try to say more than it knows.

Which plan includes automated or scheduled reverify runs, as opposed to running it on demand, is a licensing detail rather than a scanning detail, so check the current tiers on the pricing page if that matters for how your team works.

Staying inside scope when you retest

A reverify pass is still a probe against a live target, so it only belongs inside the same authorization you had for the original finding: an in-scope asset under a program's rules or a signed engagement. If the client revoked access, changed the scope, or the bounty program closed before the fix landed, that authorization does not carry over automatically, and the retest should wait until it is confirmed again. A still_vulnerable result is still evidence you disclose through the same responsible channel you used the first time, the program's reporting flow or the client's point of contact, not a public post ahead of a confirmed fix.

Key takeaways