xLOOT Staking Exploit — Duplicate NFT IDs in `redeem(uint256[])` Claim the Same Epoch Reward Repeatedly

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2026-04-XLootStaking_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/XLootStaking_exp.sol.

Vulnerability classes: vuln/logic/reward-calculation · vuln/logic/missing-check

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. The umbrella DeFiHackLabs repo contains several unrelated PoCs that do not all compile together, so this one was extracted into a standalone project. Full verbose trace: output.txt. Verified vulnerable source (active implementation behind the proxy): contracts_Staking.sol.

Key info#

TL;DR#

1. xLOOT stakers earn a weekly epoch reward. Each xLOOT NFT can claim a fixed earning-per-NFT (epn) for every epoch it has not yet redeemed. A per-NFT cursor xloot.nextRedeem[id] records the last epoch each token already claimed, so an NFT cannot double-claim the same epoch across separate calls.

2. The flaw is that the cursor is only written after the reward total is fully computed. Staking.redeem(uint256[]) → _redeemLoot → _redeemable (contracts_Staking.sol:234-431) loops over the entire supplied id array, accumulating epn for each entry, and only checks ownerOf(id) == account. The cursor nextRedeem[id] is advanced in a separate loop in _redeemLoot (:317-321) that runs after the payout — and only once per id list, not once per array entry.

3. Consequently the same owned NFT can appear many times in a single redeem call. Every duplicate entry reads the same un-advanced nextRedeem[id] and adds the full epoch reward again. There is no nonReentrant, no in-call dedup, and no per-id claimed-this-epoch flag.

4. To make the reward worth stealing, the attacker first commits a fresh epoch. The staking proxy's receive() (:159-167) finalizes the pending epoch once block.timestamp >= epoc.time. A 2.1 ETH Balancer flash loan, unwrapped to raw ETH and sent into the proxy, both funds and triggers _commitEpoc(), producing epoch 47 with epn = 5,723,348,362,381,992 wei (~0.005723 ETH per NFT) (output.txt:201).

5. The attacker owns 7 xLOOT IDs (128,144,145,195,49,51,52), each with cursor 46 (output.txt:52-56) — one epoch behind. They build a redeem array of those 7 ids repeated 155 times each = 1,085 entries and call redeem.

6. claimableOf previews the payout as 6,209,832,973,184,461,320 wei (~6.2098 ETH) (output.txt:2388), exactly 1,085 × 5,723,348,362,381,992. redeem then transfers that ETH to the attacker contract (output.txt:4562) while advancing each id's cursor only once (46 → 48, output.txt:4570-4576).

7. The attacker repays the 2.1 WETH flash loan (output.txt:4583), returns the 7 NFTs to the EOA, and sweeps the remainder. Net PoC profit: 4.110409994732514492 ETH (output.txt:4637, output.txt:8).

Background — what xLOOT Staking does#

The Staking contract is a UUPS-style upgradeable revenue-share system deployed behind a TransparentUpgradeableProxy. ETH revenue is pushed into the contract over time and distributed in weekly epochs. Two earner classes exist:

• $LOOT stakers accrue points per token-per-day and share an epoch's ETH pro-rata (_stake/unstake/_redeemable).
• xLOOT NFT holders each earn a flat earning-per-NFT (epn) per epoch, regardless of staking. Each NFT has its own redemption cursor xloot.nextRedeem[id] recording the last epoch it claimed.

Epoch lifecycle:

• ETH arrives via the proxy's receive(); the value is added to the pending epoch's value. When the pending epoch's scheduled time has elapsed, _commitEpoc() finalizes it: it computes epp (earning-per-point) and epn (earning-per-NFT) from that epoch's value, then opens the next epoch (:159-232).
• Holders later pull their accumulated rewards with redeem(uint256[] xloots), passing the NFT ids they own.

On-chain parameters / state at the fork block (read from the trace):

The whole game is the last few rows: each of the attacker's NFTs is owed exactly one epoch's epn (epoch 47). Supplying each id 155 times turns a 7-NFT, ~0.04 ETH claim into a 1,085-entry, 6.21 ETH claim, because every duplicate re-reads the same nextRedeem cursor.

