Security · Analysis
The Vendor Nobody Chose: How a Dashboard Bug Leaked Hardware-Wallet Buyers
One maximum-severity flaw in a business-intelligence tool — software no crypto customer has ever heard of, let alone agreed to — put the home addresses of hardware-wallet owners in the open. Trezor's saving throw was not cryptography. It was a deletion policy.
If you bought a Trezor between May and August, the safest assumption is that a stranger knows where you live.
Not because Trezor was hacked. It wasn't. Not because the device failed, or the firmware leaked, or a seed phrase went anywhere. The company is unusually clear on this point, and the evidence supports it: Trezor says its own systems were not compromised, and that no hardware wallet, private key, or wallet backup was touched.
What happened instead is that a dashboard tool three companies removed from the customer got popped, and the shipping labels fell out.
The flaw at the bottom of the stack
The vulnerability is CVE-2026-72898, an unauthenticated SQL injection in Metabase, a widely deployed open-source business-intelligence platform — the sort of thing a logistics company runs so its operations team can look at charts. Per OffSec's analysis, an attacker with no credentials at all can inject SQL through a password-reset endpoint and escalate to administrator on the Metabase instance. From there they can read the application's configuration, harvest the credentials for every database Metabase is wired into, and export whatever those databases hold.
It is rated CVSS 10.0. There is no higher number.
Metabase found the flaw the hard way, during an attack on its own cloud service, and disclosed it in the first days of August; The Hacker News dates public disclosure to August 8, while incident-response accounts place the first in-the-wild exploitation as early as August 3. CISA added it to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of August 14 — the short-fuse version of that deadline, reserved for bugs already being used.
The scale of the exposed surface is the part that should worry people who have never typed the word Metabase. Security firm Wiz found self-hosted Metabase instances in roughly 13% of cloud environments, with about a quarter of those reachable from the open internet — on the order of 2,500 exposed instances. Dataminr's scanning found thousands still unpatched after disclosure. The victims that surfaced first were not crypto companies at all: hardware maker Framework, the automation platform n8n, and the developer tool Kilo Code, which lost Slack tokens.
Three hops from the flaw to your doorstep
Here is the chain, and it is worth walking slowly, because every link is a company the customer never evaluated.
Trezor sells a hardware wallet. Trezor outsources fulfilment for some regions to ShipMonk, a third-party logistics provider. ShipMonk runs Metabase. Metabase had a 10.0.
ShipMonk's own breach notifications — obtained by BleepingComputer, since ShipMonk issued no public statement — tell customers that on August 6, Metabase informed it that an unauthorized party exploited a vulnerability in Metabase's software
. ShipMonk notified Trezor on August 10. Trezor told its customers on August 13.
One point of precision, because it matters and most coverage has blurred it: Trezor itself has never named Metabase. Its notice attributes the incident to a breach at a shipping provider and says its investigation was ongoing. The Metabase link comes from ShipMonk's notification emails and from the security researchers who matched the timeline. That is a solid chain — but it is a chain of two disclosures and an inference, not a single confirmed statement, and it should be read that way.
Then there is the coda nobody enjoys: BleepingComputer reports that ShipMonk has received extortion emails from the ShinyHunters group. The list, in other words, has commercial value to someone.
What a deletion policy is worth
Trezor's exposure came to 13,689 customers — 11,742 with full records (name, email, phone number, shipping address) and 1,947 with partial (name, city, email). The affected orders ran from May 10 to August 8, across the US, UK, Sweden, Colombia, Brazil, Italy, and Portugal. Orders fulfilled through Amazon went through a different partner and were untouched.
Now the number that should be the headline. That window is three months wide for one reason: Trezor operates a 90-day data-retention policy, and the records older than that were already gone when the attacker arrived. Trezor did not out-engineer this breach. It had simply already thrown away most of what the attacker came for.
Set that against the SafePal breach this desk covered last month, and the comparison does the arguing for you. SafePal exposed 39,798 hardware-wallet buyers across thirteen months of orders — not because the intrusion was more sophisticated, but because a configuration error meant order data was not being purged as intended between September 2025 and April 2026. Same industry, same category of loot, an intrusion of similar mundanity. Roughly three times the victims, because of a data-lifecycle setting.
Same loot, different retention
| Incident | Root cause | Records | Order window |
|---|---|---|---|
| Trezor (via ShipMonk) | Metabase CVE-2026-72898 at the 3PL | 13,689 | ~3 months (90-day purge) |
| Bits of Gold | Metabase CVE-2026-72898 at a provider | 200,000–250,000 | Registered customer base |
| SafePal (different root cause) | Order-plugin authorization flaw + retention failure | 39,798 | 13 months (purge misconfigured) |
A number worth not repeating
That last row needs saying out loud, because the aggregators have already got it wrong. Several roundups now circulate a tidy figure — 253,487 customers exposed across SafePal, Trezor/ShipMonk and Bits of Gold — presented as the Metabase cluster's toll. It is arithmetic laid over three incidents that do not share a cause. SafePal traced its breach to an authorization flaw in an order-tracking plug-in, compounded by the retention error above. Metabase is not in that account anywhere.
The Bits of Gold half of the sum is also softer than it looks. Israel's largest regulated crypto broker disclosed on August 17 that attackers reached a supporting data system through the flaw at its analytics provider rather than through its own systems. Calcalist reports approximately 250,000 registered customers potentially affected; CoinDesk puts the figure at 200,000. Both are reporting the same disclosure. When two competent outlets are 50,000 people apart, the honest move is to publish the range and wait for the regulator's version rather than pick the bigger one and add it to something else.
What Bits of Gold customers lost is nonetheless serious in a specific way: names, national ID numbers, phone numbers, email and IP addresses, bank account details, and public wallet addresses. Passwords, card numbers, CVVs and ID photographs were not in the set. The company reported to Israel's Capital Market Authority and the National Cyber Directorate and says customer funds and crypto were untouched.
The threat model has a hole in the shape of a spreadsheet
Every one of these disclosures contains the same reassuring sentence: no funds were taken. It is true, and it is the least interesting fact available.
A hardware-wallet order record is a signed statement that a specific person at a specific street address owns enough cryptocurrency to buy dedicated hardware to protect it. That is not incidental marketing data. It is a targeting list, and its buyers are not interested in your email address. Physical coercion attacks against crypto holders — the industry euphemism is "wrench attacks" — have been climbing all year, and their limiting input has always been knowing who and where. Two vendor breaches have now supplied both fields, verified, for tens of thousands of people, and one of those lists is already in the hands of an extortion crew.
The uncomfortable structural point is that none of this was reachable by the security decisions these customers actually made. Choosing a reputable hardware wallet, verifying firmware signatures, never typing a seed into a browser — all correct, all irrelevant here. The exposure came through a business-intelligence tool at a fulfilment contractor selected by the vendor, running a version that had not been patched. There is no consumer-side control for that. There is barely a vendor-side one, beyond asking a supplier what software it runs and how fast it patches.
The Take
Crypto security spends its attention on the cryptography and almost none on the back office, and the back office is where the last two months of damage came from. The industry's threat modelling stops at the edge of its own stack — audit the contracts, harden the firmware, and treat the logistics provider's dashboard tool as somebody else's problem. It isn't. Data you have collected and not deleted is a liability sitting on someone else's server, and the only variable you fully control is how much of it still exists when the inevitable vendor breach happens. Trezor's 90-day purge was worth more to its customers this month than any cryptographic property of its device. Retention policy is a security control. Start budgeting for it like one.