~$88M Lost: COLDCARD & LULA Exploits

During the past week (2026/07/27 - 2026/08/02), the following 2 notable security incidents are featured, together accounting for roughly $88M in losses.

Date	Incident	Type	Estimated Loss
2026/07/29	LULA	Business Logic Flaw	~$578K
2026/07/30	COLDCARD	Flawed Entropy Generation	~1,370 BTC (~$88M)*

* COLDCARD's loss varies by confirmation method: the ~1,370 BTC (~$88M) shown is the publicly verifiable on-chain minimum (coldcardwatch.com); private-channel reconciliation (Galaxy Research, from correspondence with 73 victims) puts it higher, at roughly 1,596 BTC and up to ~2,055 BTC (~$130M) once suspected-but-unconfirmed drains are included.

Reasons for selection

LULA: A privileged token function that can move an AMM pair's balances and force a reserve resync becomes a repeatable liquidity-drain primitive through price manipulation.
COLDCARD: A build-and-integration error in wallet firmware silently routed seed generation through a deterministic software fallback, undermining entropy guarantees and turning seed recovery into an offline search that escalated into large-scale fund loss.

Weekly Highlight: COLDCARD

We selected COLDCARD as this week's highlight because a wallet entropy bug produced the largest loss of the period. The root cause, a build guard that checked whether a configuration macro existed instead of whether it was enabled, is the kind of silent integration error that functional testing cannot catch, and the lesson applies to any system where on-chain security depends on off-chain randomness.

COLDCARD, a Bitcoin hardware wallet, shipped firmware in 2021 that generated wallet seeds using a deterministic software source instead of the intended hardware random number generator (RNG) [1][2]. The flaw was not exploited at scale until late July 2026, when affected wallets were swept in on-chain waves beginning 30 July: publicly confirmed losses total at least 1,370 BTC (~$88M, at the $64,099 price on 5 Aug) [3], while privately confirmed reports put the figure as high as about 1,596 BTC [4]. The root cause was a build-and-configuration error that routed seed generation onto a software fallback instead of the intended hardware RNG. For affected devices, this turned seed recovery from a cryptographically infeasible problem into an offline search.

Background

COLDCARD is a Bitcoin hardware wallet. A wallet's private keys and addresses are all derived from a single secret value, its seed, so the security of any self-custody wallet rests on two properties of that seed: that it stays secret, and that it is unpredictable when generated. Hardware wallets exist largely to protect the first; this incident is a failure of the second. A BIP-39 seed phrase is human-readable, but the security property underneath the unpredictability requirement is still the entropy of the random bytes used to create it. If those bytes can be reproduced, the seed can be reproduced. The intuition is a safe whose combination is chosen by rolling dice: if the dice are loaded, the safe stands open to anyone who knows the bias, no matter how strong the lock.

For a wallet, "loaded dice" means a weak random number generator. Hardware wallets are expected to draw seed entropy from a hardware true-random-number generator (TRNG) on their secure microcontroller, because a software pseudo-random generator (PRNG) is deterministic: given its internal state and call history, its output can be replayed exactly. If the generator's outputs are predictable, its candidate range can be enumerated and matched against public wallet data such as an address, an xpub, or a public key, which collapses seed recovery from a cryptographically infeasible problem into an offline search.

COLDCARD's firmware exposed two separate RNG surfaces. MicroPython shipped an STM32 platform layer that exposed the global rng_get() symbol the wallet's crypto library expected, while COLDCARD also maintained its own board-local hardware-RNG wrapper. Both surfaces are intended to supply hardware entropy, and the wallet's crypto library reaches one of them through a single global RNG symbol resolved when the firmware is built.

Vulnerability Analysis

The root cause was a build-and-integration error around the MICROPY_HW_ENABLE_RNG configuration macro. COLDCARD's production board configuration set this macro to 0, because the firmware intended to use its own board-local hardware-RNG wrapper rather than MicroPython's hardware-RNG implementation. However, the wallet-generation path had been migrated to ngu.random.bytes(32), and the crypto library's STM32 path ultimately depended on the global rng_get() symbol resolved by MicroPython.

The problem chain was:

