stNXM by EaseDeFi — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for stNXM by EaseDeFi, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 7
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 7 closed, publicly disclosed stNXM by EaseDeFi reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Access control, Logic error, Oracle manipulation, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Access control findings disclosed against stNXM by EaseDeFi
- Logic error findings disclosed against stNXM by EaseDeFi
- Oracle manipulation findings disclosed against stNXM by EaseDeFi
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
stNXM by EaseDeFi: The vault can be drained
stNXM by EaseDeFi is a staking vault whose owner-only stakeNxm() function lacks validation of the requested staking NFT tokenId. Because stakeNxm() executes from the vault contract, the underlying depositTo() call passes address(this) as msg.sender, so a malicious admin can stake vault-owned wNXM assets into an NXM staking NFT that the admin still personally owns. The admin can later withdraw that stake from Nexus, effectively siphoning vault funds, while the vault's internal accounting (tokenIdToPool, tokenIdToTranches, stakedNxm(), totalAssets()) incorrectly treats the position as vault-controlled, inflating reported assets and risking insolvency.
stNXM by EaseDeFi: Admin fees are applied to NMX tokens during migration
During the controlled migration of NXM tokens from the legacy arNXM contract into the newly deployed stNXM contract, the protocol's staging steps pause the new contract while funds are transferred, then later call initializeExternals. Because the `update()` modifier computes admin fees whenever the contract's wrapped NXM balance exceeds `lastBalance`, anyone (or the owner) can call a non-paused function such as `resetTranches` during that window when `lastBalance` is still zero and `stakedNxm()` returns zero, thereby triggering adminFees on the entire migrated balance. This unfairly shaves a percentage off every migrated user's tokens before external initialization completes, causing a direct economic loss. The fix gates the fee accrual on `staked != 0` and was applied by the EaseDeFi team.
stNXM by EaseDeFi: Missing Uniswap V3 cardinality initialization in `StNxmOracle` leads to permanent Denial of Service
The StNxmOracle contract prices stNXM from a 30-minute Uniswap V3 TWAP, but its constructor only stores the pool address and never grows the pool's observation buffer. Newly initialized Uniswap V3 pools keep a default observationCardinality of 1, which holds only the current block, so OracleLibrary.consult requests for 1800 seconds of history always revert. Every price() call therefore fails and the oracle is unusable, bricking the Morpho lending markets that depend on it for collateral valuations until an external actor manually raises the cardinality. The root cause is an initialization gap in the constructor: it must call increaseObservationCardinalityNext (e.g., 100 slots) before the oracle is used. This was a Sherlock medium finding fixed by the protocol team in commit 98c0058.
stNXM by EaseDeFi: Attacker can profit by manipulating Uniswap liquidity.
stNXM by EaseDeFi is a wNXM staking-era ERC-4626 vault that owns Uniswap V3 liquidity, and its exchange rate is computed from the spot price read via Uniswap's slot0(). Because slot0() reflects instantaneous, single-block price, an attacker can borrow wNXM via flash loan, swap it into the pool to inflate the reported DEX balance in totalAssets() while simultaneously reducing the virtual shares counted in totalSupply(), spiking the share price. A user whose withdrawal was already queued then finalizes it at the inflated rate, capturing far more wNXM than owed at the expense of remaining stakers, then reverses the pool swap and repays the flash loan for a net profit. The protocol team accepted the report and fixed it by replacing slot0() with a time-weighted average price over a 30-minute window.
stNXM by EaseDeFi: Missing Tranche Tracking After `extendDeposit()` Causes Temporary Asset Underreporting
stNXM by EaseDeFi wraps Nexus Mutual staking positions and tracks each token's tranches in a `tokenIdToTranches` mapping so `totalAssets()`/`stakedNxm()` can query Nexus for the correct deposit amounts. The `extendDeposit()` function moves a position between tranches but fails to push the new tranche into that mapping. As a result `stakedNxm()` queries only the old (now-empty) tranche and never the new one, so `totalAssets()` underreports vault assets — down to zero if the entire position was moved — until someone permissionlessly calls `resetTranches()` to repair the mapping. Because shares are minted against the understated asset base, a depositor in that window could receive an inflated share count and later redeem at the corrected price, extracting excess value. The flaw is purely an internal state-tracking error, not an access-control issue, and the medium ruling is consistent with its temporary, owner-preconditioned nature.
stNXM by EaseDeFi: Owner can steal funds on withdraw by burning wrong Uniswap V3 position liquidity
The stNXM contract's decreaseLiquidity() owner function accepts an arbitrary Uniswap V3 tokenId without verifying that the position belongs to the wNxm/stNxm pool. Because the contract burns the collected stNXM amount against the total share supply, an owner can mint a position in a custom pool, transfer it into the vault, and call decreaseLiquidity() to burn vault-held shares belonging to other users' pending withdrawal requests. This inflates the per-share value of remaining supply, lets the owner withdraw more assets than entitled, and blocks other users' withdrawals since their shares were already burned.