A pull request that opens a hole gets a comment with the transaction that went through it.

#### Introduced by this PR

The pull request and its base are both built and both scanned, in the same job. The check fails only on what this change introduced; an exploit that was already on the base is reported, and does not turn the check red. The default is gate: introduced on purpose — a repository with existing debt that goes red on day one gets the Action deleted on day two.

There is one comment per pull request, and it is updated, not repeated. Push the fix to the same branch and the same comment turns: demo pull request #2 goes from red to green on one comment.

**Why this is a hole** · **How to close it** · **Where**

Why this is a hole: The instruction checks that the authority account is the one its state recorded, but never requires that account to sign. Anyone can pass the authority’s address as a plain account and act as the authority.

How to close it: Declare the authority as Signer<'info>, or add signer to its #[account(...)] constraint, so the transaction has to carry the authority’s signature.

Where: programs/vault/src/lib.rs:78 (accounts field)

Quoted from the comment on demo pull request #1.

<details> The accounts it moved and the attacker transaction

DbtJEt…XMePxN
  lamports   10.000000000 SOL → 10.999995000 SOL
5hLc5F…a4b4MT
  lamports    1.001176240 SOL →  0.001176240 SOL
1 further watched account: unchanged

gained 0.999995000 SOL

The comment carries the attacker transaction itself, in base64, so it can be replayed. It is not printed on this page.

It is in the demo’s comment because the demo vault exists only on localnet and the base branch lists it under proofs.public. For any program not listed — and for a program declared on mainnet, or declared nowhere, even when listed — the comment, the job summary and the log keep the class and the line, and withhold the transaction.

#### Other scenarios

Every scenario ships with two fixture programs, one vulnerable and one fixed, and a test that requires exploited on the first and blocked on the second. A scenario that cannot tell them apart does not ship.

· build …, replay …

Building the pull request takes 22–31 s of that; replaying the scenarios, 0–3 s. The cold run — installing the toolchain and building everything — is over five minutes, and happens once per toolchain or Cargo.lock change. A push to main builds and caches, so pull requests into main start warm.

About 4–6 runner minutes per pull request: twenty pull requests a week is 340–520 of the 2,000 free minutes a month.

.github/workflows/exploitreplay.yml

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  pull-requests: write

jobs:
  exploitreplay:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      # install solana-cli and anchor-cli at the versions Anchor.toml pins
      - uses: ExploitReplay/ExploitReplayCI/apps/action@v0.3.0

No secrets beyond the token CI already has. It runs on pull_request, never pull_request_target: it builds the pull request’s code, and that event would hand a write token to whoever opened it.