On October 22, 2026, CertiK Alert flagged an ongoing attack against NEM — contract NemTokenV2 — on BNB Chain, with the loss estimated around $820,000. SlowMist’s review pinned the number at $821,920, and Wu Blockchain and Foresight News relayed the breakdown within hours.
First, the disambiguation that matters for searchers and victims alike: this NEM is a BNB Chain token, not the older NEM/XEM blockchain. The attacked asset was the USDT/NEM liquidity pair on PancakeSwap.
What the NemTokenV2 Bug Actually Was
The vulnerable mechanism is a sell-tracking feature called pendingLpSellRecycle. Its job was to watch NEM flowing into the liquidity pair and account for it as sell-side pressure — the kind of “smart tokenomics” hook that small-cap projects bolt on to manage price.
The flaw is almost boring in its simplicity: the contract treated every transfer of NEM into the pair as a completed sell, without verifying that a real swap had actually settled. Transfer-in and trade-execution are two very different events; NemTokenV2 conflated them.
A PancakeSwap pool keeps its own internal record of reserves. When the pool’s actual balance exceeds that record, anyone can call skim() to extract the difference. That is normal AMM hygiene — safe as long as nothing can artificially create the surplus.
NemTokenV2’s bug did exactly that, on demand. Per SlowMist’s analysis, the attacker’s loop was:
- Transfer NEM into the USDT/NEM pair.
skim()— pull out the excess the pool now holds over its recorded reserves.flushLpSellRecycle()— let the contract’s parallel ledger write the phantom “sell” down, dragging its records lower in step with the drained pool.
Repeat forty-two times. Every cycle pulled real value out and shrank the recorded reserves — which, as a side effect, kept pushing the NEM price up. When the pool was drained enough, the attacker sold the remaining NEM into the artificially inflated price, netting roughly 821,920 USDT. Reporting indicates the proceeds were then bridged onward to Ethereum.
The Pattern: Custom Token Logic Meeting AMM Pools
The uncomfortable lesson is where the bug lived. The PancakeSwap pair did nothing wrong — it followed its rules exactly. The vulnerability was the token contract reaching into pool mechanics and maintaining a parallel account of its own.
This is not a one-off. As security reporting noted in the aftermath, 2026 has already produced a run of same-family incidents on BNB Chain — Movie Token, ATM, LULA — where tokens with elaborate transfer taxes, sell-recycling, or reward-redirect logic interacting with PancakeSwap pools were drained through their own custom code paths. The shared ingredient is always the same: a token contract that infers trader intent from where tokens moved instead of verifying what actually happened in the swap.
What It Means for Holders and Liquidity Providers
For LPs in the USDT/NEM pair, the loss is direct — the pool was drained. For holders, the attack window’s artificial price spike creates a second trap: any “recovery” trade during the manipulation executed against fake prices.
The broader takeaway for anyone trading small-cap tokens on BNB Chain:
- Verified source is table stakes, not safety. A verified contract with custom pool hooks can still carry exactly this class of bug. What matters is whether anyone audited the pool-interaction logic specifically — often nobody did.
- Complex tokenomics are an attack surface. Every “auto-sell,” “sell-recycle,” or tax-redistribution feature is custom code that runs against your money. Our BNB Chain token safety guide walks the checks that surface this class of risk before you buy.
- The same verification stack applies across chains. The token address verification playbook covers how each of those checks gets bypassed in practice — including name-and-ticker collisions like a random BSC token calling itself NEM.
For developers, the fix pattern is blunt: never infer swaps from transfer events into a pair. Verify settlement through the router’s callbacks, or don’t build the feature at all. NEM’s attacker ran the same three-step loop forty-two times and the contract never once asked whether a trade had actually happened.
Frequently Asked Questions
Is the hacked NEM token the same as the NEM (XEM) blockchain?
No. The hacked contract is NemTokenV2, a token on BNB Chain traded against USDT on PancakeSwap. It is unrelated to the older NEM blockchain and its XEM coin, despite sharing the name — a reminder that ticker collisions are themselves a scam-and-confusion surface.
Was the NEM hack caused by a PancakeSwap vulnerability?
No. The PancakeSwap pool behaved exactly as designed. The flaw lived in the NEM token contract: its pendingLpSellRecycle sell-tracking mechanism recorded any token transfer into the pool as a sell, without verifying that an actual swap had settled. The attacker simply manufactured the condition the contract wrongly assumed.
How did the attacker turn an accounting bug into $821,920?
Each cycle: transfer NEM into the USDT/NEM pair, call skim() to pull out the excess the pool now holds over its internal record, then call flushLpSellRecycle() so the contract's parallel ledger writes the fake 'sell' down. Forty-two loops drained real reserves while shrinking the recorded ones — which also inflated the NEM price — and the attacker sold the remainder at that inflated price for about 821,920 USDT.
What does this mean for people holding tokens with tax or sell-tracking mechanics?
Treat any token whose contract hooks custom logic into AMM pool interactions as higher-risk infrastructure, not just higher-tax trading. Before providing liquidity or holding size, check whether the contract is verified, whether audits covered the pool-interaction logic specifically, and run the checks in our token safety guides. Complex tokenomics are an attack surface, not a feature.