The Wallet Is Safe. The Customer List Wasn’t: Inside SafePal’s Order-Tracking Breach

An authorization flaw in a shipping plug-in, and a data-cleanup job that died quietly, exposed roughly 39,798 hardware-wallet customers. The keys were never at risk. The people may be.

When SafePal published its disclosure on Sunday, August 16, the numbers were specific in a way breach notices rarely are: approximately 39,798 customers, everyone who ordered between March 2, 2025 and April 11, 2026, and a defined set of fields – name, email address, shipping address, phone number and purchase details. What was not exposed matters just as much. Seed phrases, private keys, wallet passwords, bank account information, card numbers and government IDs were not touched, and the company says it never collects such data in the first place. No evidence has surfaced that wallets or funds were compromised.

Calling this an “order data leak” would undersell it, though. Read the disclosure together with the company’s own FAQ page and with the accounts of affected customers, and two overlapping failures emerge: a textbook authorization bug in an order-tracking plug-in, and a scheduled data-deletion job that silently stopped working for seven months, which is what turned a six-month retention promise into a thirteen-and-a-half-month exposure window. The second failure, more than the first, explains why customers were receiving phone calls from strangers who recited their home address and order history weeks before SafePal publicly admitted anything was wrong.

A textbook flaw: when the tracking page hands out receipts

SafePal describes the root cause as an “authorization flaw in the order-tracking function for a plug-in associated with customer order information,” which “under certain conditions” allowed “unauthorized access to another customer’s order information”. CoinDesk’s analogy is apt: picture a store’s parcel-tracking page where changing the order number shows you another customer’s receipt and delivery details instead of your own. In common vulnerability taxonomies this pattern is known as an insecure direct object reference, or broken object-level authorization; it has sat at the top of the OWASP API Security Top 10 for years, and it is typically catalogued under CWE-639, authorization bypass through user-controlled key. The mechanics are simple, which is why it keeps recurring. An endpoint accepts an identifier such as an order number, a tracking ID retrieves the record and returns it, checking that the record exists but never checking that the requester is entitled to it.

Order-tracking functions are where this bug class thrives, because they are designed to be reachable by anonymous users. A customer checking a shipment has usually not logged into an account; they are holding an order ID from a confirmation email. That pushes developers toward making the identifier itself the only secret, and in commerce stacks order identifiers are rarely secret for long: numbers tend to be sequential or lightly encoded, and they appear in inboxes, receipts, support tickets, URL parameters and shipping notifications. Once an attacker works out the scheme, enumerating the order table is a script and an afternoon. A public write-up of an unrelated order-tracking system shows what that looks like in practice – customer emails, shipping addresses, order contents and payment amounts served to anyone, without authentication. SafePal has not named the plug-in or published a technical root-cause write-up, and an independent third-party firm is still being engaged to validate the fix and review the wider order-processing system. What the company does acknowledge is that its e-commerce environment “involves multiple interconnected components and external integrations, as well as third-party logistics partners” which is the other half of the story. Plug-ins and integrations are the attack surface nobody reviews with the same rigor as the core product, because they are installed to add a feature and quietly inherit access to production data.

The cleanup job that died quietly

The affected window is where the disclosure gets uncomfortable. SafePal’s stated policy, repeated in a support email sent to a customer on May 19, 2026 and reviewed for this article, is strict data minimization: shipping data and order information are “automatically and permanently deleted from our online system six months after the order has been successfully fulfilled and delivered.” If that had actually been happening, an authorization flaw discovered in 2026 could never have reached orders placed in March 2025. The company’s own FAQ now explains the gap with unusual candor: a “scheduled data-cleanup process had stopped working correctly between September 2025 and April 2026 due to a configuration error,” so older order records “stayed in the system longer than intended,” and that is “why the affected range extends back to March 2025”.

The sequence matters here. SafePal says it received its first report “consistent with this issue” in early May and treated it “as an isolated case” at the time. Days later, its support desk was still assuring customers that the deletion machinery worked and that “the remaining data will wipe itself out automatically very soon.” The company does not state when the backlog of stale records was actually purged, and the May email reads, in hindsight, as a support script promising what the systems were not doing. That is the quieter lesson of this incident. Retention limits are a security control of last resort. When authorization fails, a short retention window still caps the blast radius but a retention policy is only as real as the monitoring on the job that enforces it. Scheduled tasks that fail silently are one of the oldest failure modes in operations, and here one converted a six-month window into a thirteen-and-a-half-month one. SafePal’s corrective step is to tighten retention in the order-processing environment to 90 days, subject to legal requirements. Whether the enforcement is now monitored the way security controls should be is a question the pending third-party review ought to answer.

Why a hardware-wallet customer list is not an ordinary customer list

