SafePal Breach Exposes 39,798 Customer Records via Plug-in Flaw

Every locksmith knows the ugly truth: the strongest deadbolt in the world doesn't help if the customer database sitting in the back office tells burglars exactly which houses have the good stuff inside. SafePal just learned this the hard way. The wallets held, the plug-in didn't, and now roughly 40,000 people who bought a hardware wallet specifically to stay off the radar are on somebody's list.

What Happened

On Sunday, hardware wallet maker SafePal disclosed a data breach affecting 39,798 customers who placed orders between March 2, 2025, and April 11, 2026. As CoinDesk reported, the exposed records included names, physical addresses, and contact details. Enough to build a very targeted phishing campaign, or worse.

The company was clear about what didn't leak: no seed phrases, no private keys, no bank details, no government IDs, no passwords, no payment card numbers, and crucially no cryptocurrency funds. The wallets themselves stayed sealed. This was a breach of the shop, not the vault.

SafePal traced the root cause to an "authorization flaw" in a plug-in used to track customer orders. In plain English, the tracker likely let one customer read another customer's order details by fiddling with the request. Change a number, see somebody else's receipt.

SafePal emailed every affected customer from [email protected] on the same Sunday it disclosed, patched the flaw, brought in an independent third-party firm to audit the fix and the wider order-processing pipeline, and committed to retaining personal data in that system for only 90 days from collection going forward. It also identified and removed more than 30 fraudulent websites and phishing links tied to the incident, and put up a verification tool on its own site so users can check whether they're in the exposed set. Users who ever shared a seed phrase or private key with a phishing prompt were told to treat the wallet as compromised and move assets.

Technical Anatomy

An "authorization flaw" in an order-tracking plug-in is the polite way of describing what's almost certainly an IDOR, or a close cousin. Insecure Direct Object Reference has been sitting near the top of the OWASP list for years, and it keeps getting shipped because it's the kind of bug that only exists when you forget to write code, not when you write bad code.

The pattern is depressingly simple. A customer logs in, hits an endpoint like /api/orders/482913, and gets their order. The server checks that a session exists but never checks that this session owns that order ID. Increment the number, get someone else's order. Automate the loop, get 39,798 orders. Anyone who has reviewed a fresh e-commerce integration knows this is the failure mode you scan for first, and it's the one that gets missed when the plug-in was bolted on by a growth team who just needed shipping notifications working before a product launch.

Plug-ins are the recurring villain here. Hardware wallet vendors obsess, quite rightly, over the firmware, the secure element, the supply chain of the device itself. The e-commerce stack that actually sells the thing tends to be a Shopify or Magento install with a graveyard of third-party extensions handling tracking, tax, fulfilment, and email. Each one is a separate auth surface, often written by a two-person shop, rarely covered by the same threat model as the wallet firmware.

The Coldcard incident referenced in the same CoinDesk piece, where an attacker reportedly walked off with at least $120 million in bitcoin, is a different beast entirely. That was money. This is metadata. But the metadata is the map, and the map is what turns opportunistic phishing into targeted extraction. Give me a name, a physical address, and confirmation that the person owns a specific brand of hardware wallet, and I don't need to guess who to send the fake firmware update letter to.

Who Gets Burned

The 39,798 customers wear the primary risk. Their names and shipping addresses are now floating in whatever channel the attacker sells to, and the qualifying signal ("this person owns a SafePal") is baked in. Expect a wave of postal phishing, spoofed replacement-device shipments, fake support calls, and the particularly nasty variant where somebody shows up at a physical address claiming to be from the vendor. SafePal's own advisory that phishing-tricked users should treat wallets as compromised is doing a lot of work in that sentence.

SafePal itself takes a brand hit that's hard to quantify but easy to feel. When your entire pitch is "we are the security company," a breach of the order system reads worse than the same breach at a mattress retailer. The 90-day retention pledge and the independent audit are the right moves, and they were made fast, which counts for something.

The wider hardware wallet category catches strays too. Trezor warned 14,000 customers earlier after a fulfilment partner suffered a data breach. Ledger's 2020 customer database leak still gets cited in every serious threat writeup. There's a pattern, and it isn't about the wallets. It's about the retail plumbing behind them. Any CISO at a hardware vendor reading this on Monday morning has the same question: what does our order pipeline look like, and who last audited it?

For iGaming and fintech readers who might feel this is somebody else's problem, look at your own KYC-adjacent systems. Loyalty platforms, deposit-confirmation emails, courier integrations for physical cards. Same shape of risk, same class of bug, same "we didn't think of it as security-critical" origin story.

Playbook for Security Teams

Three things worth doing this week, in order of embarrassment-if-skipped.

First, grep your codebase and your third-party plug-ins for object-lookup endpoints that trust a session but not an ownership claim. Anything shaped like GET /orders/:id, /tickets/:id, /documents/:id. Automated IDOR scanners catch the obvious cases. Manual review catches the ones where the check exists but only for the "view" route and not the "download PDF" route. That's the boring bit, and it's where the bugs live.

Second, treat data retention as a security control, not a compliance chore. SafePal's move to 90-day retention on order data is the right instinct: the data you don't have can't leak. Order-processing systems accumulate PII the way basements accumulate boxes. Aggressive TTLs on shipping records, contact details, and legacy customer imports shrink the blast radius of the next plug-in bug you don't know about yet.

Third, run a tabletop for the "our customer list is public, our product is fine" scenario. Comms, legal, support, and engineering all react differently to this than to a funds-loss event, and most incident playbooks are written for the funds-loss case. Who drafts the email? Who monitors the phishing sites? Who talks to the auditor? SafePal removed more than 30 fraudulent domains in the wake of this incident, which means somebody had a takedown workflow ready. If your team doesn't, build it before you need it.

Bonus round: if you sell physical goods to customers who value privacy, ask whether you actually need the shipping address after the package is delivered. Nine times out of ten, the answer is no.

Key Takeaways

• SafePal's breach exposed order data for 39,798 customers between March 2, 2025 and April 11, 2026 via an authorization flaw in an order-tracking plug-in. Funds, keys, and seed phrases were untouched.
• The likely bug class is IDOR or similar, the plug-in ecosystem around e-commerce is the real attack surface, not the wallet firmware.
• Affected customers face elevated targeted phishing risk because the leaked data confirms both identity and product ownership.
• SafePal's response (rapid email disclosure, third-party audit, 90-day retention cap, 30+ phishing sites taken down) is the template other vendors should copy.
• Back to the locksmith: the deadbolt is only as private as the customer list in the back office. Audit the office.