Crypto Trainingblogweb3 security engineering
<- Back to hacks

Reproduced Exploit

Fake staking pool is accepted by stakeNxm — AuditVault synthetic reduction

This bug report discusses a vulnerability found in the stNXM contract, which allows the contract owner to steal funds from the contract. The bug was found by multiple individuals and can be exploited by passing a fake staking pool address to the _stakeNxm() function and setting the owner as the fee…

Aug 2025•Other•access-control•4 min read

Chain

Other

Category

access-control

Date

Aug 2025

Source

AuditVault

PoC & write-upPoC for your local evm-hack-analyzerAuditVault PoCs

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. Reproduction of a public audit finding curated by AuditVault — the original finding: 64082-h-4-owner-can-steal-funds-from-contract-by-calling-stakenxm. Standalone Foundry PoC and full write-up: 64082-h-4-owner-can-steal-funds-from-contract-by-calling-stakenxm_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/access-control/missing-auth · vuln/dependency/unsafe-external-call

Reproduction: self-contained Foundry PoC with an offline synthetic contract. Full trace: output.txt.

AuditVault finding: 64082 · H-4: Owner can steal funds from contract by calling stakeNxm() with fake pool address

Key info#

ImpactHIGH — Fake staking pool is accepted by stakeNxm
Protocol[[stETH]] by EaseDeFi
FindingAuditVault #64082
Reporthttps://github.com/sherlock-audit/2025-11-stnxm-by-easedefi-judging
SourceAuditVault finding
Compiler^0.8.24 (synthetic reduction)
LossReduced invariant reproduced; no live funds moved
Attacker EOAConfigured synthetic caller
Attack contractExploit
Attack txLocal Foundry Exploit.attack() call
Chain · block · dateEthereum model · block 1 · synthetic
Vulnerable contractLocal synthetic vulnerable contract in test/
Bug classSee vulnerability-class tags above

TL;DR#

This bug report discusses a vulnerability found in the stNXM contract, which allows the contract owner to steal funds from the contract. The bug was found by multiple individuals and can be exploited by passing a fake staking pool address to the _stakeNxm() function and setting the owner as the fee beneficiary. This allows the owner to inflate rewards and withdraw all funds from the contract. The root cause of the bug is that the owner can pass any address to the _stakeNxm() function without validation. The impact of this bug is that the owner can steal funds from the contract. The protocol team has fixed this issue in a recent commit. To mitigate this issue, it is recommended to ensure that the pool address is valid in the _stakeNxm() function.

Background#

The upstream report is a Solidity finding. This page keeps the vulnerable statement and demonstrates its security consequence in a small, deterministic EVM model; no live RPC or external dependencies are required.

The vulnerable code#

SOLIDITY
// The exact vulnerable pattern is retained in test/64082-h-4-owner-can-steal-funds-from-contract-by-calling-stakenxm.sol.
// @> see the marked statement in the synthetic reduction

Root cause#

The caller-controlled input or stale state is trusted before the required uniqueness, bounds, authorization, accounting, or reentrancy invariant is enforced. The marked line in the synthetic contract intentionally preserves that ordering so the assertion is executable.

Preconditions#

  • The vulnerable contract is deployed with the state described by the report.
  • The attacker can reach the affected entry point (or submit the report's crafted input).

Attack walkthrough#

  1. Exploit.run() initializes the minimal state from the report.
  2. The marked vulnerable operation executes without its required check.
  3. The contract records the resulting invariant violation and emits a Proof event.
  4. The test asserts the harm; the passing trace is recorded at output.txt:4.

Diagrams#

flowchart TD A[Attacker supplies crafted input] --> B[Vulnerable operation] B --> C{Missing invariant check} C --> D[Security impact demonstrated]
sequenceDiagram participant A as Attacker participant V as Vulnerable contract participant S as State A->>V: invoke affected entry point V->>S: apply unchecked update S-->>A: harm is observable

Remediation#

Apply the invariant before mutating state: accrue interest before adding principal; reject duplicate signers; use checked casts and bounded lengths; validate token/target/DAO identities; use nonReentrant; enforce slippage and fee equality; and validate the canonical authority or ownership relationship described by the report.

How to reproduce#

BASH
cd evm-hack-registry/64082-h-4-owner-can-steal-funds-from-contract-by-calling-stakenxm_exp
forge test -vvvvv

The test is offline and uses only the shared forge-std library. The corresponding Playground bundle is generated from scripts/poc-configs/64082-h-4-owner-can-steal-funds-from-contract-by-calling-stakenxm.mjs.

Sources#

Reference: https://github.com/sherlock-audit/2025-11-stnxm-by-easedefi-judging

Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

  • 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.