SafePal says an order-tracking flaw exposed 39,798 customers' addresses

SafePal disclosed on 16 August that an authorisation flaw in an order-tracking plug-in allowed one customer’s order information to be read by someone else, and that roughly 39,798 customers were affected. The exposed records belong to people who placed orders between 2 March 2025 and 11 April 2026, a window of thirteen months.

The company’s notice is precise about what was in those records: name, email address, shipping address, phone number and purchase details. It is equally precise about what was not. The incident “did not involve your seed phrase, private keys, wallet password, or other wallet credentials, bank account information, payment card numbers, or government-issued identification numbers”, and SafePal adds that it never asks for or stores those in the first place. On the question everyone asks first, the company’s wording is careful: “No evidence has been found that the incident itself compromised access to SafePal wallets or funds.”

What was taken, and what was not

Why an address list is worse for a wallet maker than for a shop

A leaked customer list from a clothing retailer tells an attacker that somebody bought a coat. This one tells an attacker that a named person, at a specific address, with a working phone number, bought a device whose entire purpose is to hold cryptocurrency offline. That is a qualitatively different fact, and it is the reason this disclosure counts even though nothing was stolen.

SafePal’s own advice is the clearest statement of the risk, and it goes well beyond the usual line about suspicious emails. Customers are told to treat any unexpected contact or hardware delivery referencing their SafePal purchase as suspect, “whether it arrives by phone, in the post, or in person”. A wallet maker warning its customers about someone turning up at the door is not boilerplate. It is advice written for a leak that includes where people live.

The notice is direct about what it expects to follow. Affected customers “might be targeted by more sophisticated phishing attempts”, and the list SafePal gives runs from fraudulent phone calls, emails and text messages to letters, refund offers, firmware-update requests and fake customer-support communications.

The list went on sale the same day

That did not take months to arrive. On 16 August, the day SafePal published its notice, the threat-intelligence tracker Dark Web Informer recorded SafePal customer order data being advertised on a cybercrime forum. Its account is carefully hedged and worth reading in the same spirit: a forum seller “is advertising customer information allegedly connected to a SafePal order plugin data breach”, covering customers who ordered in the period SafePal had just disclosed.

The matching detail proves less than it appears. The customer count and the order window were both published in SafePal’s own notice hours earlier, so an advertisement written after reading it would quote them correctly. Nobody has confirmed that this seller holds the records, and we have not either. SafePal has not commented publicly on the listing.

What does not depend on resolving that question is the position the affected customer is in. SafePal’s notice already establishes that the records were read by someone without authorisation. Whether this particular advertisement is genuine changes who is holding the list, not whether a list exists.

The flaw itself

SafePal describes it as an authorisation flaw in the order-tracking function for a plug-in tied to customer order information: “Under certain conditions, the flaw allowed unauthorized access to another customer’s order information.”

SafePal does not describe how the flaw was exploited, and the wording above is the whole of its technical account. What it describes is consistent with a broken object-level authorisation bug, the class of flaw where a system checks that you are signed in but never checks that the record you asked for is yours. That is our reading rather than the company’s.

The company is specific about something else, though, and it is the more useful fact: why the affected window runs back thirteen months. In the FAQ attached to the notice, SafePal says a scheduled data-cleanup process “had stopped working correctly between September 2025 and April 2026 due to a configuration error, which meant older order records stayed in the system longer than intended”. It adds that the fault “did not cause the unauthorized access itself, but it is why the affected range extends back to March 2025”. A retention job that silently stopped is what turned a flaw into thirteen months of exposed records.

What SafePal says it has done

The notice lists six completed steps and two continuing ones. The completed list: the flaw is fixed and further security measures added; the retention period for personal information in the order-processing environment is tightened to 90 days; a dedicated support channel is open for the incident; affected customers were emailed individually; third-party logistics and fulfilment partners were contacted to confirm the problem had not spread into their systems; and more than 30 fraudulent websites and phishing links tied to the resulting scam activity have been identified and taken down.

