Reproduced Exploit
RebaseReward deposits the wrong token on claim
Chain
Other
Category
untagged
Date
Jan 1970
Source
DeFiHackLabs
EVM Playground
Source-level debugger — step opcodes and Solidity in sync
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.
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.
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#
Marked-line walkthrough (Playground)#
The EVM Playground pins each step to the exact executed source line in 0xbd4fd5a3ce…:
- L71 — Step: Executes
function incentivize(address token, uint256 amount) external { - L81 — Vulnerable line: Executes
veKitten.deposit_for(_tokenId, reward); - L82 — Step: Executes
emit ClaimReward(_period, _tokenId, token, _owner); - L91 — Step: Executes
contract Exploit { - L92 — Step: Executes
address internal constant SINK = 0x000000000000000000000000000000000000D00d; - L96 — Step: Executes
MiniToken public token0;
PoC#
Registry (Foundry, local deploy — verbatim vulnerable source + harm-asserting test):
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
- DeFiHackLabs incident explorer: search "RebaseReward deposits the wrong token on claim".
- 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.