Crypto Trainingblogweb3 security engineering
<- Back to hacks

Reproduced Exploit

Securitize DSToken — unapproved `transferFrom` theft

StandardToken.transferFrom calls its transfer primitive directly and never checks the owner's allowance for msg.sender. An arbitrary investor can therefore debit any other investor and transfer their DSToken balance to itself.

Oct 2025•Other•logic•2 min read

Chain

Other

Category

logic

Date

Oct 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: 64373-investors-can-steal-tokens-from-other-investors-since-standa. Standalone Foundry PoC and full write-up: 64373-investors-can-steal-tokens-from-other-investors-since-standa_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/missing-check · vuln/access-control/broken-logic

Reproduction: Local synthetic; forge test -vvv passes offline in this folder.

Key info#

FieldValue
Loss100 DST stolen from an investor with zero allowance
Vulnerable contractStandardToken
ChainLocal EVM synthetic
CompilerSolidity 0.8.24
Bug classMissing ERC20 spending-approval check

TL;DR#

StandardToken.transferFrom calls its transfer primitive directly and never checks the owner's allowance for msg.sender. An arbitrary investor can therefore debit any other investor and transfer their DSToken balance to itself.

The vulnerable code#

SOLIDITY
// FIX: allowance[_from][msg.sender] -= _value;
_transfer(_from, _to, _value); // @> VULN: transferFrom moves another investor's balance without checking spending approval.

Root cause#

The contract exposes the ERC20 transferFrom interface but omits the authorization invariant that distinguishes it from an unrestricted administrative transfer.

Preconditions#

  • A victim has a positive DST balance.
  • The attacker can call the token contract.

Attack walkthrough#

  1. The reduction issues 500 DST to a victim account.
  2. It proves the victim gave the attacker allowance 0.
  3. The attacker calls transferFrom(victim, attacker, 100).
  4. The unchecked transfer succeeds and the attacker receives 100 DST.

Diagrams#

sequenceDiagram participant A as Attacker participant T as StandardToken participant V as Victim A->>T: transferFrom(V, A, 100) T->>T: no allowance check T-->>A: credit 100 DST T-->>V: debit 100 DST

Impact#

Any investor's entire token balance is directly stealable without a signature or allowance.

Remediation#

Require and decrement allowance[_from][msg.sender] before the transfer, while retaining the conventional infinite-allowance behavior if intended.

How to reproduce#

BASH
cd /workspaces/RustroverProjects/audits/evm-hack-registry/64373-investors-can-steal-tokens-from-other-investors-since-standa_exp
forge test -vvv

Sources#

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.