SafePal places the third-party firm under the completed heading, with the firm “is being engaged” to validate the fix. The two items it lists as continuing are following up with that firm on the audit, with any updates promised on the official blog, and monitoring for new fraudulent domains.

The 90-day retention change is the most durable item on that list, and it is tied directly to what went wrong: it is the same retention machinery whose failure stretched the exposure window. SafePal qualifies it as “subject to applicable legal requirements”. A shorter window shrinks the size of any future incident, which makes it the only step there that reduces the consequences of the next flaw rather than this one.

The signal arrived in May

The disclosure landed on 16 August, but the FAQ puts the first warning three months earlier. SafePal says it “first received a report consistent with this issue in early May, and treated it as an isolated case at the time, but escalated it into a formal security investigation”. It began “a full review and rebuild of our order-processing pipeline in July”, and confirmed the root cause during that work.

That sequence is worth stating because it sets what the disclosure date means. This was not a flaw found and announced in the same week. It was a report that looked like one customer’s problem in May, an investigation, a pipeline rebuild in July, and a confirmed cause announced in August.

How to check, and the trap to avoid

Affected customers were emailed on 16 August from [email protected] with the subject line “[Important] Your SafePal Order Information Has Been Affected”. SafePal has also published a verification page where a customer can check their status using an order ID and shipping country, which is the safer route: it does not depend on trusting an email that arrived unprompted.

One detail in the notice deserves repeating because it is the specific trick already in use against these customers. SafePal reports fraudulent websites that swap the lower-case L in its name for a capital i, two characters that look identical in many typefaces. The company’s instruction is to type the address manually rather than follow any link, including a link that appears to come from the notice itself.

The standing advice is unchanged and worth stating in full: SafePal will never ask for a seed phrase, private key or password, by phone, by email or through any other channel. Anyone who has already entered a seed phrase in response to a message, website, call or letter should treat that wallet as compromised, create a new one on a trusted device and move the remaining assets immediately.

A second customer list in three days

SafePal’s is not the only hardware wallet customer list to surface this month. On 13 August, three days earlier, Trezor disclosed that one of its shipping providers had been breached. The provider, ShipMonk, told Trezor on 10 August that an unauthorised party had reached systems holding customer order data.

Trezor’s numbers are smaller and more precisely split. Of 13,689 affected customers, 11,742 had name, email address, phone number and shipping address exposed, while 1,947 had name, city and email address exposed. The affected orders were received between 10 May and 8 August 2026, across seven countries: the United States, the United Kingdom, Sweden, Colombia, Brazil, Italy and Portugal. Trezor states that “the contents of the parcel were not exposed in this breach”, and that its devices, wallet backups and its own systems were not touched. It does not describe how ShipMonk was breached.

Read next to each other, the two incidents make an argument about data retention that neither makes on its own. Trezor’s exposure stops at three months of orders because Trezor keeps order data for 90 days, and its notice says so. SafePal’s ran to thirteen months because the job that should have deleted old records had been failing since September 2025. Two lists of the same kind of customer, and the difference in scale comes down to a deletion schedule. SafePal’s own remedy was to cut retention in the order-processing environment to 90 days, which is the figure Trezor was already keeping.

The second shared feature is where each failure sat. No device was opened in either case, no backup was read and no key was taken. Both exposures happened in the ordinary commercial machinery around the product: an order-tracking plug-in at one company, a fulfilment partner at the other. For a device bought specifically to keep valuables away from other people’s computers, that surrounding machinery is proving to be the weak edge.

Where this sits against the year’s thefts

No funds moved, so it stays out of the Crypto Exploit Tracker, which records incidents with losses attached.

What it does belong to is the smaller, less-tracked category of incidents that make future thefts easier rather than causing one. The Coldcard entropy sweep in July drained wallets directly. This one hands attackers a qualified list: people who own hardware wallets, verified by purchase, with addresses. For the wider picture of how the sector has been attacked this year, see our reference page on crypto security in 2026.