Reproduced Exploit

RebaseReward deposits the wrong token on claim

Jan 1970Otheruntagged2 min read

Chain

Other

Category

untagged

Date

Jan 1970

Source

DeFiHackLabs

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. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. The historical source/toolchain is unavailable; this entry is documentation only and claims no executable Forge PoC. DeFiHackLabs PoC directory: src/test.


Vulnerability classes: vuln/logic

Reproduction: a faithful minimal reproduction of the vulnerable finding — the vulnerable code is reproduced verbatim (marked @>) with faithful minimal doubles; local deploy, no fork.

Root cause#

RebaseReward.getReward always calls veKitten.deposit_for (depositing KITTEN) regardless of the reward token, so a non-Kitten (token0) reward is paid out as Kitten while 100e18 of token0 stays locked in the contract forever.

SOLIDITY
        uint256 reward = rewardOf[token];
        rewardOf[token] = 0;
        if (reward > 0) {
            veKitten.deposit_for(_tokenId, reward); // @> VULN (this line)

Why it's exploitable here#

RebaseReward.getReward always calls veKitten.deposit_for (depositing KITTEN) regardless of the reward token, so a non-Kitten (token0) reward is paid out as Kitten while 100e18 of token0 stays locked in the contract forever.

Attack path#

flowchart TD S0["Step"] S1["Vulnerable line"] S2["Step"] S3["Step"] S4["Step"] H["RebaseReward.getReward always calls veKitten.deposit_for (de"] S0 --> S1 S1 --> S2 S2 --> S3 S3 --> S4 S4 --> H

Marked-line walkthrough (Playground)#

The EVM Playground pins each step to the exact executed source line in 0xbd4fd5a3ce…:

  1. L71 — Step: Executes function incentivize(address token, uint256 amount) external {
  2. L81 — Vulnerable line: Executes veKitten.deposit_for(_tokenId, reward);
  3. L82 — Step: Executes emit ClaimReward(_period, _tokenId, token, _owner);
  4. L91 — Step: Executes contract Exploit {
  5. L92 — Step: Executes address internal constant SINK = 0x000000000000000000000000000000000000D00d;
  6. L96 — Step: Executes MiniToken public token0;

PoC#

Registry (Foundry, local deploy — verbatim vulnerable source + harm-asserting test):

BASH
cd 58205-c-01-rebasereward-fails-because-of-incorrect-token-handling_exp
forge test -vvv

The browser Playground replays the same synthetic opcode-for-opcode and measures the harm. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).


Sources & further analysis#

Reproductions & code

  • No executable Forge reproduction is claimed; the historical source/toolchain was unavailable for this finding.
  • Upstream DeFiHackLabs PoC directory: src/test.

Alerts & third-party analyses

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.