Hardware wallets are built around a simple promise: keep the keys offline, and attackers cannot reach them.
The Coldcard hack broke that assumption.
A flaw made some recovery phrases predictable from the moment they were created, allowing Bitcoin to be stolen while the wallets remained offline and physically protected.
This week, we look at how the incident shook trust in Bitcoin self-custody and pushed some holders back toward exchanges. We then examine the technical failure that made the keys predictable and why updating an affected wallet cannot secure keys that were already created.
Also inside: a self-spreading npm worm, a Metabase zero-day, a macOS Screen Sharing bypass, an exploited LoadMaster flaw, backdoored routers, LLVM for security testing, a suspicious GitHub SSO renewal email and more.
Inside this issue
🌡️ Threat Level: High Alert
⚡ News: Five security stories worth catching up on
🔎 Deep Dive: How the Coldcard Hack Shook Trust in Bitcoin Self-Custody
🎣 Is It a Phish?
🔬 Technical Research: The Wallet Stayed Offline. The Attacker Still Found the Key.
🛠️ Tool of the Week: LLVM
👤 Person of the Week: Andrea Fioraldi
📅 Event of the Week: Ekoparty Security Conference 2026
📚 Book of the Week: Black Hat GraphQL
😅 The Meme
❓ One Question Before You Leave
Let’s dig in.
Before we get into this week’s stories, here’s where the threat level stands.
🌡️Threat level
⚡ News
More than 400 npm packages were turned into a self-spreading worm
ChainDrop infected popular JavaScript packages through stolen publishing credentials. The malware ran during installation, searched developer workstations and CI/CD systems for npm, GitHub, cloud and infrastructure secrets, then used stolen tokens to infect more packages automatically. Microsoft identified more than 400 affected packages. Unit 42 found 453 public GitHub repositories matching the worm’s data-theft patterns and observed its execution across ten environments.
Stolen tokens infect developer and CI systems.
A Metabase zero-day turned password reset into administrator access
Metabase confirmed that attackers exploited a previously unknown SQL injection flaw against its cloud service. The vulnerable password-reset endpoint allowed remote attackers without credentials to gain administrator access, potentially exposing connected database credentials and data. Metabase patched its cloud platform and released fixes for self-hosted versions. Framework, Tally and Kilo Code subsequently reported exposure involving customer contact information, password hashes or Slack access tokens.
Password reset bypass exposes connected databases.
No valid password required: Apple patches a macOS Screen Sharing bypass
Apple disclosed that an attacker on the same network could authenticate to macOS Screen Sharing without valid credentials. The vulnerability, tracked as CVE-2026-65400, worked before authentication and affected systems with Screen Sharing enabled. Huntress found that changing the VNC password or restricting allowed users would not prevent exploitation. Apple addressed the flaw on August 6 in macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9.
Local attacker bypasses Screen Sharing authentication.
CISA gave agencies three days to patch an exploited LoadMaster flaw
CVE-2026-8037 affects Progress Kemp LoadMaster, a product that distributes traffic between applications and servers. The flaw allows a remote attacker without credentials to run operating-system commands through insufficiently checked input sent to the appliance. Progress released fixes for affected versions. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on August 7 and set an August 10 remediation deadline for federal agencies.
Unauthenticated request exploits a vulnerable load balancer.
More than 20 router models shipped with a root-level backdoor enabled by default
VulnCheck found a remote-control implant named ENDLESSDOORS inside routers sold under the Zbtlink and Wiflyer brands. The software contacts external infrastructure and can execute commands with full system privileges without authenticating the server. VulnCheck estimates that at least 100,000 affected routers may be deployed worldwide. On August 6, Zbtlink said the implant was a support tool, suspended affected router sales, removed the firmware and began developing updates.
Built-in implant enables remote router control.
🔎 Deep Dive
How the Coldcard Hack Shook Trust in Bitcoin Self-Custody
Hackers stole around $130 million in Bitcoin from Coldcard hardware wallets, making it the third-largest crypto hack of 2026.
Hardware wallets are built on a simple promise: keep the keys offline, and remote attackers cannot reach them. There is no account to compromise, no server holding the secret and no way in without the recovery phrase or physical device.
The Coldcard theft broke that promise.
The wallets remained offline, but the Bitcoin was still stolen. It exposed a weakness in one of the main tools people rely on for Bitcoin self-custody.
Self-custody means holding the keys to your own Bitcoin instead of leaving that control with an exchange or another company. Hardware wallets create and store those keys offline, where they are supposed to remain beyond the reach of online attackers.
Coldcard was an established Bitcoin-only hardware wallet with a strong reputation for security. Yet a flaw in how some devices generated recovery phrases made their keys predictable from the moment they were created. Attackers could reconstruct those keys and access the funds without defeating the wallets’ physical protections.
So the real question is:
What happens when the device meant to protect self-custody becomes its weakest link?
Self-custody removes the custodian, not trust
People choose self-custody so they do not have to trust an exchange or financial institution with their Bitcoin. But controlling the private keys also means protecting them safely.
Before hardware wallets, this often required paper wallets or computers kept permanently offline. Hardware wallets turned those complicated setups into a dedicated device that created the keys and kept them offline.
This made self-custody practical, but it did not remove trust. It moved that trust from the institution holding the Bitcoin to the manufacturer building the wallet.
Most users cannot verify how their device creates its keys. They have to trust that the manufacturer handled the most important part correctly.
The Coldcard hack made users question self-custody
Coldcard was one of the few established Bitcoin-only hardware wallets. It had become a trusted option among people who wanted to keep their Bitcoin keys offline and outside an exchange.
That reputation made the hack more significant.
Coldcard’s role was not simply to keep those keys offline. Users trusted it to create them securely in the first place. If that step failed without the owner knowing, every protection that followed was built around a vulnerable key.
One victim reported to Galaxy Research that his Coldcard had remained inside a bank safe-deposit box and had never connected to the internet. Attackers still stole 18.25 BTC in seven minutes. The device had remained physically protected, but the key it created had not.
The risk had come from the product people had chosen to protect themselves.
The reaction spread across Bitcoin and Coldcard communities on Reddit. One user reported losing Bitcoin in the exploit, while another said they were leaving Coldcard.
In another discussion, a Ledger owner questioned every hardware-wallet company, while commenters debated moving to ETFs, Fidelity, Binance or Coinbase.
These posts do not prove a wider shift, but they show that returning to third parties had already become part of the debate.
Coldcard pushed some holders from self-custody back to exchanges
After the flaw was exposed, holders worried about vulnerable keys had to decide where to move their Bitcoin. They could trust another hardware wallet or let an exchange protect the keys for them.
On-chain data gives a partial view of what happened next. On July 31, nearly one million Bitcoin addresses sent or received funds, up from 645,000 the day before, according to CryptoQuant. The surge showed a rush to move Bitcoin, but not what caused every transfer or where the funds went.
Exchange deposits provide a clearer clue. On the same day, people deposited more Bitcoin into exchanges than they withdrew. The difference was 11,163 BTC, according to CoinDesk. Most went to Binance, River, Kraken and OKX.
Not every deposit can be linked to Coldcard. But the timing suggests that some holders chose an exchange instead of another self-custody wallet.
Exchanges, however, carry their own risks. Many Bitcoin holders choose self-custody because exchanges have repeatedly been hacked or collapsed. In 2025, for example, attackers stole approximately $1.5 billion from the Bybit exchange.
For holders who returned to exchanges, the move removed the immediate uncertainty around Coldcard. But it did not remove the need for trust. It simply moved that trust from the wallet manufacturer back to an exchange responsible for protecting their keys and providing access to their Bitcoin.
Coldcard did not prove that self-custody is dead. It showed that owning your keys still means trusting the tools that create them.
What qualifies a hardware wallet as secure?
Coldcard had a strong reputation. But reputation reflects what a product has survived before. It does not show which parts of its security have been independently tested.
Terms such as open source, air-gapped (designed to work without a direct internet connection) and secure element (a chip built to protect secret keys) can make a wallet sound trustworthy. These are useful features, but they do not prove that the complete product is secure.
Public code still needs to be reviewed, and a certified chip does not automatically qualify the software responsible for creating and protecting the keys.
A formal security qualification identifies the exact product and software version tested, the threats included and the organization that performed the evaluation.
The ANSSI certification of the Ledger Nano S Plus, for example, applies only to the version and configuration that was evaluated. Its security target includes threats such as predictable random-number generation and malicious firmware updates. It shows what was tested, but it does not guarantee the security of every future version.
Coldcard shows why this matters. Its weakness was introduced through firmware and affected how recovery phrases were created. A review of the hardware alone would have missed it, while a review completed before the vulnerable firmware was released would no longer have been enough.
Meaningful qualification must therefore cover the hardware, firmware, key generation and update process. It must also be repeated when an update changes how the keys are created or protected.
Self-custody removes the need to trust an exchange. It should not replace that trust with claims users cannot verify. Hardware-wallet security needs clear evidence, and that evidence must be renewed when the product changes.
🎣 Is It a Phish ?
Would you click to renew your GitHub SSO access?
🔬 Technical Research
The Wallet Stayed Offline. The Attacker Still Found the Key.
The reported COLDCARD thefts in July 2026 exposed the failure mode on the other side of cold storage. Attackers did not need to compromise the device, intercept a transaction, trick users into approving a payment, or steal recovery phrases from a backup. Public reporting links the incident to weak seed generation in affected firmware: the wallets were offline, but the space of possible seeds was small enough to search.
The first widely documented sweep moved approximately 1,082.65 BTC from 1,196 Coldcard wallets in 41 minutes on July 30, worth about USD 70 million at the time. Subsequent analysis expanded the reported total to roughly 1,755 BTC across around 5,000 wallets, placing the loss near USD 116 million, although the estimate continued to change as researchers grouped additional transactions.
The device did not leak the key after it was generated.
The key appears to have been guessable from the beginning.
The attackers did not have to break into the wallet. They searched the reduced seed space elsewhere, found addresses holding bitcoin, and recreated the keys on their own machines.
Where randomness became the security boundary
A Bitcoin wallet does not store a pile of unrelated private keys. It starts with entropy: random input encoded as a recovery phrase. Given the same recovery phrase and optional passphrase, BIP-39 always produces the same seed, from which the wallet derives its master key, private keys, public keys, and addresses.
This reproducibility is intentional. It is why the same recovery words can rebuild the same wallet years later on another compatible device.
It also creates a hard rule: anyone who reconstructs the same seed reconstructs the same wallet.
Normally, this is computationally unrealistic. A correctly generated 12-word BIP-39 phrase represents 128 bits of entropy, while a 24-word phrase represents 256 bits. The search spaces are so large that trying every possibility is not a practical attack.
But the words do not create the randomness. They only encode it.
If the random-number generator can produce only a limited or predictable subset of possible values, a recovery phrase can still look normal while representing far less uncertainty than its length suggests. Twenty-four correctly spelled words are not automatically 256 bits of security. They are only as strong as the process that selected them.
That is the boundary the COLDCARD incident appears to have broken.
The fallback that should never have been possible
COLDCARD publishes its firmware repository and supports reproducible builds, allowing this code path to be inspected directly.
In firmware 4.0.0, COLDCARD changed new-wallet generation from its own ckcc.rng_bytes hardware-randomness path to random.bytes(32), a wrapper around the new libNgU library. The intended libNgU implementation was meant to use the STM32 hardware random-number generator.
A build-configuration mistake defeated that intention. LibNgU checked only whether the hardware-RNG setting existed, while MicroPython checked whether it was enabled. The setting existed but was set to 0, so libNgU’s check passed while MicroPython compiled rng_get() as its software fallback.
That fallback was seeded from device-specific and timing values, not sufficient fresh secret entropy. As a result, seeds that appeared normal could come from a far smaller, enumerable set of possibilities. The exact impact varied by device generation; Coinkite’s current advisory is the authoritative source for affected model and firmware ranges.
The resulting call chain looked like this:
make_new_wallet()
↓
random.bytes(32)
↓
ngu.random.bytes()
↓
my_random_bytes()
↓
CHIP_TRNG_32()
↓
rng_get() That final function name is where the implementation and the assumption separated.
The COLDCARD board configuration defined MICROPY_HW_ENABLE_RNG as 0 because the project included its own hardware-RNG implementation. LibNgU attempted to ensure an STM32 hardware RNG was available, but its compile-time guard checked only whether MICROPY_HW_ENABLE_RNG was defined. It did not check whether the value was enabled.
Because the macro existed, libNgU accepted the build and mapped CHIP_TRNG_32() to MicroPython’s rng_get(). Because the macro’s value was zero, MicroPython compiled the other implementation of rng_get(): a Yasmarang software PRNG intended for STM32 targets without an enabled hardware RNG.
The setting existed with a value of 0. That was enough to pass libNgU’s existence check, but MicroPython’s value check compiled the software fallback instead of the hardware RNG implementation.
The fallback initialized its internal state from the first 32 bits of the chip’s unique identifier XORed with the current SysTick counter, plus two real-time-clock registers. Those inputs can vary, but they are not equivalent to 256 bits of fresh secret entropy. LibNgU XORed that output with a second Yasmarang stream whose state began from fixed constants. Mixing in another deterministic stream changes the output; it does not add unknown entropy.
That distinction is critical.
A hardware TRNG measures a physical process intended to provide fresh, unpredictable entropy. A software PRNG expands an internal state into values that look random. A cryptographically secure PRNG can be safe when it begins with enough secret entropy and is reseeded correctly. A small deterministic fallback seeded with values such as device identifiers and timer state is not an acceptable replacement for generating a wallet’s master secret.
The dangerous part was not simply that a software generator existed. It was that the production path could silently use it for a security-critical operation.
Two local checks made the output look safer without repairing the entropy loss. Seed creation verified that the 32 generated bytes contained more than four distinct values, which can catch a stuck generator but cannot distinguish predictable output from cryptographically random output. It then hashed the 32 bytes with SHA-256 to mitigate bias. Hashing can spread biased input evenly across the output, but it cannot create possibilities that were absent from the original generator. If an attacker can enumerate the inputs, they can hash every candidate too.
The wallet still displayed a valid recovery phrase. The checksum still worked. Addresses derived normally. Transactions signed normally. Nothing in the user experience announced that the seed came from a much smaller search space.
The failure was quiet, persistent, and irreversible for every wallet created from the affected randomness.
How an offline brute-force attack becomes a theft
Once the RNG behavior is understood, the physical wallet is no longer required.
An attacker can reproduce the weak generator, enumerate its plausible internal states, and convert each output into candidate recovery phrases. From every candidate, they derive the corresponding Bitcoin keys and addresses.
The blockchain provides the verification layer.
Bitcoin addresses and their balances are public. The attacker does not need to query the victim, log in to a service, or trigger an alert on the hardware wallet. They compare the derived addresses with blockchain history and keep the candidates that produce a match.
When a candidate seed derives an address containing bitcoin, the search is over. The attacker now possesses the same signing authority as the original wallet owner. They can recreate the wallet on their own system and produce a transaction that the Bitcoin network considers completely valid.
There is no forged signature for the network to reject. No password failure. No abnormal authentication flow.
The attacker has the key.
Why 41 minutes does not describe the whole attack
The most dramatic number in the reporting is the 41-minute window in which more than one thousand bitcoin were moved.
That was likely the execution phase, not the beginning of the work.
Enumerating candidate seeds, deriving their addresses, checking their histories, and prioritizing funded targets could happen before the first theft transaction appeared. The rapid sweep suggests the attacker may already have prepared a list of vulnerable wallets and private keys, then moved through the highest-value targets in a coordinated burst.
Later transactions complicate attribution. Public estimates grew from an initial 594 BTC to more than 1,000 BTC, then to approximately 1,755 BTC as additional waves and addresses were associated with the weakness. Similar transaction timing or fund flows can support clustering, but they do not automatically prove that every theft came from one operator.
For that reason, the safest description is an evolving, on-chain estimate rather than a final victim count or a confirmed single-attacker total.
Why updating the device is not enough
A firmware update can correct the randomness used for future wallet creation.
It cannot add entropy to a seed that already exists.
Every private key and address derived from an affected recovery phrase remains tied to that original seed. Wiping the device and restoring the same words changes nothing. Importing those words into a different hardware wallet changes nothing. The new device simply recreates the same keys the attacker may already be able to calculate.
The meaningful remediation is migration:
Install verified firmware from the official vendor source.
Generate a completely new seed using a trusted, unaffected process.
Verify the recovery procedure and receiving address offline.
Move all funds from addresses derived from the old seed to the new wallet.
Treat every child wallet derived from the old root, including BIP-85 children, as potentially exposed.
Never enter the recovery phrase into a website, support form, “checker,” or unsolicited recovery tool.
Users should follow Coinkite’s current advisory for the definitive affected-device and firmware scope. Public reporting has not always used “wallet,” “address,” “device,” and “user” consistently, and those terms are not interchangeable.
What hardware-wallet teams should learn
This was not a failure of Bitcoin’s signature algorithm, BIP-39 word list, or blockchain consensus. It was an implementation failure at the moment a long-term secret was created.
That makes the engineering lessons unusually direct:
A cryptographic RNG must fail closed. If the intended entropy source is unavailable, seed creation should stop with a visible error.
Production code should not contain a silent non-cryptographic fallback for key generation.
Tests must exercise the exact signed firmware image and hardware path shipped to users, not only source-level or simulator behavior.
Build-time configuration should assert that the required RNG implementation is active.
Independent entropy sources can be combined so that one failed component does not fully determine the seed.
Seed generation needs known-answer, fault-injection, and negative-path tests in addition to statistical randomness tests.
Reproducible builds improve transparency, but reproducibility only proves that the binary matches the source. It does not prove that the source is secure.
Multisignature custody is strongest when keys are generated independently, ideally across different implementations and vendors. Repeating the same weak generator across every signer preserves the same failure domain.
The broader lesson is uncomfortable because the hardware wallet appears to do everything right after setup. It keeps the seed offline. It protects the PIN. It verifies firmware. It displays addresses on a trusted screen. It signs inside dedicated hardware.
All of those controls sit downstream of seed generation.
If the first secret is predictable, the rest of the architecture may protect a key the attacker can independently recreate.
Air-gapping protects a secret from leaving the device.
It cannot protect a secret that was never secret enough.
Version and scope note: This section reflects public reporting available on August 10, 2026. Loss totals, transaction clusters, and the precise affected-device scope were still evolving. The USD 116 million figure is an estimate, not a final audited loss total.
Sources: TRM Labs, CoinDesk, Coinkite security advisory, COLDCARD firmware repository, firmware 4.0.0 seed-generation code, COLDCARD board RNG configuration, pinned libNgU RNG implementation, pinned MicroPython STM32 RNG implementation, COLDCARD firmware history, BIP-39 specification
🛠️ Tool of the Week
LLVM
Most people think a compiler has one job: turn source code into a working application.
LLVM shows how compilation can also become part of security testing. The open-source infrastructure behind Clang can insert checks while software is being built, helping security teams uncover memory errors and guide fuzzers toward code that ordinary tests may never reach.
How LLVM supports security testing
Clang translates C and C++ source code into an internal format that LLVM can analyze and modify before producing the final application.
During this process, tools such as AddressSanitizer can add checks that detect memory problems, including attempts to access data outside an allowed area or reuse memory after it has been released.
LLVM also includes libFuzzer. It repeatedly sends modified inputs to a program and tracks which parts of the code they reach. Inputs that discover new behavior are kept and modified again, allowing the fuzzer to explore progressively deeper into the application.
A simple example
Imagine a company maintains a C++ library that processes image files.
A security engineer compiles the library with Clang and enables AddressSanitizer. They then connect libFuzzer to the function responsible for opening images and provide several valid files as starting inputs.
LibFuzzer continuously modifies those files while monitoring which parts of the parser are reached. Eventually, one malformed image activates a rarely used code path and triggers a memory error.
AddressSanitizer reports where the error occurred, giving the team a reproducible input and a clear place to begin investigating.
What it does not replace
LLVM is an infrastructure project rather than a security scanner that can simply be pointed at an application.
Using its security capabilities usually requires access to the source code and build process, along with a suitable fuzzing target. It will not automatically identify authorization flaws, insecure business logic or vulnerabilities that its tests never reach.
These additional checks can also make an application run more slowly, so instrumented builds are generally used for testing rather than released to users.
👏 Person of the Week
Andrea Fioraldi
This week, we’re highlighting Andrea Fioraldi , a security researcher focused on fuzzing and automated vulnerability discovery.
Andrea is one of the maintainers of AFL++, a community-driven open-source fuzzer that brings techniques developed through years of security research into one practical tool.
His work also includes LibAFL, a framework for building customized fuzzers, and QASan, which helps detect memory errors in compiled software when its source code is unavailable. His doctoral thesis on modern fuzzing techniques received the 2024 Thesis Prize from GDR Sécurité Informatique.
For helping turn fuzzing research into practical open-source tools for discovering software vulnerabilities, Andrea Fioraldi is our Person of the Week.
📅 Event of the Week
Ekoparty Security Conference 2026
Thousands of security researchers, professionals and enthusiasts are expected in Buenos Aires for the 22nd edition of Ekoparty , Latin America’s largest hacker conference.
Across three days, the event combines technical talks and workshops with CTFs, community villages, live hacking activities and practical challenges.
Its program covers mobile hacking, reverse engineering, fuzzing, exploitation, firmware, cloud security and hardware hacking.
For AppSec and offensive-security teams, Ekoparty brings together new security research, practical demonstrations and hands-on activities in one event.
📍 Centro de Convenciones de Buenos Aires, Argentina
📅 October 7–9, 2026
📚 Book of the Week
Black Hat GraphQL
By Nick Aleks and Dolev Farhi
How do you test an API that allows clients to decide exactly what data they want?
Black Hat GraphQL explains how GraphQL APIs work and how security professionals can examine their attack surface. It covers reconnaissance, information disclosure, authentication and authorization bypasses, injection, denial-of-service attacks and request forgery.
Through hands-on labs and a deliberately vulnerable GraphQL application, readers learn how to identify weaknesses, validate security controls and incorporate automated testing into the development pipeline.
It is a useful read for penetration testers, AppSec engineers, security analysts and developers who want a practical understanding of how GraphQL APIs are attacked and protected.
😅 The Meme
If both hardware wallets and exchanges require trust, what evidence should Bitcoin holders demand before deciding where to keep their Bitcoin?
The Breach Brief, Ostorlab Team