Munchables Rogue-Developer Exploit on Blast (Mar 26-27, 2024)

Overview

On March 26-27, 2024, Munchables, a play-to-earn NFT game built on the Ethereum layer-2 Blast, was exploited for approximately $62.5 million in ETH, but the incident is most notable for two things: the attacker was an insider, a developer Munchables had hired who had built the very vulnerabilities into the project's contracts, and within roughly a day the attacker returned all of the stolen funds with no ransom paid. On-chain investigator ZachXBT identified the attacker as likely North Korean, noting that the four developers Munchables had hired to build its smart contracts appeared to be a single person, and that the rogue developer (operating under a GitHub handle) had embedded the means of the exploit during development. The mechanism leveraged the project's upgradeable-contract design: the rogue developer, with privileged control, manipulated the contract to assign themselves an enormous balance (reported as 1 million ETH in the contract's accounting) and then, around a contract upgrade, transferred roughly $62.5 million of real user ETH to their own wallets. The attack triggered an emergency response across the Blast ecosystem, including the disabling of third-party Blast bridges to contain potential outflows. Then, under pressure and negotiation, the attacker handed over all the relevant private keys, allowing the full recovery of user funds. Munchables is the canonical insider-developer case study: it shows that a project's own developers, especially anonymous, externally-hired ones, can be the threat actor, that upgradeable-contract privilege is a loaded weapon, and that even a fully-recovered hack carries severe lessons about hiring, key control and the DPRK-IT-worker infiltration threat.

Timeline of events

In the early hours of Wednesday, March 27, 2024 (UTC), Munchables, a game on the Blast L2, suffered an exploit that drained approximately $62.5 million in ETH. On-chain monitors and ZachXBT flagged the outflow rapidly, and ZachXBT publicly identified the attacker as likely North Korean, pointing out that the several developers Munchables had hired to build its smart contracts appeared in fact to be one individual, and that this rogue developer had built the exploit into the project. The mechanism, detailed below, exploited the developer's privileged control over the project's upgradeable contracts: the attacker had earlier set up the conditions to credit themselves an outsized balance, and when they struck, they transferred the users' stored funds to their own addresses. The incident set off an emergency response across Blast: third-party Blast bridges were disabled to prevent the stolen funds from being moved off the L2 while a resolution was sought, and the Blast core team, including its founder, became involved in pressuring and negotiating with the attacker. Within roughly a day, the situation resolved in an unusual way for a hack of this size: the attacker voluntarily provided all the private keys needed to recover the funds, the keys controlling the ~$62.5M in ETH, additional WETH, and the main owner key, allowing Munchables and the ecosystem to restore user funds in full, with no ransom paid. The outcome, a $62.5M insider exploit fully reversed within a day, is rare and was driven by the combination of the funds being trapped on the L2 and the negotiation pressure brought to bear.

Attack mechanism: the insider with upgrade privilege

The Munchables exploit was not an external attacker finding a bug; it was the project's own developer abusing privileges they had been granted and had deliberately positioned to abuse. Munchables used upgradeable smart contracts, contracts whose logic can be changed by a privileged controller, a common pattern that lets teams fix bugs and add features but that concentrates enormous power in whoever controls the upgrade mechanism. The rogue developer had this privileged control. According to analyses of the incident, the developer manipulated the contract's storage/accounting to assign themselves a balance (reported as 1 million ETH within the contract's internal accounting), positioning a claim far larger than any real deposits. Then, around a contract upgrade, they exercised that position to transfer the real user ETH, about $62.5 million, out to wallets they controlled. Because the developer had legitimate privileged access by design, having built the contracts and held the upgrade/owner keys, there was no perimeter to breach: the threat came from inside the trust boundary. This is the defining feature of the insider-developer exploit and what distinguishes it from external hacks: the audits and perimeter defenses that protect against outsiders are useless against a malicious party who holds the keys legitimately and wrote the code. The upgradeable-contract design, which gave the developer the power to change contract logic and control balances, was the loaded weapon, and the rogue developer was holding it the whole time.

Root cause analysis and the DPRK-IT-worker threat

The root cause has two layers: a governance/key-control failure and a hiring/personnel failure that maps onto the broader DPRK IT-worker infiltration threat. On the technical/governance side, the project concentrated upgrade and owner privileges in a single externally-hired developer with no effective check, no multisig requiring independent co-signers for upgrades or fund movements, no timelock that would have surfaced the malicious upgrade before it executed, and no segregation ensuring that the person who wrote the contracts could not unilaterally move user funds. Any of these controls would have blunted the insider's ability to act alone. On the personnel side, the deeper root cause is that Munchables hired anonymous developers without sufficient vetting, and those developers, per ZachXBT, were apparently a single person likely connected to North Korea. This is the now-well-documented DPRK IT-worker threat: North Korean operatives obtaining remote development jobs at crypto projects under false or multiple identities, then either collecting salaries to fund the regime or, as here, exploiting their privileged access to steal funds outright. The lesson is that hiring is a security control: the people granted privileged access to contracts and keys are part of the attack surface, and inadequate vetting of anonymous developers, especially those given upgrade or owner authority, is a direct path to an insider exploit. Munchables is a clean illustration that decentralization and audits do not protect against a malicious insider who was trusted by design.

Response, recovery and why it was returned

The response was fast and ecosystem-wide, and the recovery was, unusually, complete. As the exploit was detected, the Blast ecosystem moved to contain it: third-party Blast bridges were disabled to prevent the stolen funds from leaving the L2, which is a critical factor in the eventual recovery, because the funds being trapped on Blast limited the attacker's exit options and strengthened the negotiating position of the defenders. The Munchables team and Blast leadership, including the founder, engaged the attacker directly. Under that pressure, and likely calculating that the funds were difficult to extract and that returning them was preferable to the risk and scrutiny of attempting to launder a high-profile, closely-watched $62.5M, the attacker agreed to return everything: they handed over the private keys controlling the ~$62.5M in ETH, the additional WETH, and the main owner key, enabling Munchables to recover all user funds with no ransom paid. This outcome, a full, voluntary return, is rare for a hack of this scale and stands in contrast to the typical DPRK-linked theft (DMM, Bybit, Radiant) where funds are laundered and never returned. The likely explanation is the specific dynamics here: an insider whose identity and methods were rapidly exposed by ZachXBT, funds trapped on an L2 with disabled bridges, and direct negotiation pressure, a combination that made return the attacker's least-bad option.

Industry implications and verdict

Munchables is the canonical insider-developer case study, and its lessons are distinct from external-hack post-mortems precisely because the threat came from inside the trust boundary. First, hiring is a security control: granting anonymous, unvetted developers privileged access to contracts and keys is a direct insider-exploit risk, and the DPRK IT-worker infiltration threat, operatives obtaining remote dev jobs at crypto projects, is real and active. Projects must vet the people they grant privileged access to with the same rigor they apply to auditing code. Second, upgradeable-contract and owner privileges are loaded weapons that must never be concentrated in a single party: upgrades and fund movements should require multisig with independent co-signers, timelocks that surface changes before they execute, and segregation so the contract author cannot unilaterally move user funds. Third, the recovery, full and voluntary, shows the value of ecosystem-level containment (disabling bridges to trap funds on the L2) and of rapid public attribution (ZachXBT's identification) in changing an attacker's calculus, though relying on an attacker's goodwill is never a strategy. Fourth, even a fully-recovered hack is a severe warning, not a non-event: it exposed the insider-threat and inadequate-vetting failure modes that, in a less contained setting, would have meant a permanent $62.5M loss. The verdict is that Munchables belongs in the record as the definitive rogue-developer/insider case and a key data point in the DPRK-IT-worker threat that connects to the broader pattern of North Korean targeting of crypto, here from the inside rather than the outside.

Recovery

Full recovery: third-party Blast bridges were disabled to trap the funds on the L2, the Munchables team and Blast leadership negotiated with the attacker, and within ~a day the attacker voluntarily returned all private keys (controlling ~$62.5M ETH, additional WETH, and the main owner key) with no ransom paid. All user funds were restored.

Frequently asked questions

Related

• Coinbase Insider Data Breach and Extortion (May 2025)
• PlayDapp Minting Exploit (Feb 9-12, 2024)
• Radiant Capital Multisig/Device Compromise (Oct 16, 2024)
• DMM Bitcoin Hack and Shutdown (May 31, 2024)
• blast