The Private Keys Were Safe. The Address of the Person Holding Them Was Not.
SafePal says the incident did not expose seed phrases, private keys, wallet passwords, payment cards or customer funds. It exposed something different: the identity and delivery address of people known to have bought a crypto wallet.
The company’s 16 August 2026 disclosure says an authorisation flaw in an order-tracking plug-in allowed unauthorised access to another customer’s order information under certain conditions. Approximately 39,798 customers who placed orders between 2 March 2025 and 11 April 2026 were affected.
The exposed fields include names, email addresses, shipping addresses, phone numbers and purchase details. SafePal fixed the flaw, notified affected customers and says it is engaging an independent security firm to validate the remediation and review the wider order-processing environment.
The cryptographic boundary may have held. The customer-security boundary did not.
This was not a wallet compromise
SafePal’s disclosure is clear about what the incident did not contain. The company says it does not request, collect, process or store customers’ seed phrases, private keys or wallet passwords. It found no evidence that the incident itself provided access to wallets or funds. Bank-account information, payment-card numbers and government-issued identification numbers were also outside the affected data.
That distinction matters. Customers should not move assets solely because their order record was affected. Moving funds creates its own operational risk and can push a worried customer towards the very phishing sites the incident makes more convincing.
SafePal gives a different instruction if a customer has already entered a seed phrase or private key into a suspicious site or shared it with a caller. In that case, the wallet should be treated as compromised and remaining assets moved to a newly created wallet using a trusted device or official application.
The appropriate response therefore depends on the evidence. Exposed order data calls for heightened scepticism and identity protection. Shared wallet secrets call for immediate wallet replacement.
The address changes the threat model
A shipping address linked to a hardware-wallet purchase is not ordinary fulfilment data. It combines identity, location, contact channels and a strong signal that the person may control cryptocurrency.
That bundle supports attacks with much more context than a generic email list:
- a fake firmware-update message that names the product ordered;
- a convincing replacement-device or recall notice;
- a telephone call that already knows the customer’s address and purchase date;
- a letter or parcel designed to look like an official hardware-wallet delivery;
- a refund or delivery-failure lure tied to the real order;
- impersonation of customer support using the correct phone number and email address; and
- physical targeting based on the belief that valuable assets are held at the delivery location.
Not every affected customer will face every scenario, and an address does not prove that cryptocurrency is stored at that location. The attacker does not need certainty. The dataset allows them to prioritise people for whom the story is more plausible than a random target.
This is why “the private keys were safe” is necessary but incomplete. Security is not only the secrecy of the cryptographic material. It is also the safety of the person who holds it.
Fulfilment systems inherit the sensitivity of the product
Order-processing tools are often treated as commerce infrastructure rather than part of the security boundary. They sit with logistics providers, plug-ins, customer-support platforms and retention workflows that are separated from the wallet product itself.
The data does not become low risk because it lives outside the wallet. Its sensitivity comes from the relationship between the record and the product.
A name and address for an ordinary household purchase may be useful to a scammer. The same fields attached to a hardware-wallet order can imply access to digital assets and familiarity with self-custody. Purchase details can reveal the device model, accessories and approximate time the customer began using it. That knowledge makes a technical support pretext far more credible.
Hardware-wallet vendors should therefore classify fulfilment data according to the harm created by the product association, not according to whether the database contains a seed phrase.
Retention became a security control
SafePal says it has tightened retention in the relevant order-processing environment to 90 days, subject to legal requirements. That is one of the most consequential changes in the disclosure.
Data cannot be exfiltrated from a service that no longer holds it. Shorter retention reduces the population available to a future attacker, limits the historical context attached to an account and narrows the evidence that an unauthorised plug-in request can return.
Retention should still be designed carefully. Legal, tax, warranty and fraud requirements may justify keeping some records. The answer does not need to be one complete order profile in one broadly reachable environment. Organisations can separate financial records from delivery operations, remove fields from active systems, tokenise references, restrict support access and delete plug-in copies before deleting the authoritative record.
The practical question is not, “How long can we keep this?” It is, “Which system still needs which field, for which purpose, and what harm does continued availability create?”
What SafePal customers should do now
SafePal says affected customers were emailed individually from security@safepal.com on 16 August with the subject [Important] Your SafePal Order Information Has Been Affected. Customers can also use the company’s dedicated incident page to check an order ID and shipping country.
Customers should assume that future contact may contain real order details.
- Never disclose a seed phrase, private key or wallet password. SafePal says it will not request them by email, telephone or any other channel.
- Navigate to SafePal manually. Type the official address or use a trusted bookmark instead of following links in messages, text messages, QR codes or letters.
- Treat unexpected hardware as hostile. Do not connect, initialise or recover a wallet on a device that arrives without a purchase you independently initiated and verified.
- Verify support through a separate channel. A caller knowing the correct address or order does not prove that they work for SafePal.
- Review account security. Change reused passwords, enable strong multi-factor authentication on the affected email account and watch for mailbox rules or recovery changes.
- Preserve suspicious contact. Keep the message, sender details, domain, telephone number, envelope or parcel information before reporting it through SafePal’s dedicated channel.
- Escalate physical concerns. If contact references the home address, threatens the customer or suggests in-person targeting, involve local law enforcement and review personal-safety measures.
SafePal says it has already identified and taken down more than 30 fraudulent websites and phishing links tied to scam activity. That number shows why customers should expect the incident to be used, not merely archived.
What hardware-wallet vendors should change
The incident has lessons beyond one plug-in.
- Remove order data from active fulfilment systems as soon as the operational purpose ends.
- Test every order-status and customer-support function for object-level authorisation failures.
- Prevent sequential or predictable identifiers from becoming a route to another customer’s record.
- Restrict plug-ins and logistics integrations to the minimum fields and time window they need.
- Log unusual order lookups, enumeration patterns and bulk access in a system the plug-in cannot alter.
- Use independent testing for customer-facing authorisation, not only wallet firmware and cryptography.
- Model phishing and physical harm when assessing incidents involving product ownership and location.
- Prepare customer notices that explain what not to do, especially unnecessary asset movement and seed entry.
The security review for a hardware-wallet company cannot end at the secure element. The order database, courier integration and support workflow all carry information that can move risk from the device to the owner.
What is confirmed and what is not
SafePal confirms the authorisation flaw, the affected order period, the approximate customer count and the exposed data types. It confirms that the issue was remediated, that affected customers were notified, that a third-party security review is being engaged and that the relevant retention period was reduced.
The company says it found no evidence that the incident compromised wallet access or funds. That is not a guarantee that no customer will lose funds through a later phishing or impersonation attempt. The follow-on attack would use the exposed context to persuade the customer to surrender the secret that SafePal did not store.
The incident is therefore a useful test of security language. “No private keys exposed” answers whether the order system contained the wallet’s cryptographic secret. It does not answer whether the exposed record can help an attacker reach the human secret-holder.
