Skip to content

v0.1.0 — one command proves an exploit by running it

Choose a tag to compare

@ExploitReplay ExploitReplay released this 21 Aug 16:45
· 43 commits to main since this release

exploitrun scan replays a library of known Solana exploit classes against an
Anchor program inside an in-process SVM. On the vulnerable half of a fixture pair
it returns EXPLOITED with the attacker's transaction, the account delta that
proves the gain, and the source line that allowed it, and exits 1. On the fixed
half it returns BLOCKED and exits 0.

BLOCKED means this attack did not get through. It never means the program is
safe: this tool proves presence, never absence.

Running it

Linux or macOS — the SVM runtime ships no Windows binary, so on Windows this runs
under WSL. Node 22+, pnpm 9+. Nothing is published to npm yet, so build from the
tag:

git clone --branch v0.1.0 https://github.com/ExploitReplay/exploitrun.git
cd exploitrun
pnpm install
pnpm build

Then point it at a checkout and hand it the built program:

node apps/cli/dist/index.js scan <path> --artifact <dir>

--artifact takes a directory holding one .so and its IDL. --scenarios <ids>
runs a subset instead of the whole library; --json <file> writes the
machine-readable report.

Exit codes

Code Meaning
0 nothing got through
1 at least one scenario reached EXPLOITED
2 every scenario was inconclusive
64 the invocation itself was wrong

What this release does not have, and it has to be said out loud

  • BLOCKED never means safe. One scenario class (missing-signer), one fixture
    pair. Zero false positives is measured on that pair, not on a library.
  • No GitHub Action, no fork mode, no PoC redaction. apps/action is a stub.
  • The CLI needs --artifact passed by hand, and locates sources by searching the
    path it was given rather than by following the artifact.
  • Fixture reproducibility is verified on one machine. The workflow that would
    verify it across machines has never run.