SafePal discloses an order-tracking data incident

SafePal reports unauthorised access to order information

SafePal reported an order-tracking flaw affecting approximately 39,798 customers who ordered between March 2, 2025 and April 11, 2026. It says names, contact details, shipping addresses and purchase information were exposed, but wallet credentials were not part of the affected data. The company reports no evidence that the incident itself gave access to wallets or funds. That remains SafePal’s stated assessment.

The follow-on approaches SafePal warns about

SafePal’s scam-protection page describes impersonation through email, phone calls, social profiles, fake apps and physical mail. Examples include a supposed firmware emergency, a replacement offer or a request for an invented customs or “unlock” fee. The common pattern is to use a believable story to prompt a separate action.

The page also warns about unexpected replacement devices and messages that ask for recovery words. It directs doubtful users to official support and to social channels verified through the official website. These examples explain the kinds of contact the company wants users to recognise; they are not evidence that every affected customer has received such an approach or that each example occurred in this particular incident.

An illustrative call that knows the order details

Imagine an unexpected caller who knows a customer’s name, delivery address and the product purchased. The caller says a replacement is urgent and offers to guide the customer through a wallet procedure. Accurate order details can make the introduction persuasive, but they do not establish that the caller is authorised to change anything about the wallet.

A useful response is to end the unrequested procedure and independently open the company’s established support route. The customer can describe the caller’s claim and ask whether it corresponds to a published notice. The point is to verify the proposed action outside the channel proposing it. Continuing the call while asking the caller to “prove” their role can keep the verification inside the same untrusted conversation.

This is a fictional example of how exposed purchase information can be used. It is not a report of a call we observed, nor a claim that a person’s wallet is compromised merely because someone knows their address. It demonstrates the difference between knowing customer data and having legitimate authority.

Separate exposed order data from a disclosed wallet secret

For an individual trying to work out what to do, a short factual history is more useful than a broad label such as “affected.” Did the person receive a company notification? Did an unexpected contact arrive? Was a link opened or software installed? Were recovery words or a private key entered anywhere? Each answer changes the question that needs resolving.

For an illustrative report, distinguish receiving an unexpected message from following its instructions. A chronology can record the time of contact, the action taken and the result observed. Those details help a support professional understand the situation without having to guess what the word affected means in this particular case.

A support report should state what happened without reproducing the secret. For example, “I entered my recovery words into the application linked by that message” is informative; sending the words again is not. This preserves the distinction between explaining an incident and creating another exposure while seeking help.

Claims of a dataset sale remain unverified

SafePal could not verify claimed dataset sales. An unverified claim is not a confirmed sale.

Keep the investigation scope precise

Our reading is that the immediate value of the notice is its account of the affected records and the separate response paths for customer data and wallet secrets. A later report should change that account only when new evidence supports the change. For a reader, the practical next step is to understand their own notification and preserve a clear record of any suspicious approach.

That approach avoids two opposite mistakes: dismissing detailed customer-data exposure because it is not a key leak, or assuming that everyone whose order appeared in a database must already have lost control of their funds. Accurate scope makes a more useful security story than either extreme.