For most retailers, a leak of names, addresses and phone numbers fuels generic phishing. For a company selling personal security infrastructure, it fuels something sharper, because the purchase history is itself intelligence: it tells a criminal that the person at that address probably holds cryptocurrency, how many devices they bought, and which models. One affected customer, whose account Startup Fortune reported, said a caller knew the number of devices, the model, the delivery address and the payment method, then followed up with an email about a supposed firmware problem that repeated the order details. A Trustpilot review dated July 4, more than a month before public disclosure describes the same experience: “They were hacked with my personal details stolen. I got a call this morning, claiming to be safepal with all my account” details. A home address plus known crypto holdings is also the ingredient list for the uglier end of this crime category, coercion attacks and tampered replacement hardware, which is why SafePal’s guidance explicitly tells customers to treat any unexpected contact or physical delivery referencing their purchase as suspect.

The documented abuse pattern follows a consistent script. A call, often with caller ID suppressed, from a “risk concierge” or support agent who recites the victim’s address and order contents to establish legitimacy; a claim that the device batch is faulty or that a firmware update is urgently required; then an email or message repeating the order number and carrying a link or QR code. In one published account the email pointed to a link at zonos.com, a legitimate cross-border ecommerce and logistics platform. The customer concluded that SafePal’s supply chain must itself be compromised. SafePal’s disclosure does not name its logistics partners, though it confirms they sit inside the order pipeline and says that, after contacting them, it found no evidence of a breach on their side. What can be said with confidence is only what the company itself warns: links that appear to reference real services in the shipping chain are part of the lure, lookalike domains are part of it too. SafePal says it previously reported fraudulent sites swapping the letter “l” for a capital “I” and more than 30 fraudulent websites and phishing links tied to this activity have already been taken down, with monitoring continuing.

What the checker shows, and what to do now

SafePal has published a status checker that asks for two things, an order number and a shipping country, and returns one of two outcomes. If your order is unaffected, the page states that personal information such as email, contact number and address is already permanently deleted, with only the order number, date and purchase content kept for after-sales and warranty purposes. If you are affected, it states that personal data has been purged from active e-commerce servers and that “an offline encrypted copy is stored securely to assist with potential law enforcement investigations”. That last detail is worth noting: the company is keeping a secured offline copy of the affected records, a reasonable forensic and legal posture, but also a reminder that “deleted” in a breach response rarely means destroyed everywhere, immediately.

For the roughly 40,000 affected customers, the practical posture is straightforward even if maintaining it for months is tedious. Check your status only by typing safepal.com into the browser yourself, never by following a link in an email or message that references the breach. Assume any unsolicited call, text, email, letter or delivery mentioning your purchase is hostile no matter how many correct details the sender recites, because those details are precisely what leaked and no longer prove legitimacy. SafePal states plainly that it will never request a 12- or 24-word recovery phrase, a PIN, or private keys through any channel. and its firmware guidance likewise says updates come only through official applications and devices, never through a link sent to you. If you have already entered a seed phrase or private key in response to any such contact, treat that wallet as compromised: create a new wallet on a trusted device, move remaining assets immediately, and contact the company through its official support channel. Report suspicious messages, calls, letters and websites through SafePal’s dedicated reporting page rather than social media, where impersonators reliably outnumber the real support desk.

A better-than-average disclosure, and a trust problem anyway

Measured against what the industry usually produces, the August 16 disclosure is on the stronger side. It gives a precise count and window, names the sender address and subject line of the notification email so customers can separate it from phishing, and publishes both a checker and an FAQ that admits the broken cleanup job and the early-May misjudgment. The listed remediations are concrete: an independent third-party review of the fix and the wider order-processing system, a 90-day retention limit, a dedicated support channel, and the takedown of more than 30 fraudulent sites. The trust damage accumulated before all of this, in the quiet months when support emails promised automatic deletion that was not happening and when, according to the complainant, customers who reported being targeted were told the company “don’t have anything to do with customer data” and the fault might be their own – an early framing around SafePal’s decentralized-wallet nature that Startup Fortune’s reporting shows only deepened the dispute.

The broader lesson reaches past one company. A hardware wallet’s security story does not end at its secure element; it extends to the commerce stack that knows who bought the device and where it went, to the plug-ins bolted onto that stack, and to the scheduled jobs that were supposed to delete the trail. Customers buy these devices as personal security infrastructure, and the order database is the bridge from that infrastructure to a person’s home. Plug-ins are attack surface. Retention is a security control. And a support script is a public claim about the state of the systems, whether or not the systems agree. SafePal’s independent review is still underway, and the company says updates will be posted to its blog as the work concludes. The answers that matter now are whether the fix holds under external scrutiny, and whether the next silent failure gets noticed by the company before it is noticed by a stranger with a phone script.