SafePal Order Data Leak: 39,798 Wallet Buyers Exposed by an Authorization Flaw

TL;DR

On August 16, 2026, SafePal disclosed an authorization flaw in the order-tracking function of a plug-in attached to its store. Under some conditions the flaw let one customer read another customer's order record. Approximately 39,798 buyers who placed orders between March 2, 2025 and April 11, 2026 had their name, email address, shipping address, phone number and purchase details read without authorization. Seed phrases, private keys, wallet passwords, card numbers and government ID numbers were not involved, and SafePal has found no evidence that wallets or funds were touched. The exposed records amount to a verified list of people who own a hardware wallet, which model they bought, and the street address it shipped to, which solves an attacker's targeting problem in a single file. For a company that sells self-custody, the order database carries the same blast radius as the firmware, and it almost never gets the same scrutiny.

The Disclosure, and What It Leaves Out

SafePal is a hardware and software wallet company backed by Binance Labs, per The Crypto Times, and it sells its devices through its own storefront.

The notice is specific about scope. Affected fields: name, email address, shipping address, phone number, purchase details. Affected population: roughly 39,798 customers. Affected window: orders placed between March 2, 2025 and April 11, 2026. Every affected customer was emailed on August 16 from security@safepal.com. SafePal also published a page where a buyer checks status using an order ID and a shipping country. (Checking your exposure to an order-lookup flaw by submitting an order ID is a choice.)

It is equally specific about what it excludes. SafePal states it never requests, collects or stores seed phrases, private keys, wallet passwords, bank account information, payment card numbers or government-issued ID numbers, so none of those were in the exposed set. It also says plainly that the affected order information "may be used for targeted phishing and impersonation attempts."

What the notice does not say is when SafePal discovered the flaw, when unauthorized access started or stopped, or who found it. The word used is "recently." The affected order window closes on April 11, 2026, four months before disclosure, with no reason given. It could mark the end of the attacker's access. It could equally mark a change in what that system retained. SafePal has not explained it, so the April 11 boundary carries no information about when access actually stopped. The notice also declines to name the plug-in or its vendor, which leaves any other merchant running the same integration with no way to check itself, and it offers affected buyers no credit monitoring or compensation.

Remediation, as stated: the flaw is fixed, an independent security firm "is being engaged" to validate that fix and review the order-processing system, retention there is capped at 90 days, logistics partners were contacted, and over 30 fraudulent websites and phishing links have been taken down.

That last item is the one to sit with. You do not take down 30 phishing domains on disclosure day. They were already up.

The Bug: Authorization Bypass Through a User-Controlled Key

An application shows you your own order by looking it up with a key you supplied, usually the order number in a URL or a form field. Authentication asks whether you are a real user. Object-level authorization asks whether this record belongs to you. Perform the first check, skip the second, and changing the order number in your own request returns somebody else's record, which the server treats as a normal read.

MITRE catalogs this as CWE-639, Authorization Bypass Through User-Controlled Key: a system whose authorization "does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data." OWASP ranks the same weakness first among API risks as API1:2023 Broken Object Level Authorization, because servers routinely trust client-supplied object identifiers. CoinDesk described the SafePal case as an attacker seeing other customers' orders by modifying order numbers, comparable to reading another customer's receipt through a parcel-tracking system. That matches CWE-639 exactly.

Two properties turn a single unauthorized read into a full database extract. The first is enumerability: commerce platforms hand out order numbers in sequence, so a valid identifier tells you where the next thousand live. The second is cost: each record is one HTTP request. OWASP's prevention list is short and old, which is what makes this class frustrating rather than interesting. Check ownership on every record access. Use unpredictable identifiers instead of sequential ones. Write authorization tests and run them before you ship.

From Flaw to Campaign, Step by Step

The path from flaw to fraud is short. Separating what SafePal confirmed from what customers reported and what remains inference:

Step seven is not our speculation. SafePal's own guidance tells customers to "treat any unexpected contact or hardware delivery referencing your SafePal purchase as suspect, whether it arrives by phone, in the post, or in person." A wallet vendor writing "or in person" into a customer notice is telling you what it expects next.

