stETH: The (untrusted) vault owner calls stakeNxm to deposit the vault's 1000 NXM into a Nexus st

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 64080-h-2-the-vault-can-be-drained-sherlock-steth-by-easedefi-git. Standalone Foundry PoC and full write-up: 64080-h-2-the-vault-can-be-drained-sherlock-steth-by-easedefi-git_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/theft

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

Root cause#

The (untrusted) vault owner calls stakeNxm to deposit the vault's 1000 NXM into a Nexus staking NFT the owner keeps, then withdraws the stake — draining the vault: vault wNXM/NXM go to 0 and the attacker EOA gains 1000 NXM.

SOLIDITY

        nxm.approve(nxmMaster.getLatestAddress("TC"), _amount);

        IStakingPool pool = IStakingPool(_poolAddress);
        uint256 tokenId = pool.depositTo(_amount, _trancheId, _requestTokenId, address(this)); // @> no `require(stakingNFT.ownerOf(tokenId)==address(this))`: stake is credited to the attacker-owned requestTokenId, draining the vault

        // if new nft token is minted we need to keep track of

Why it's exploitable here#

Attack path#

flowchart TD S0["Seed token-to-pool mapping"] S1["Stake vault NXM into Nexus pool"] S2["Record new staking NFT id"] S3["Load token's tranche list"] S4["Append tranche to token"] H["The (untrusted) vault owner calls stakeNxm to deposit the vault's 1000"] 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 0xaf38a9c57e…:

L307 — Seed token-to-pool mapping: Setup: registers a seed staking NFT and its Nexus pool so the vault can later manage that stake.
L322 — Stake vault NXM into Nexus pool: Root-cause bug: the untrusted vault owner calls stakeNxm to deposit the vault's NXM into a Nexus staking position, then withdraws it and drains the vault.
L328 — Record new staking NFT id: Stores the minted Nexus staking token id — the position the owner later unstakes to pull the NXM out.
L333 — Load token's tranche list: Reads the recorded tranches for this staking token id while bookkeeping the deposit.
L337 — Append tranche to token: Records the tranche the vault's NXM was staked into for this token id.
L353 — Token-to-pool mapping state: Setup: maps each staking NFT id to its Nexus pool.
L354 — Token-to-tranches mapping state: Setup: maps each staking NFT id to the tranche ids its stake covers.

PoC#

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

BASH

cd 64080-h-2-the-vault-can-be-drained-sherlock-steth-by-easedefi-git_exp
forge test -vvv

The browser Playground replays the same synthetic opcode-for-opcode and measures the harm: The (untrusted) vault owner calls stakeNxm to deposit the vault's 1000 NXM into a Nexus staking NFT the owner keeps, then withdraws the stak. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 64080-h-2-the-vault-can-be-drained-sherlock-steth-by-easedefi-git_exp (evm-hack-registry mirror).
AuditVault finding: 64080-h-2-the-vault-can-be-drained-sherlock-steth-by-easedefi-git.
Upstream DeFiHackLabs PoC directory: src/test.

Alerts & third-party analyses

DeFiHackLabs incident explorer: search "stETH: The (untrusted) vault owner calls stakeNxm to deposit the vault's 1000 NXM into a Nexus st".
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.

Source-level debugger — step opcodes and Solidity in sync