Crypto Trainingblogweb3 security engineering
<- Back to hacks

Reproduced Exploit

Etherspot — an attacker installs their session key and claims the escrow

enableSessionKey ends with sessionKeyToWallet[sessionKey] = msg.sender. It does not check that another wallet already owns that key. Locks are stored by session key, and claim pays whoever that mapping names.

Jul 2025•Other•access-control•4 min read

Chain

Other

Category

access-control

Date

Jul 2025

Source

AuditVault

PoC & write-upPoC for your local evm-hack-analyzerAuditVault PoCs

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: 61404-c-02-unauthorized-session-key-takeover-via-missing-ownership. Standalone Foundry PoC and full write-up: 61404-c-02-unauthorized-session-key-takeover-via-missing-ownership_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/access-control/missing-owner-check · vuln/access-control/missing-auth

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/61404-c-02-unauthorized-session-key-takeover-via-missing-ownership_exp.sol.

Key info#

ImpactHIGH — the attacker claims 1,000 the victim escrowed under a session key
ProtocolEtherspot CredibleAccountModule
Vulnerable codeenableSessionKey sets sessionKeyToWallet[sessionKey] = msg.sender with no existing-owner check
Bug classAnyone can take over a live session key and claim its locked tokens
FindingShieldify — Credible Account Module, July 2025 · C-02 · id 61404
ReportEtherspot-CredibleAccountModule-Security-Review.md
SourceAuditVault finding
StatusFixed by reverting when sessionKeyToWallet[sessionKey] is already set. Reproduced here as a local synthetic.
Compilersolc 0.8.27, cancun, via IR

TL;DR#

enableSessionKey ends with sessionKeyToWallet[sessionKey] = msg.sender. It does not check that another wallet already owns that key. Locks are stored by session key, and claim pays whoever that mapping names.

  1. The victim enables the key and escrows 1,000. The mapping points at the victim.
  2. The attacker calls enableSessionKey for the same key with amount 0. The mapping now points at the attacker. The escrow stays.
  3. claim sees the attacker as the owner and transfers 1,000 to them.

The vulnerable code#

Pre-fix tail of enableSessionKey:

SOLIDITY
if (amount > 0) {
    Token(token).transferFrom(msg.sender, address(this), amount);
    _locks[sessionKey].push(LockedToken(token, amount, 0));
}
// @> VULN: any caller becomes the owner, even when another wallet already registered this key
sessionKeyToWallet[sessionKey] = msg.sender;

claim then requires only msg.sender == sessionKeyToWallet[sessionKey] and transfers the unpaid locks. The fixed enable reverts with SessionKeyOwned when the mapping is already non-zero. The attacker's call reverts, their claim reverts NotOwner, and the victim can still claim the 1,000.

Root cause#

Ownership of a session key is a single slot overwritten by every successful enable. The escrow is keyed by the session key, not by the wallet that deposited it, so the new owner can claim the old deposit.

Preconditions#

  • A victim has enabled a session key and the module holds their tokens. Here that is 1,000.
  • The attacker knows the session key address and calls enableSessionKey for it. They pass amount 0, so they do not need a balance.
  • claim pays the address currently stored in sessionKeyToWallet.

Attack walkthrough#

  1. Mint 1,000 to the victim. The victim approves the module and enables the key. The module's balance is 1,000 and the owner is the victim.
  2. The attacker enables the same key with amount 0. sessionKeyToWallet becomes the attacker.
  3. The attacker calls claim. The module transfers 1,000 to them. The victim's balance and the module's balance are both 0.

Control: the second enableSessionKey reverts SessionKeyOwned. The attacker's claim reverts NotOwner. The module still holds 1,000. A claim from the victim pays the victim 1,000.

Diagrams#

flowchart TD A["Victim escrows 1000 under their session key"] --> B["Attacker calls enableSessionKey for that same key"] B --> C["sessionKeyToWallet now points at the attacker"] C --> D["claim pays the 1000 escrow to the attacker"]

Impact#

The attacker takes 1,000 the victim locked. The victim is no longer the owner, so they cannot claim or recover the session through the module. Any later deposit recorded on that session key is payable to whoever overwrote the mapping.

Remediation#

Before the assignment, revert if sessionKeyToWallet[sessionKey] is already set. Shieldify's fix is that check. Do not let a second caller replace the wallet that deposited the locks.

Sources#

Taxonomy#

  • vuln/access-control/missing-owner-check
  • vuln/access-control/missing-auth

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.