The vulnerable code#

1. redeem → _redeemLoot: the cursor is advanced after the payout is computed#

function redeem(uint256[] memory xloots) external {
    _redeemLoot(msg.sender, xloots);
}

(contracts_Staking.sol:234-236)

function _redeemLoot(address account, uint256[] memory xloots) internal {
    StakingStorage storage $ = _getOwnStorage();
    User storage _user = $.users[account];

    (
        uint256 claimable,
        uint256 bonusAmount,
        uint256 time,
        uint256 duration,
        uint256 points
    ) = _redeemable(account, xloots);          // ← computes FULL payout first

    // ... user point bookkeeping ...
    _user.epoc = $.nextEpocId - 1;
    if (xloots.length > 0) {
        for (uint256 i = 0; i < xloots.length; i++) {
            $.xloot.nextRedeem[xloots[i]] = $.nextEpocId;   // ← cursor advanced AFTER, idempotent per id
        }
    }

    if (claimable > 0) {
        _user.totalClaimed += claimable;
        (bool success, ) = account.call{value: claimable}("");   // ← pays the inflated amount
        require(success, "Transfer Fail");
        emit Redeem(account, xloots, claimable, $.nextEpocId - 1, block.timestamp, duration);
    }
    // ...
}

(contracts_Staking.sol:297-341)

The cursor loop at lines 317-321 writes nextRedeem[id] = nextEpocId once for each distinct array slot, but because all 1,085 slots that share id 128 write the same value, the result is identical to writing it once. The eligibility check has already happened — and inflated the total — in _redeemable, which ran before any cursor was touched.

2. _redeemable: per-entry accumulation gated only by ownerOf(id)#

if (xloots.length > 0) {
    for (uint256 i = 0; i < xloots.length; i++) {
        uint256 id = xloots[i];
        IERC721 _xloot = IERC721($.xloot.token);
        require(_xloot.ownerOf(id) == account, "Invalid xLoot Owner");   // ← ONLY guard
        if (
            $.xloot.nextRedeem[id] > 0 &&
            $.xloot.nextRedeem[id] < $.nextEpocId
        ) {
            uint256 fromEpoc = $.xloot.nextRedeem[id];                   // ← same value every duplicate
            if (fromEpoc + $.config.maxRedeemEpoc < $.nextEpocId) {
                fromEpoc = $.nextEpocId - $.config.maxRedeemEpoc;
            }
            // ...
            // redeem all epoc
            for (uint256 j = fromEpoc; j < $.nextEpocId; j++) {
                claimable += $.epocs[j].epn;                            // ← adds epn AGAIN per duplicate
                BonusLoot memory bonusLoot = $.bonus[j];
                if (bonusLoot.amount > 0) {
                    bonusAmount += bonusLoot.epn;
                }
            }
        }
    }
}

(contracts_Staking.sol:393-426)

This is a view function (it never writes), so nextRedeem[id] cannot change between iterations of the i loop. Each duplicate of id 128 therefore enters the if, reads fromEpoc = nextRedeem[128] = 46, loops j = 46 → 47 (< nextEpocId = 48), and adds epocs[47].epn to claimable. With epoch 46's epn already 0, the net effect is +epn(47) per duplicate.

3. claimableOf exposes the same broken math (used by the PoC to size the attack)#

function claimableOf(address account, uint256[] memory xloots)
    external view
    returns (uint256 claimable, uint256 bonusAmount, uint256 duration)
{
    (claimable, bonusAmount, , duration, ) = _redeemable(account, xloots);
}

(contracts_Staking.sol:556-565)

4. receive() / _commitEpoc: a permissionless way to mint a fresh epoch to drain#

receive() external payable {
    StakingStorage storage $ = _getOwnStorage();
    Epoc storage _nextEpoc = $.epocs[$.nextEpocId];
    _nextEpoc.value += msg.value;

    if (_nextEpoc.time <= block.timestamp) {   // ← any sender can finalize once the timer elapsed
        _commitEpoc();
    }
}

