Privileged function in 79AU token contract drained $14.35M from PancakeSwap pool

How the drain unfolded

In early October 2026, a PancakeSwap liquidity pool for the 79AU token, issued by a project called 79thVault, lost $14.35 million in USDT. According to a post-mortem published on dev.to, the theft did not involve a flash loan or a flaw in the exchange's router. Instead, it relied on an administrative capability built into the 79AU token contract itself.

The dev.to write-up reconstructs the timeline: at roughly 07:25 UTC on October 7, an operational wallet linked to 79thVault called a privileged function in the 79AU contract to move tokens directly out of the pool without paying for them. A wallet labeled Seller A then sold those tokens back into the same pool in stages, extracting about $12.6 million in USDT and cutting the pool's stablecoin reserves from $15.2 million to $3.89 million. At 07:41 UTC, a separate batch of 500,000 79AU tokens went to a second wallet, which waited until approximately 12:48 UTC to sell for another $1.75 million. Across nine privileged withdrawals and three receiving wallets, the total loss reached $14.35 million.

The backdoor behind the burn

The project had done the thing DeFi participants are told to look for: 79% of the pool's LP tokens were sent to a burn address, which in PancakeSwap V2 should prevent anyone from redeeming those receipts for the underlying liquidity. But as the dev.to analysis explains, burning LP tokens only blocks the standard redemption path. It does nothing to change the permissions inside the custom token.

The 79AU contract carried an OPERATOR_ROLE that let its holder move tokens from any chosen address and synchronize the pool's reserves, sidestepping the need to redeem LP receipts at all. Security firms cited in the post noted that this function had been called hundreds of thousands of times since June, apparently to run the project's reward system, which helped the malicious withdrawals blend in with routine activity. The role sat behind no multisignature wallet and no timelock, and the contract's source code was unverified on BscScan, so the capability was invisible to anyone doing casual due diligence.

The mechanics were simple once the privilege existed. The pool's pair contract trusted the balances reported by the 79AU token. When the operator moved tokens and the reserves were synced, the attacker could swap tokens that had never been paid for against genuine USDT in the pool.

Aftermath, negotiations and lingering risk

The proceeds were consolidated into BNB. On-chain tracking cited by dev.to showed roughly 14,395 BNB, around $11 million, sitting in a single address, while earlier alerts flagged about 16,200 BNB moved to external addresses.

Recovery talks moved on-chain. The project offered a 10% bounty for the return of the funds; the attacker countered by demanding to keep 25% and asking that legal action be dropped. Because the negotiation message came from the compromised privileged address itself, the post notes, investigators remain split on whether the key was stolen by an outsider or misused by an insider.

The danger also was not fully over. Simulations run by blockchain analytics firm Bitquery at 12:53 UTC on October 8 reportedly identified two addresses still authorized to pull tokens, the original contract deployer and a newly approved wallet, which together could drain about 95% of the pool's remaining 79AU balance.

Why it matters

The incident punctures one of DeFi's most trusted signals. Burned LP tokens guarantee only that liquidity cannot be withdrawn the normal way; they say nothing about mint functions, transfer hooks or privileged roles embedded in the token. Anyone evaluating a token, and any auditor reviewing one, has to examine the token contract's own permissions, not just the exchange infrastructure around it. Where administrative roles are genuinely needed, the dev.to post argues they should sit behind multisignature controls, timelocks or decentralized governance, and contracts should be verified on block explorers so the community can inspect them. A single unprotected key in a custom token can render every other lock on the liquidity irrelevant.