generate_seed()
  -> ngu.random.bytes(32)
  -> libngu CHIP_TRNG_32()
  -> rng_get()
  -> MicroPython STM32 RNG module
  -> Yasmarang software fallback because MICROPY_HW_ENABLE_RNG == 0

The board configuration disabled MicroPython's hardware-RNG branch:

// We have our own version of this code.
#define MICROPY_HW_ENABLE_RNG (0)

The crypto library still treated the macro as sufficient proof of a hardware RNG [5], because it checked only whether the macro existed before calling rng_get():

extern uint32_t rng_get(void);
#define CHIP_TRNG_32() rng_get()

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

That guard misses the dangerous case: a macro defined as 0 is still defined, so the #ifndef check passes and the build succeeds. Because MicroPython selects its RNG implementation by the macro's value rather than its existence, MICROPY_HW_ENABLE_RNG == 0 routed rng_get() onto the software fallback branch instead of COLDCARD's board-local wrapper [6]:

#if MICROPY_HW_ENABLE_RNG
    // STM32 hardware RNG
#else
    // Yasmarang software fallback
#endif

The consequences differ by device generation. For Mk2/Mk3 firmware v4.0.0-v4.1.9, Block's analysis [7] states that no cryptographic entropy was added to ngu.random, so wallet generation can become deterministic once the fallback state and call history are known (Coinkite's advisory [2] scopes the Mk2/Mk3 range slightly more narrowly, as v4.0.1-v4.1.9). For Mk4/Q/Mk5, secure-element material was hashed but only four bytes were passed into ngu.random.reseed(), limiting the secure reseed to a single 32-bit state word, far less effective search space than the wallet entropy users expect. Hashing the final 32 random bytes cannot increase the entropy of the result; it only transforms an already-limited candidate set.

Attack Analysis

Unlike a smart-contract exploit, this incident has no single on-chain attack transaction to trace. It was an offline seed-recovery problem followed by on-chain sweeps. The precondition was that affected users had generated their wallet seeds through the vulnerable ngu.random.bytes(32) path, so their seed material depended on a reproducible software-fallback state rather than full hardware entropy. A second, inferred precondition is that the affected wallets were derivable from the seed alone: a strong, unique BIP-39 passphrase mixes in independent, user-supplied entropy through PBKDF2 that the RNG flaw never touched, placing such wallets outside pure seed enumeration, and the scale of the sweeps suggests most affected users had set no such passphrase. From there, the recovery likely proceeded in three steps:

The attacker constrained or enumerated candidate RNG states using device metadata, boot timing, RTC/SysTick assumptions, and plausible RNG-call history.
For each candidate state, the attacker derived candidate wallet seeds and checked them offline against public wallet data such as addresses, xpubs, or generated public keys.
Once a candidate matched a real wallet, the attacker recovered the seed, reconstructed the private keys, and swept the associated BTC.

On-chain, the theft appeared as a burst of address sweeps beginning on 30 July. Independent on-chain heuristic tracking [3] identifies several drain waves totaling at least 1,370 BTC (approximately $88M, valuing the coins at the $64,099 5 Aug BTC price) swept from 4,580 verified addresses, a verified minimum rather than a total. Meanwhile, a private channel [4], confirmed through correspondence with 73 victims, puts the figure as high as roughly 1,596 BTC, rising toward 2,055 BTC (~$130M) once suspected-but-unconfirmed drains are added.

Conclusion

The COLDCARD incident was an entropy-generation failure: the security-critical seed-generation API silently resolved to a deterministic software PRNG fallback instead of the intended hardware RNG, because a build guard checked whether a configuration macro existed rather than whether it was enabled. For affected devices, this turned seed recovery from a cryptographically infeasible problem into an offline search, and the result was more than 1,370 BTC [3] swept across multiple waves (private-channel tallies put it at roughly 1,596 to 2,055 BTC [4]).

The core engineering failure is that the shipped firmware never proved that its most security-critical API actually reached the intended hardware RNG. Three practices would have caught it: build guards for cryptographic entropy must check both macro existence and macro value; entropy fallbacks must fail closed rather than silently substitute a software PRNG; and verification of the final firmware image should cover symbol provenance and end-to-end entropy flow, not just that the code compiles. An affected seed cannot be fixed in place; its funds should be moved to a wallet created on fixed firmware, and a strong, unique passphrase reduces immediate exposure without repairing the seed [2].