(contracts_Staking.sol:159-167)

_commitEpoc() computes epn for the just-closed epoch and advances nextEpocId (storage change 47 → 48, output.txt:206). The attacker uses this to guarantee there is exactly one fresh, unredeemed epoch worth epn for each of their NFTs at attack time.

Root cause — why it was possible#

The defect is a classic read-all-then-write-all ordering bug combined with a missing per-call deduplication:

1. Eligibility and payout are computed in a view pass that cannot mutate the cursor. _redeemable accumulates claimable += epn for every array entry, but the only state that gates the addition — xloot.nextRedeem[id] — is never updated inside that pass. It is a view function.

2. The cursor is advanced only afterwards, and idempotently per distinct id. The write loop in _redeemLoot (lines 317-321) sets nextRedeem[id] = nextEpocId. Writing the same value 155 times for id 128 is indistinguishable from writing it once. By the time it runs, the inflated claimable total is already fixed.

3. The per-entry guard is ownerOf(id) == account, which is duplicate-insensitive. Owning an NFT once lets it appear arbitrarily many times in the array; ownerOf returns the same owner for every occurrence.

4. No reentrancy guard, no "claimed this epoch" set, no input dedup. Nothing in the call path collapses repeated ids, caps array length meaningfully (1,085 entries is well within gas), or marks an (id, epoch) pair as consumed mid-call.

The correct invariant — "each NFT can claim each epoch at most once" — is enforced across calls (via the cursor) but not within a single call. The flash loan is merely a convenience: it lets the attacker create a fresh, fully-funded epoch and pay the gas with borrowed capital, then repay it in the same transaction. The reward inflation itself requires no borrowed capital at all — it is a pure logic bug.

Preconditions#