Step three is where the unanswered question sits, and it is the more interesting failure. Pulling forty thousand order records means roughly forty thousand requests against one endpoint, walking an identifier range in order. That is the traffic shape a rate limit or a request-anomaly rule exists to catch, and it ran for some part of a 405-day window without producing an alert anybody acted on. SafePal has published no request volumes, no dates for the access itself, and no account of what the storefront's logs held, so the public record cannot say whether nothing fired or nothing was watching.

Customers Were Reporting This Six Weeks Earlier

Three reviews on SafePal's public Trustpilot page describe the campaign before the August 16 notice. SigIntZero has not independently verified them; they are dated first-person customer reports on a public platform, and we present them as that.

A reviewer in Australia, posting July 1, 2026, describes a call from someone claiming to represent SafePal who knew their name, phone number, the exact purchase date, and which devices they had bought and how many. By their account SafePal responded that it had found no indication its systems or confirmed third-party providers had been compromised, while being unable to explain how the caller had that detail. The reviewer later confirmed the August 16 email arrived and credited the company for acknowledging it.

A reviewer in the UAE, posting July 4, 2026, describes a caller with their account information who pushed them toward a replacement hardware wallet and a site at a safepal.support address. SafePal replied two days later asking them to file a ticket.

A reviewer in Canada, posting July 28, 2026, describes a phishing email received the previous day from a safepal.review domain carrying their order number, order date, amount, billing address and payment method. They opened a support ticket and, in their account, were told: "based on the review conducted to date, we have not identified any indication that customer information has been compromised through SafePal's official systems or our confirmed third-party service providers. At present, we are unable to verify how the phishing actor obtained the information used during this scam." SafePal's public reply on that review, dated August 4, 2026, says the team is continuing to review "this incident."

Take those dates at face value and the earliest public report sits 46 days ahead of the disclosure. In that window the front line was a support queue, and a support queue is graded on ticket resolution, not correlation. Each report looked like an ordinary crypto scam complaint, the highest-volume category any wallet vendor's inbox handles. What made these different was that the scammer already knew the order number, and three of them arrived from three countries carrying purchase dates and device models. Whether anyone inside SafePal was in a position to see all three together is not something the public record answers.

The two domain names in those reviews are checkable, which changes how much weight the accounts carry. Registry records show safepal.support was registered on April 10, 2026 and safepal.review on July 10, 2026, seventeen days before the phishing email the Canadian reviewer describes. The first of those dates falls one day before the last affected order in SafePal's window. A wallet brand attracts lookalike registrations constantly, so read that as a coincidence worth recording rather than as a causal link. Both entries last changed on August 11 and 12 and both now carry client hold, the status a registrar applies when it suspends a name, which places those takedowns four to five days ahead of the public notice.

The Ledger Precedent: Where a Buyer List Ends Up

A leaked retail customer list gets you spam. A leaked hardware wallet list gets you pre-qualified people who self-custody enough value to buy dedicated hardware for it, plus the address where they keep it.

The industry already ran this experiment. In July 2020 Ledger disclosed that an unauthorized third party had reached part of its e-commerce and marketing database through an API key on June 25, 2020, exposing around one million email addresses plus roughly 9,500 customers with fuller detail including names, postal addresses and phone numbers. No payment data, no passwords, no keys. The same reassuring shape as this week's notice.

Then it aged. In December 2020 a dataset holding 272,853 customer records with names, physical addresses and phone numbers was published on a hacking forum, according to Halborn's account of the aftermath. Six months later, criminals used those addresses to mail victims boxes containing counterfeit Ledger devices with a letter purporting to come from Ledger's CEO, offering a replacement because of the breach. A micro flash drive was soldered to the fake device's internals. Plug it in, and the software asked for the 24-word recovery phrase to "import" the old wallet.

That is the finished form of this attack, and it took a year to arrive. It also gives you the honest way to read a first-day scoping figure. Ledger's initial disclosure named 9,500 detailed records; the dataset five months later held 272,853. We have no evidence SafePal's number is wrong, only that "approximately 39,798" is the output of a review conducted under time pressure, published on day one, using whatever access logs survived a retention policy tightened afterward.

The Vendor Integration Nobody Scoped

The failure sat in the order-tracking function of a plug-in bolted onto a storefront. SafePal's cryptography, firmware and chain integrations all worked as designed throughout.

