An exploit targeting the $NEM token on BNB Chain has resulted in losses estimated at approximately $820,000, according to a CertiK Alert flagged on October 22, 2026. The attack hit the USDT/NEM liquidity pool on PancakeSwap, with security firm SlowMist corroborating the findings and putting the damage at about $821,920.
How the NEM exploit worked
The vulnerable code resides in a contract called NemTokenV2, which included a mechanism named 'pendingLpSellRecycle' designed to track and process sells flowing into the liquidity pool. According to the findings, the contract made a basic accounting mistake: it treated any transfer of tokens into the liquidity pair as sell volume, without checking whether a real sale had actually taken place.
The attacker repeatedly sent NEM tokens into the PancakeSwap pool and then skimmed the excess funds back out. Liquidity pools on PancakeSwap keep an internal record of their reserves. When the actual token balance sitting in the pool drifts above that recorded figure, the surplus can be pulled out. The NEM contract's faulty sell tracking gave the attacker a way to keep manufacturing that surplus on demand.
According to SlowMist, the attacker ran this loop 42 times. Each round chipped away at the pool and distorted its reserves, and the operation also artificially pushed up the token's price along the way. Once enough value had been pulled from the pool, the attacker extracted it and bridged the stolen funds over to Ethereum.
A pattern on BNB Chain in 2026
The NEM incident does not stand alone. The research findings describe a recurring trend in 2026 in which BNB Chain tokens with complex tokenomics have proved vulnerable to reserve manipulation. Earlier in 2026, projects with similar mechanics, including Movie Token, ATM, and LULA, suffered comparable attacks. The shared thread is tokens that bolt custom logic onto their interactions with PancakeSwap pools.
Standard decentralized exchange pools are fairly predictable on their own. Problems tend to show up when a token contract reaches into those pools and tries to keep its own parallel set of books.
What this means for DeFi users and token builders
For anyone holding NEM or providing liquidity to the USDT/NEM pair, the damage is direct. Liquidity providers in a drained pool absorb the losses, and the artificial price movement during the attack adds another layer of disruption for traders who happened to be active at the time.
For developers, the lesson is fairly specific. Any contract that infers user intent from where tokens land, rather than verifying what actually happened in a trade, is making a bet that nobody will game the inference. The NEM attacker won that bet 42 times in a row.
The findings argue that investors may start demanding more transparency from token teams about how their liquidity pool mechanics work. Rigorous audits that specifically test how custom token logic interacts with exchange pools, rather than reviewing the token contract in isolation, would address the exact gap exploited here.
Security firms like CertiK and SlowMist play a growing role in this landscape, often publishing breakdowns within hours of an incident. Their quick alerts help other projects check whether they share the same weakness, though by the time an alert goes out, the funds in question have typically already moved.
