A Missing Reentrancy Guard Let an Attacker Drain GemPad's Token Locker Across Three Chains
An ordinary night across Ethereum, BNB Chain, and Base turned into a scramble when roughly $1.9 million in tokens locked through GemPad's platform was withdrawn without authorization.
A cluster of projects — including BPay, Munch Protocol, and Nutcoin — found the liquidity they had placed in GemPad's lock contracts disappearing, a direct result of one of DeFi's oldest and most recognizable bug classes: reentrancy.

GemPad acknowledged the breach quickly and began coordinating with affected teams, but by then the drained liquidity had already moved across multiple chains.
01Discovery and confirmation
OKLink's team was the first to notice the pattern: several protocols losing liquidity through what appeared to be the same underlying flaw. Their review traced the problem to GemPad's lock contract, which lacked reentrancy protection on its withdrawal function — a gap that left locked assets exposed to repeated, unauthorized withdrawal calls.
GemPad confirmed the exploit shortly afterward, acknowledging that its lock mechanism had been compromised and stating it was working with security partners to investigate. Cyvers Alerts subsequently verified the scope of the incident, tracking the attacker draining one lock contract after another across chains.
A technical breakdown from pennysplayer identified the specific weakness: a reentrancy vulnerability in the collectFees function. The attacker deployed malicious tokens engineered to trigger callback execution during transfers. This let them effectively create liquidity-provider locks at no real cost, and with each reentrant call during the process, withdraw the locked LP amount again — turning the lock mechanism meant to secure funds into the tool that emptied them.
02On-chain details
Attack transactions were tracked by Blocksec.
The same attacker address appeared on all three affected chains: 0xFDd9b0A7e7e16b5Fd48a3D1e242aF362bC81bCaa on Ethereum, the identical address on BSC, and again on Base.
The attack contract was likewise deployed at the same address across chains: 0x8e18Fb32061600A82225CAbD7fecF5b1be477c43 on Ethereum, on BSC, and on Base.
Some of the stolen funds remained on Base at the time of reporting, while the remainder had already been routed through a mixing service, following the familiar path of on-chain funds disappearing into obfuscation tools.
03Projects affected
The list of impacted protocols grew fast. BPay and Munch Protocol both saw their liquidity drained, while AnonFi suspended all token trading in response.
Nutcoin's team publicly sought answers after its locks were emptied, and FOMO Network's pools were drained with no ability to intervene. The Law of Attraction Coin and Hemera Trading AI both moved to reassure their communities, and Dub Token felt secondary effects through its exposure via Alien Base's ALB/DUB liquidity farm.

04Where the security model broke down
The irony is that GemPad marketed itself around accessible, low-friction security. Its no-code token creation system offered five pre-audited templates, ranging from Simple to Ultimate tier, each carrying a sign-off from ContractWolf. Projects could launch a token without writing any code, relying entirely on the platform's underlying infrastructure for safety.
That model broke down once the shared lock mechanism itself contained the flaw. Pre-audited templates and no-code deployment count for little when the underlying contract everyone depends on has a missing safeguard — a single point of failure that let one vulnerability cascade into losses for numerous unrelated projects simultaneously.
05Takeaway
This incident is a reminder that relying on a third-party platform for security does not eliminate the need for that platform to get the fundamentals right. GemPad responded quickly and pledged to work with the affected projects, but the episode illustrates how a single missing reentrancy guard in a shared lock contract can cascade into losses across an entire ecosystem of dependent protocols, regardless of how each individual project was audited or built.
Get new scam files the moment we publish them — usually 2–3 emails a week.