Unverified "Slot" Staking Contract — `releaseSlot()` Reentrancy BNB Drain

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: 2025-02-unverified_35bc_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/unverified_35bc_exp.sol.

Vulnerability classes: vuln/reentrancy/single-function · vuln/logic/incorrect-order-of-operations

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not whole-compile, so this one was extracted). Full verbose trace: output.txt. The victim contract is unverified on BscScan — there is no published source. The analysis below is reconstructed from the on-chain bytecode, the live fork execution trace, and the recovered function selectors.

Key info#

TL;DR#

The contract is a BNB "slot" staking / lottery product. A user calls unlockSlot(uint256) with BNB to activate a slot, and later calls releaseSlot(uint256) to get their deposit refunded. releaseSlot sends the refund BNB to the caller before it zeroes the slot's recorded amount and active flag. The attacker's contract receives that BNB inside its fallback() and immediately calls releaseSlot(3) again on the still-"active" slot — re-entering the refund over and over.

Because the slot still reads as active and still records its 0.6 BNB amount on every re-entrant call, the contract pays out 0.6 BNB per recursion using other users' pooled BNB. The recursion repeats until the contract runs OutOfFunds. The slot's state is only finally cleared in the deepest frame — far too late.

Concretely, from the live trace:

1. Attacker deposits 0.6 BNB via unlockSlot(3). The contract now holds ≈ 11.19 BNB (10.59 BNB of prior users' deposits + the 0.6 just added).
2. Attacker triggers releaseSlot(3), which sends 0.6 BNB to the attacker's fallback(), which re-enters releaseSlot(3), which sends another 0.6 BNB… 19 nested calls, of which 18 actually transfer 0.6 BNB each = 10.8 BNB.
3. The 19th call hits OutOfFunds (contract balance below 0.6 BNB), the recursion unwinds, and only then is the slot marked inactive.

Attacker ends with 10.8 BNB (started with 0.6 BNB). Net theft of other users' funds = 10.2 BNB ≈ $6,700.

Background — what the contract does#

The victim is unverified, but its bytecode dispatcher exposes a clear public API (selectors recovered with cast 4byte and confirmed present in the deployed code). It is a BNB-denominated staking / "slot" product:

On-chain ground truth read at the fork block (via cast):

The contract was custodying ≈10.6 BNB of pooled user deposits. That pool is the prize.

The vulnerable code#

No verified source exists. The mechanism is, however, unambiguous from the execution trace in output.txt. The releaseSlot(uint256) refund function performs an external BNB transfer to the caller before clearing the slot's amount and active flag. Reconstructed, the buggy logic is equivalent to:

// 0x2dad6442  ── refund a slot's deposit to the caller
function releaseSlot(uint256 slotId) external {
    Slot storage s = slots[msg.sender][slotId];
    require(s.active, "not active");        // ← still TRUE on every re-entry
    uint256 amount = s.amount;              // ← still 0.6 BNB on every re-entry

    // ⚠️ INTERACTION before EFFECTS:
    (bool ok, ) = msg.sender.call{value: amount}("");  // sends 0.6 BNB
    require(ok, "unable to send value, user may have reverted");

    // ⚠️ state cleared only AFTER the external call returns:
    s.active = false;                       // ...3963698 / ...396369e -> 0
    s.amount = 0;                           // ...3963699 -> 0
    totalStakeAmount -= amount;             // slot 21 -> decremented
}

The fingerprint that proves this ordering is in the trace: the storage writes that clear the slot (...3963698: 2 → 0, ...3963699: 0.6 BNB → 0, ...396369a → 0, ...396369e: 1 → 0) appear only in the innermost (last) releaseSlot frame — after the contract has already sent 0.6 BNB out 18 times. The require(s.active) and the amount read happen at the top of each frame, so every re-entrant call sees the slot as still active with its full 0.6 BNB recorded.

The revert string "unable to send value, user may have reverted" (visible in the trace where the final transfer OutOfFunds) is the contract's own message on the BNB-send failure, confirming the refund is a low-level value call.

Root cause — why it was possible#

A textbook reentrancy via the checks-effects-interactions anti-pattern:

1. External call before state update. releaseSlot pushes the refund to msg.sender first, then clears the slot. While that external call is executing, the slot is still active and still records its 0.6 BNB amount.
2. No reentrancy guard. There is no nonReentrant mutex; re-entering releaseSlot for the same slotId re-passes the active check and re-reads the unchanged amount.
3. Refund amount is per-slot, not balance-aware. Each frame pays the full recorded 0.6 BNB regardless of how much of the deposit has already been refunded in outer frames, so the contract keeps handing out other users' pooled BNB.
4. The recipient is attacker-controlled code. Because the refund is a value call to msg.sender, the attacker's fallback() runs synchronously and recursively calls back into releaseSlot before the original call returns.

The single deposit of 0.6 BNB is "refunded" 18 times. 17 of those refunds are pure theft from the shared pool; the 18th returns the attacker's own stake. The attacker's profit is exactly (N_successful_refunds − 1) × 0.6 BNB = 17 × 0.6 = 10.2 BNB.

Preconditions#

• The attacker holds a small amount of BNB to seed one slot. In the PoC, deal(attacker, 0.6 ether) (test/unverified_35bc_exp.sol:27).
• The contract custodies enough pooled BNB to be worth draining — ≈10.6 BNB at the fork block.
• The attacker controls the depositing/withdrawing address (a contract with a fallback() that re-enters). The PoC's HelperB (test/unverified_35bc_exp.sol:65-91) serves this role and is the real attack contract 0x0A2f…3Ce5.
• No reentrancy guard exists on releaseSlot — satisfied by the deployed code.

No flash loan, no oracle, no price manipulation is needed; the attack costs one 0.6 BNB deposit plus gas.

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

The numbers below come directly from the Unlock/Release events and the @21 storage-change lines in output.txt. Storage slot 21 is the contract's internal tracked balance; it tracks the native BNB outflow 1:1 with each refund.

Counts from the trace: 19 releaseSlot(3) invocations, 19 HelperB::fallback frames, 1 OutOfFunds → 18 successful 0.6 BNB refunds = 10.8 BNB out of the contract.

Profit / loss accounting (BNB)#

The PoC verifies this end-to-end:

before attack: balance of attacker: 0.600000000000000000
after attack: balance of attacker:  10.800000000000000000

Note on the PoC structure: the reconstructed AttackerC/HelperB in the test file hard-code the recovered total (3 * 10**15 * 3600 = 10.8 BNB) as the amount to forward up the call chain to the attacker EOA, mirroring what the real attack contract did. The exploit itself — the recursive releaseSlot drain — is performed live against the real on-chain contract; only the bookkeeping of forwarding the proceeds is reconstructed.

Diagrams#

Sequence of the attack#

Contract balance evolution (state diagram)#

The flaw inside releaseSlot (control flow)#

Remediation#

1. Apply checks-effects-interactions. Clear slot.active and zero slot.amount (and decrement totalStakeAmount) before sending any BNB. With state cleared first, the re-entrant call fails the require(active) check immediately and refunds nothing extra.
2. Add a reentrancy guard. Mark releaseSlot (and any other value-pushing function such as unstake/harvest) nonReentrant using OpenZeppelin's ReentrancyGuard. This is a one-line defense that would have fully blocked this exploit.
3. Prefer pull-over-push for refunds. Credit the refund to a withdrawable balance and let the user claim() it in a separate transaction, instead of pushing BNB via a low-level call to attacker-controlled code.
4. Bound per-slot payouts to recorded state read after the effect. The refund must be derived from state that has already been decremented, so a double-spend of the same slot is structurally impossible.
5. Account against actual obligations, not a single slot's amount. Even absent reentrancy, a refund function should never be able to pay out more than the slot's recorded deposit; here it paid 0.6 BNB ×18 for one 0.6 BNB deposit.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile under a whole-project forge test build):

_shared/run_poc.sh 2025-02-unverified_35bc_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 46,886,077). The bundled foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block. The default OnFinality public endpoint rate-limited (HTTP 429) and was swapped out.
• Result: [PASS] testPoC() — attacker balance 0.6 BNB → 10.8 BNB (net +10.2 BNB stolen).

Expected tail:

  before attack: balance of attacker: 0.600000000000000000
  after attack: balance of attacker: 10.800000000000000000

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 3.61s (2.83s CPU time)
Ran 1 test suite in 6.29s: 1 tests passed, 0 failed, 0 skipped (1 total tests)

References: TenArmor post-mortem — https://x.com/TenArmorAlert/status/1893333680417890648 . Victim contract is unverified on BscScan; analysis grounded in the deployed bytecode (selectors 0x6a9787bc unlockSlot, 0x2dad6442 releaseSlot), on-chain storage reads, and the live fork trace in output.txt.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2025-02-unverified_35bc_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: unverified_35bc_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

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