Reproduced Exploit

Superform — a PPS signature with no nonce is replayed and the redeem pays 100 too much

The PPS message hash has no nonce. A signature over PPS = 2 ether is accepted, a fresh price of 1 ether is posted, and the same signature is accepted again. That second use puts the stale price back.

Jun 2025•Other•auth•4 min read

Chain

Other

Category

auth

Date

Jun 2025

Source

AuditVault

EVM Playground

Source-level debugger — step opcodes and Solidity in sync

evm-hack-analyzer

The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.

Loading fork state…

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 63079-lack-of-replay-protection-in-pps-oracle-spearbit-none-superf. Standalone Foundry PoC and full write-up: 63079-lack-of-replay-protection-in-pps-oracle-spearbit-none-superf_exp in the evm-hack-registry mirror.


Vulnerability classes: vuln/auth/signature-replay · vuln/oracle/stale-price

Reproduction: a self-contained Foundry PoC that compiles and runs offline with only forge-std — no fork and no RPC. Trace: output.txt. PoC: test/63079-lack-of-replay-protection-in-pps-oracle-spearbit-none-superf_exp.sol.


Key info#

ImpactHIGH — the second use of one signature sets PPS to 2 ether and a 100-share redeem pays 200 ASSET instead of 100. Off by 100 ASSET
ProtocolSuperform v2 periphery, ECDSA PPS oracle
Vulnerable codeupdate hashes strategy, pps, stdev, validator, totalValidators, timestamp and never consumes a nonce
Bug classSignature replay of a stale PPS
FindingSpearbit (MiloTruck) — Superform v2 periphery, June 2025 · id 63079
ReportSuperform v2 periphery review
SourceAuditVault finding
StatusReproduced here as a local synthetic. The signer key is held locally and one signature is precomputed.
Compilersolc 0.8.27, cancun, via IR

TL;DR#

The PPS message hash has no nonce. A signature over PPS = 2 ether is accepted, a fresh price of 1 ether is posted, and the same signature is accepted again. That second use puts the stale price back.

A redeemer with 100 shares is then paid 100 * 2 = 200 ASSET. At the fair PPS the payout is 100 ASSET. The difference is N = 100 ASSET.

Control puts nonce in the hash and increments it. The first submission succeeds and consumes nonce 0. The second submission of that signature reverts. The fresh PPS stays 1 ether, and the redeem pays 100 ASSET.

The vulnerable code#

SOLIDITY
bytes32 messageHash = keccak256(abi.encodePacked(strategy, price, stdev, validator, totalValidators, timestamp));
bytes32 ethSigned = keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", messageHash));
address recovered = ecrecover(ethSigned, v, r, s);
require(recovered == signer, "signer");
uses += 1;
pps = price; // @> VULN: no nonce is consumed

The fix is to append nonce to the packed payload and increment it inside the successful update.

Root cause#

Verification only checks that the recovered signer is the validator. The signed bytes do not include a nonce, a chain id, or the oracle address, and the oracle does not record that this digest was already used. Any caller who has seen the signature can submit it again after a newer price is posted.

Preconditions#

  • The validator key is 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266. The signature below was produced offline for strategy 0xbeeF, PPS 2 ether, stdev 0, that validator, total validators 1, and timestamp 1700000000.
  • The vault holds 200 ASSET and the caller has 100 shares.
  • A fresh PPS of 1 ether is posted between the two submissions.

Attack walkthrough#

  1. Mint 200 ASSET into the vault and 100 shares to the redeemer.
  2. Submit the precomputed signature. The oracle sets PPS to 2 ether. uses is 1.
  3. Post the fresh PPS of 1 ether.
  4. Submit the same v, r, and s again. PPS returns to 2 ether. uses is 2.
  5. Redeem. Payout is 200 ASSET. Fair payout is 100 ASSET. offBy is 100 ASSET.

Control signs the same fields plus nonce 0. The first update consumes the nonce. The second update reverts with signer. Redeem pays 100 ASSET.

Diagrams#

flowchart TD A["One signature quotes PPS of 2 ether"] --> B["First submission sets PPS to 2"] B --> C["A fresh update sets PPS to 1 ether"] C --> D["The same signature is accepted again"] D --> E["PPS is stale at 2 ether"] E --> F["100 shares redeem for 200 ASSET instead of 100"]

Impact#

The redeemer receives 200 ASSET for 100 shares. The fair amount at PPS 1 ether is 100 ASSET. The vault overpays by 100 ASSET because the second use of the signature restored the stale price.

Remediation#

Include a nonce in the signed payload and increment it when the signature is accepted. A repeated submission then recovers a different signer and reverts.

Sources#

Taxonomy#

  • severity/high
  • sector/oracle
  • platform/spearbit

Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

  • Web3Sec X hacked database: search.
  • Rekt leaderboard: search.
  • Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.