Crypto security budgets concentrate on the parts of the stack that touch keys and chains, because that is where the money is and what the market pays to have audited. Meanwhile the commerce stack, a storefront, a payment processor, a fulfillment partner, an email provider, a support desk and an assortment of plug-ins, accumulates the identity graph of every customer and is scoped by nobody. An audit certifies the code you pointed it at, on the day you pointed it at it, and the storefront was never in that scope.

The same asymmetry showed up in Ledger's leak sequence. The device did its job. The storefront that sold it gave away the buyer's address, and the resulting attack aims past every protection the device offers, because a recovery phrase typed voluntarily into a convincing support flow leaves the wallet working exactly as designed.

We have written before about the human factor in Web3 losses and about what happens when a hardware wallet's own guarantees fail. This one sits between the two.

Operator Takeaways

1. Put every third-party plug-in that touches customer records in audit scope. Inventory them by data access, not by whether they shipped in the original build. A plug-in added to display shipping status is a database read path that inherits none of your first-party review.
2. Test object-level authorization on every record-fetch endpoint. Take an authenticated session for user A, request user B's identifier, assert a denial. Run it in CI, because this class returns the moment an endpoint ships without one.
3. Stop using sequential public identifiers for customer-scoped records. Opaque random identifiers leave the missing authorization check exactly where it was, and they remove the enumeration that turns one leaked record into forty thousand. Do both.
4. Treat "the scammer knew my order number" as a breach indicator rather than a scam report. Give the support desk one escalation trigger with no judgment call attached: any report where the fraudster held non-public order data goes to security the same day. SafePal's support line was accurate about what its review had found, and the review was looking in the wrong place.
5. Set data retention before an incident forces it. SafePal capped retention in the affected environment at 90 days after the fact. The 13-month exposure window is a direct product of what that system still held.
6. Publish an unknowns section in the disclosure. Detection date, access start, access end, discovery source. When those are absent, readers price in a revision and you pay that cost without the credit for candor.
7. If you own a hardware wallet, assume your purchase details are public. No vendor calls about a problem with your device, ships an unsolicited replacement, or needs your recovery phrase.

On where SigIntZero fits, honestly: on-chain alerting would not have seen an HTTP request to a storefront, and no transaction surveillance catches a customer typing a seed phrase into a counterfeit device six months from now. This was a web application authorization bug of the most ordinary kind. A routine application security review of the commerce stack finds it in an afternoon, and if the last thing you reviewed was your contracts, nobody has run that review against your storefront. That is a scoping decision somebody made, usually without noticing they were making it.

Frequently Asked Questions

Were SafePal wallets or crypto funds stolen in this breach? No. SafePal states the incident did not involve seed phrases, private keys or wallet passwords, and that no evidence has been found that it compromised access to wallets or funds. The risk is downstream: the exposed order data makes impersonation and phishing against those specific buyers far more convincing.

How do I check whether my SafePal order was affected? All affected customers were emailed individually on August 16, 2026 from security@safepal.com. SafePal also published a verification page where a customer can check status using an order ID and shipping country. Reach it by typing the SafePal domain into your browser rather than following a link in any email, including one that appears to be the breach notice itself.

Should I move my crypto to a new wallet? SafePal's guidance is that order data exposure alone is not a reason to move assets, and we agree. The exception matters more: if you have already entered your seed phrase in response to any call, email, letter, site or device that arrived after this leak, treat that wallet as compromised, generate a new one on a device you trust, and move the funds immediately.

Is this the same kind of failure as the Ledger breach? The root causes differ. Ledger's 2020 exposure came through an API key reaching an e-commerce database; SafePal's came through an authorization flaw in an order-tracking plug-in. The consequence is identical: a verified list of wallet owners with home addresses, and a phishing campaign on top of it.

Sources / References

• SafePal security notice, August 16, 2026
• CoinDesk on the SafePal vulnerability
• The Crypto Times on the SafePal leak
• Trustpilot: public customer reviews of safepal.com
• Registry RDAP records: safepal.support, safepal.review
• MITRE CWE-639
• OWASP API1:2023
• Ledger on the July 2020 breach
• Ledger CEO update on the leak
• Halborn on the fake Ledger wallet scam