The failure mode is worth underlining: randomness bugs of this kind are invisible to functional testing because every generated seed is individually valid. The defect lies not in any single output but in the source that produced them: because that source is predictable and reproducible, the seeds collectively fall into a small, enumerable range. Off-chain key-generation components deserve first-class security scrutiny.

References

More Incidents This Week

LULA

LULA, a BEP-20 token on BNB Chain, lost approximately $578K on 29 July 2026 to a business-logic flaw in its token contract. An attacker-reachable path could trigger its privileged recycle() function, letting the Rental contract transfer LULA directly out of the PancakeSwap V2 pair and then call sync(), updating the pair's reserves to the manipulated balances. The attacker repeatedly triggered recycle() to shrink the pair's LULA reserve close to zero, then swapped a small amount of LULA back for nearly all of its USDT [1].

Background

LULA is a BEP-20 token on BNB Chain with a rental-based team-reward mechanism. Eligible addresses accrue pending team rewards in a Rental contract and claim them through claimTeamReward(). During the claim flow, the Rental contract calls the token's recycle() function to obtain LULA for reward distribution. recycle() is not callable by arbitrary users; only the Rental contract is authorized to execute it.

The claimTeamReward() entrypoint contains an "EOA only" check. It supports direct calls from externally owned accounts where msg.sender == tx.origin, and it also supports EIP-7702 delegated calls by inspecting the delegated-code prefix.

On an automated market maker (AMM), a pair prices swaps from its stored reserves, and those reserves are updated through the pair's sync() function, which sets them to the pair's current token balances. Reserves normally track genuine trading because they move with swaps and liquidity events, but a pair's token balance can also be changed by a direct transfer, and sync() copies whatever balance is present, manipulated or not, into the stored reserves.

Vulnerability Analysis

The root cause was that LULA.recycle() allows the Rental contract to transfer LULA directly out of the PancakeSwap V2 pair and then call sync(), updating the pair's reserves to the manipulated balances [1].

Because sync() sets the reserves to whatever LULA balance remains in the pair, this privileged path can drive the pair's LULA reserve arbitrarily low while leaving the USDT side untouched. Once the LULA reserve is close to zero, the pair prices a small amount of LULA as worth nearly all of its USDT.

Attack Analysis

The following analysis is based on the transaction 0xa219ab9...411d7c.

Step 1: The attacker funded the manipulation by accumulating ~197.05M USDT. The funds came from multiple flash-loan and borrow sources, including Moolah/Lista, Aave V3, Venus, PancakeSwap V3, PancakeSwap Vault, Uniswap V4 PoolManager, and Uniswap V3.
Step 2: The attacker used the ~197.05M USDT to perform a large USDT -> LULA swap through the PancakeSwap V2 router. This sharply reduced the pair's LULA reserve from about 8M LULA to 24,022 LULA, while increasing the USDT side to roughly 197.64M USDT.
Step 3: The attacker invoked the reward path through multiple EIP-7702 wallets. Each wallet called claimTeamReward() on the Rental contract, which then triggered LULA.recycle(), shrinking the pair's LULA reserve from 24,022 LULA to 0.004 LULA while the pair still held a very large USDT side.
Step 4: The attacker routed a final PancakeSwap V2 swap through the router, sending only ~4,749 LULA into the pair and receiving ~197.64M USDT out.
Step 5: The attacker repaid all flash loans, profiting approximately $578K.

Conclusion

The LULA token on BNB Chain was exploited for approximately $578K through a business-logic flaw in its token contract: an attacker-reachable path could trigger its privileged recycle() function, letting the Rental contract transfer LULA directly out of the PancakeSwap V2 pair and then call sync(), resynchronizing the pair's reserves to the manipulated balances. The attacker repeatedly triggered this to skew the pair's price and swap a small amount of LULA back for nearly all of its USDT.

A token contract should never expose a privileged path that can move an AMM pair's balances and force a reserve resync, because doing so hands price control to whoever can reach that path. Tokens that integrate with AMM pairs must keep the pair's reserves bound to genuine, market-driven balance changes, and any logic that reads pool reserves for pricing should treat them as manipulable rather than authoritative.

References

[1] BlockSec Phalcon's analysis of the LULA exploit

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.