Reproducible Vulnerability Evidence: Inside Vexta's Full HTTP Exchange Archive

Reproducible vulnerability evidence is a record of the exact request and response that produced a finding, captured and hashed so a third party can independently confirm it happened rather than take your word for it. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and it builds that record automatically: every proof-of-exploitation attempt produces a proof artifact, and every HTTP request Vexta issues during a scan is written to an append-only, hash-chained archive.

What a proof artifact actually contains

Every time Vexta's proof-of-exploitation engine attempts to verify a finding, it produces a structured record: which verifier ran, which attempt number it was, how long it took in milliseconds, a SHA256 hash of the request, the request body itself (truncated to 4 KiB), a SHA256 hash of the response, the response body (also truncated to 4 KiB), and the timestamp it was captured.

That is not a summary or a screenshot. It is the actual bytes that went over the wire, hashed so the record cannot be quietly edited after the fact, and it is what makes a finding something a third party can replay and check for themselves instead of trusting a description of what supposedly happened.

How does Vexta make a finding replayable?

Every proof artifact is hashed into an audit chain, and Vexta exposes an API endpoint for replaying any archived exchange. In practice that means a client's security team, a bounty program's triager, or an auditor reviewing a pentest deliverable does not have to take the hunter's narrative account of a bug. They can pull the exact request that was sent and the exact response that came back, both fingerprinted with SHA256 hashes, and confirm the finding is what it claims to be.

This matters most on the findings people are most likely to argue about: a blind SSRF confirmed only through an out-of-band callback, a race condition that only shows up on the right timing, or a second-order SQL injection where the vulnerable request and the triggering request are two different calls. A written description of any of these invites doubt. The actual request-response pair, hashed and stored, does not.

The full HTTP exchange archive

Proof artifacts cover verifier attempts specifically. Underneath that, Vexta also keeps a complete record of every HTTP request and response it issues during a scan, proof-of-exploitation or not. That archive is stored as append-only, gzipped NDJSON, one line per exchange, and it is chained with SHA256 hashes so that tampering with any single record invalidates everything after it.

A SQLite index keyed on scan ID and sequence number makes it possible to look up any specific exchange quickly rather than scanning through a compressed log file by hand. The archive has a configurable size cap, 500 MB by default, and once that cap is hit it stops recording rather than silently truncating older data or crashing the scan.

On top of the hash chain, Vexta can produce a cryptographic notarization of a scan's integrity: a way to prove after the fact that the archive you are holding is the same one the scan actually produced, not one that was edited afterward.

Why this matters more than a screenshot

A screenshot of a vulnerable response, or a paragraph describing what a payload did, is evidence you have to trust. It can be cropped, mistimed, or simply misremembered. A hashed request-response pair with a timestamp is evidence you can check: recompute the hash, compare it against the chain, and know whether the record has been altered since it was captured.

For a bug bounty hunter, that turns a disputed finding into a shorter conversation. Instead of re-explaining what you saw, you hand over the archived exchange and let the program's triager verify it directly. For a pentester writing a client deliverable, the same archive is what lets the report's per-finding evidence hold up months later when someone asks how a specific claim was reached.

None of this changes the rules of engagement. Replaying an archived exchange to confirm a finding is still something you do inside the scope you were authorized for in the first place, the same as the original scan; the archive documents what happened, it does not grant permission to do more.

Where the archive fits alongside the rest of a report

The exchange archive and the proof artifacts are not the finished deliverable on their own; they are the backing evidence behind it. When a scan's results go into an HTML, PDF or Word report, the per-finding evidence in that document draws on the same captured requests and responses, so the summary a client reads and the raw proof a skeptical reviewer wants to check both trace back to the same hashed record instead of two different accounts of what happened.

Because Vexta runs as a single self-hosted binary and keeps everything it captures on the machine it runs on, that archive stays under your control rather than sitting on a third-party server somewhere. Exactly how much archive retention and which notarization capabilities are available depends on your license, so check the current tiers on the pricing page if that is a factor in how your team plans engagements.

The practical upshot is that evidence quality does not depend on how carefully a hunter remembered to take notes during a fast-moving engagement. It is captured automatically, by default, for every exchange, whether or not anyone thinks in the moment that a particular request might matter later.

Key takeaways