An attacker abused a flawed sell-tracking mechanism in the NemTokenV2 contract on BNB Chain, repeating the trick 42 times before bridging funds to Ethereum
Another BNB Chain token has learned that clever tokenomics can turn into an attacker’s playbook. On October 22, 2026, CertiK Alert flagged an exploit targeting the $NEM token, with losses estimated at approximately $820,000.
The attack hit the USDT/NEM liquidity pool on PancakeSwap . The culprit was not a stolen key or a rogue insider, but a logic flaw baked into the token’s own smart contract.
Security firm SlowMist corroborated the findings and put the damage at about $821,920.
The vulnerable code sits in a contract called NemTokenV2. At its center is a mechanism named ‘pendingLpSellRecycle’, which was designed to track and process sells flowing into the liquidity pool.
Per 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, 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.
Daily. Free. Join 34,000+ readers across crypto, finance, and policy.
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 .
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.
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.