• Own at least one xLOOT NFT whose cursor nextRedeem[id] is behind nextEpocId (i.e. it has at least one unredeemed epoch). The attacker owned 7, all at cursor 46 vs nextEpocId 47 (output.txt:52-56). Profit scales linearly with (#owned NFTs) × (repeat count) × epn × (#unredeemed epochs).
• A committable epoch. The pending epoch's scheduled time must have elapsed so that sending ETH into receive() finalizes it and produces a non-zero epn. The PoC reads nextEpoc().time (1776262763) and vm.warps to it (XLootStaking_exp.sol:90-91).
• Enough ETH to seed the new epoch's value so epn > 0. The PoC flash-borrows 2.1 WETH from Balancer (fee 0, output.txt:185-186), unwraps it, and sends it into the proxy — this is recovered intra-transaction, hence flash-loanable.
• No reentrancy or per-call dedup protection on redeem — satisfied by the deployed code.

Attack walkthrough (with on-chain numbers from the trace)#

All figures are taken directly from the trace; raw wei first, human approximation in parentheses. The "reward pool" column is the proxy's ETH that backs the per-NFT epn.

Profit / loss accounting (ETH)#

The PoC asserts attackerProfit > 4 ether (XLootStaking_exp.sol:99, output.txt:4646) and that each NFT's cursor advanced exactly once (startingNextEpoch + 1, XLootStaking_exp.sol:102-105). The honest claim for 7 NFTs over one epoch would have been 7 × epn ≈ 0.04006 ETH; the duplicate-id attack multiplied that by 155 to ~6.21 ETH, of which ~4.11 ETH is pure profit after returning the borrowed 2.1.

Note: the live incident's headline loss is 6.21 ETH (the gross amount drained from the reward pool, per the PoC @KeyInfo header). The PoC's asserted figure is the net attacker profit (~4.11 ETH) after the flash-loan repayment.

Diagrams#

Sequence of the attack#

Reward-pool / cursor state evolution#

The flaw inside redeem / _redeemable / _redeemLoot#

Why it is theft: entitlement vs. paid-out#

Why each magic number#

• WETH_FLASH_AMOUNT = 2.1 ether (XLootStaking_exp.sol:31): the ETH sent into receive() to seed the pending epoch's value. It produces epoch 47.value = 2.11e18 (2.1 borrowed + 0.01 pre-existing pending value) and epn = 5,723,348,362,381,992 (output.txt:201). It is fully repaid to Balancer (fee 0), so it is working capital, not cost. Any amount large enough to make epn worth more than gas would do.
• TRACE_REPEAT_COUNT = 155 (XLootStaking_exp.sol:32): the number of times each owned id is repeated. 7 ids × 155 = 1,085 entries, the exact count needed to reproduce the live attack's 6,209,832,973,184,461,320 wei payout (1,085 × epn). It must stay under the gas ceiling (the redeem call costs ~7.2M gas, output.txt:2390); 155 is the value the live attacker chose, not a hard maximum.
• The 7 ids 128,144,145,195,49,51,52 (XLootStaking_exp.sol:110-116): the xLOOT NFTs the attacker EOA actually owned at the fork block, each with cursor 46 (one unredeemed epoch). The PoC asserts ownership and cursor before attacking (XLootStaking_exp.sol:78-79).
• forkBlock = 24_885_767 (XLootStaking_exp.sol:60): the block at which the attacker owns the NFTs and nextEpocId == 47, immediately before the live exploit.
• The 2.1 WETH repayment (output.txt:4577-4583): exactly the borrowed principal; the Balancer fee was 0 (output.txt:185-186), so no surplus repayment was needed.

Remediation#

1. Deduplicate ids within a redeem call. Reject or collapse repeated ids before computing rewards (e.g. require strictly increasing ids, or track a seen set / bitmap per call). A single owned NFT must contribute to claimable at most once per epoch per call.
2. Advance the cursor before (or atomically with) crediting the reward. Restructure _redeemable/_redeemLoot so that processing id x sets nextRedeem[x] = nextEpocId before the next array entry is read. Then a second occurrence of x finds nextRedeem[x] == nextEpocId, fails the nextRedeem[id] < nextEpocId test, and contributes nothing. (This requires moving the reward accumulation out of a pure view function into the state-mutating path, or marking (id, epoch) pairs consumed as they are counted.)
3. Add nonReentrant and pay last. Mark redeem nonReentrant and follow checks-effects-interactions: update all cursors and totalClaimed, then perform the single ETH call.
4. Track claimed-per-epoch explicitly. Maintain a claimed[id][epoch] flag (or a lastClaimedEpoch that the inner loop checks and writes per iteration) so the same (id, epoch) can never be paid twice regardless of array shape.
5. Bound the per-call array and gate epoch creation. Cap the xloots array length to a sane maximum and consider restricting receive()-driven _commitEpoc() so a fresh epoch cannot be conjured by an arbitrary caller in the same transaction as a claim.

How to reproduce#

The PoC runs offline against a local anvil fork served from anvil_state.json (the test's createSelectFork points at http://127.0.0.1:8545, XLootStaking_exp.sol:61); no public RPC is contacted.

_shared/run_poc.sh 2026-04-XLootStaking_exp --mt testExploit -vvvvv

• foundry.toml sets evm_version = 'cancun' and fs_permissions = read ./ so the harness can load the local fork state.
• The harness boots anvil from the bundled anvil_state.json and serves historical state at fork block 24,885,767; the test forks 127.0.0.1:8545. No mainnet archive endpoint is required.
• Result: [PASS] testExploit() with Attacker profit ETH Balance: 4.110409994732514492.

Expected tail (from output.txt:4-9 and output.txt:4724-4727):

Ran 1 test for test/XLootStaking_exp.sol:ContractTest
[PASS] testExploit() (gas: 16539049)
Logs:
  Attacker Before exploit ETH Balance: 0.000000000000000000
  Attacker profit ETH Balance: 4.110409994732514492
  Attacker After exploit ETH Balance: 4.110409994732514492

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 20.33s (19.04s CPU time)

Reference: DefimonAlerts — https://x.com/DefimonAlerts/status/2044709964091187660 (xLOOT Staking, Ethereum mainnet, Apr 2026, 6.21 ETH).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2026-04-XLootStaking_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: XLootStaking_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "xLOOT Staking Exploit".
• 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.