How Vexta Verifies Every Vulnerability It Finds

What is a vulnerability verification tool, and why does a finding need one before you trust it? A vulnerability verification tool re-tests a scanner's finding against the live target and hands back a verdict - confirmed, ruled out, or still undecided - instead of leaving a hunter to manually recheck every line item by hand. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, builds this straight into its scan pipeline as the Proof-of-Exploitation (PoE) engine: every finding gets a non-destructive re-probe and comes back proven, refuted, or unproven, never a guess dressed up as certainty.

What do proven, refuted, and unproven actually mean?

The PoE engine runs a safe re-probe against each finding under a strict set of rules: side effects are read-only only, so nothing gets inserted, updated, or deleted on the target. Each verifier gets one shot with retries on transient errors (three attempts, backing off 500ms, then 1 second, then 2 seconds) and an 8-second timeout, so a slow endpoint doesn't hang the scan. The result maps to one of three verdicts. A clean pass produces proven, with the evidence captured. A verifier that ran its safe proof-of-concept without incident and found nothing there returns refuted. Anything else, including a timeout or a capability gap, comes back unproven, with the specific reason attached to the finding.

That third state is the point. A finding a hunter hasn't personally reproduced is a liability if it gets treated as gospel either way, so Vexta separates 'we tested this and it's real,' 'we tested this and it's not there,' and 'we don't know yet' into three distinct, visible states instead of collapsing them into a single confidence number.

Why can't a network hiccup fake a refuted verdict?

The design rule behind Proof-of-Exploitation is blunt: network errors never cause a false refute. If the target was unreachable, DNS failed, or a connection reset mid-probe, the finding stays unproven, with the failure reason recorded, rather than silently flipping to refuted. That distinction matters most on blind bug classes that rely on an out-of-band (OOB) channel, a callback path a payload pings from outside the direct HTTP response to prove a bug that never echoes anything back, such as blind SSRF or XXE. Earlier versions of the engine returned a clean refutation whenever the operator forgot to switch the OOB listener on, which quietly hid real bugs behind a configuration mistake. Vexta now treats an offline listener as a transient failure, so those findings sit at unproven until they get a real retest with a working callback path.

The same discipline shows up elsewhere. The IDOR verifier fetches the same resource ID twice and requires the two responses to hash-match before it will compare them against a swapped ID, so a merely inconsistent endpoint reports unproven instead of a confident but wrong verdict. Second-order SQL injection verification refuses to guess which URL actually triggers the injected payload; it insists on the detector supplying that URL explicitly, closing a gap where a trigger point different from the injection point used to cause a false refute. Prototype pollution findings need two independent fetches to agree before the engine will call them proven at all.

How wide is the verifier coverage?

Vexta ships 48 registered verifier classes, grouped by the kind of bug they confirm. The injection family covers SQL injection (error-based, boolean-based, and time-based), NoSQL injection, LDAP and XPath injection, server-side template injection, remote code execution, local file inclusion, and second-order SQL injection. The server-side and network family covers server-side request forgery, including cloud metadata endpoints across AWS, GCP, Azure, and other providers, XML external entity injection, host header poisoning, and insecure deserialization. The client-side family covers reflected and blind stored cross-site scripting, CRLF injection, open redirect, clickjacking, and prototype pollution. An auth and configuration family covers insecure direct object reference, mass assignment, JWT algorithm confusion, CORS misconfiguration, and missing security headers, and a GraphQL family covers introspection exposure, batching abuse, alias-based rate-limit bypass, authentication gaps, and unbounded deep-query denial of service.

Not every class gets automated to the same depth, and Vexta says so instead of pretending otherwise. DOM-based XSS, for instance, returns a clean 'cannot prove' verdict on purpose, because confirming it safely needs a headless browser re-test a human should run, not a script assuming the DOM behaved as expected. That kind of honesty about limits is itself a signal a hunter can use when deciding what still needs eyes on it.

What happens after a finding is proven?

Every verifier attempt produces a proof_artifact: the verifier ID, the attempt number, the latency, a SHA-256 hash of the request and response with a truncated capture of each, and a timestamp. That artifact gets hashed into the audit chain, so a teammate, a client, or a bounty program can independently replay the exact request that produced the verdict rather than taking the report's word for it.

Each finding also carries an operator-managed status (open, submitted, duplicate, paid, wontfix, or ignored), an optional note, and an assignee, so a team can move findings through triage without leaving the dashboard. On the finding row itself, a set of reliability badges keeps the verdict visible at a glance: PROVEN in green, UNVERIFIED in amber when PoE couldn't decide and a manual reproduction is required before submission, REFUTED in grey when PoE actively ruled the bug out, EXPERIMENTAL for detector classes on a curated known-flaky list, and FROM AI when the discovery path involved the AI loop and needs independent reproduction. None of that requires opening the finding to check; it's right there in the row header, which matters most on a large scope where dozens of findings land at once and a hunter has to decide, in seconds, which ones are worth opening first.

Key takeaways