SafePal Data Breach Exposed 39,798 Customers: The Wallets Were Not the Weak Point
Introduction
SafePal has disclosed a data breach affecting approximately 39,798 customers who purchased its products between March 2, 2025 and April 11, 2026. Names, email addresses, phone numbers, shipping addresses and purchase details were accessed without authorization through a flaw in an order-tracking component.
The first fact to establish is also the one most likely to be lost in an alarming headline: SafePal has not reported a compromise of its hardware wallets, private keys or recovery phrases. According to the company, the incident was isolated to its ecommerce and order-processing environment, while the systems responsible for wallet credentials and cold storage remained separate. SafePal says it found no evidence that the vulnerability itself provided access to customer wallets or funds.
That distinction is technically important, but it does not make this a minor breach.
For someone buying an ordinary consumer product, leaked order information may primarily create identity-theft and phishing risk. For someone buying a cryptocurrency hardware wallet, the same information can reveal something more valuable to an attacker: this identifiable person, at this physical address and phone number, is sufficiently involved in cryptocurrency to purchase dedicated self-custody hardware.
What stood out to me while reviewing the disclosure is that this incident demonstrates how the security of a crypto holder can fail outside the wallet itself. An attacker may never defeat the Secure Element, extract a private key or exploit the device firmware. If they can identify the owner, learn exactly what that person bought and construct a convincing enough story to make the owner reveal a recovery phrase, the cryptography can remain intact while the assets disappear.
SafePal's own incident response reinforces that risk. The company says it has already identified and taken down more than 30 fraudulent websites and phishing links associated with scam activity, and public reports show SafePal customers were receiving unusually targeted impersonation attempts as early as May 2026.
This is therefore not just a story about an ecommerce plug-in. It is a case study in how metadata surrounding a hardware wallet can become part of the attack surface.
Is your cellphone vulnerable to SIM Swap? Get a FREE scan now!
Please ensure your number is in the correct format.
Valid for US numbers only!
SafePal Data Breach at a Glance
What Actually Failed at SafePal?
SafePal says the incident originated in an authorization flaw in the order-tracking function of a plug-in associated with customer order information. Under certain conditions, the defect allowed information belonging to another customer to be accessed without authorization. SafePal says it remediated the flaw after identifying it and added further security measures.
There is not yet enough public technical information to precisely reconstruct the exploit.
The behavior is consistent with the broad class of application-security problems commonly called Insecure Direct Object Reference, or IDOR, and Broken Object Level Authorization, or BOLA. In those vulnerabilities, an application may successfully locate an object such as an order but fail to establish that the person requesting it is actually authorized to view that particular order.
However, SafePal has not publicly released a technical postmortem identifying the exact vulnerability class, request format or exploitation method. We therefore should not treat IDOR or BOLA as a confirmed diagnosis.
Several important questions remain unanswered. SafePal has not publicly identified the plug-in developer, explained whether authentication was required, said whether order identifiers could be systematically enumerated, described how much information a single request revealed, or published forensic indicators showing how attackers extracted the records.
The company has also not publicly established when exploitation first began, how many external parties accessed the vulnerable system or whether the customer information was acquired through automated bulk collection or repeated access to individual orders.
Those are meaningful evidence gaps. They do not establish that the breach was larger than SafePal says, but they limit what can currently be concluded about the attack itself.
The Hardware Wallet Was Not Compromised, but the Customer Was Identified
SafePal is a non-custodial wallet provider offering hardware and software wallets. Its hardware products are designed around the premise that sensitive wallet credentials remain under the user's control rather than being stored in the company's ecommerce environment.
SafePal says the compromised system did not contain seed phrases, private keys, wallet passwords, bank-account information, payment-card numbers or government-issued identification. Its incident FAQ states that the order-tracking plug-in operates independently from its wallet systems and that it found no evidence the incident itself compromised access to wallets or funds.
The available public evidence supports a narrower conclusion than saying "SafePal wallets were hacked." There is currently no evidence of that.
The security problem instead moves from key compromise to owner compromise.
Consider what the exposed dataset can tell an attacker when the fields are combined:
- the victim's name;
- their email address;
- their telephone number;
- where they receive physical deliveries;
- the fact that they purchased cryptocurrency hardware;
- potentially which SafePal product they purchased.
None of those fields can sign a blockchain transaction. Together, however, they can make a fraudulent interaction extraordinarily convincing.
An attacker can claim that the customer's exact hardware model has been recalled, that a particular batch contains a firmware problem, that the customer is entitled to a refund, or that a replacement device is being shipped. The criminal can reinforce the story by reciting the victim's actual purchase information.
The objective is then to obtain the one piece of information SafePal never possessed in the first place: the recovery phrase or private key.
This is why self-custody security cannot be evaluated only by asking whether a hardware device can resist remote exploitation. The human being operating the wallet is also part of the security boundary.
Warning Signs Appeared Months Before SafePal's Public Disclosure
SafePal disclosed the incident publicly on August 16, 2026, but the company's FAQ acknowledges that it received a report consistent with the eventual issue in early May.
SafePal says it initially treated the report as an isolated case. Because its ecommerce environment involved multiple connected components, external integrations and third-party logistics providers, the company says it could not immediately determine the source. It later escalated the matter into a formal security investigation and introduced additional protections.
In July, according to SafePal, the company began a full review and rebuild of its order-processing pipeline. That process led it to confirm the authorization flaw that is now identified as the root cause. SafePal also says it contacted logistics and fulfillment partners during the investigation and has found no evidence that their systems were breached as part of this incident.
The timing matters because reports of highly personalized SafePal impersonation had already begun circulating.
BleepingComputer and Help Net Security documented a customer report from May involving communications from someone impersonating SafePal. The reported contact included a phone call and fraudulent messages claiming that a SafePal hardware wallet faced a security problem and required corrective action. Help Net Security notes that the customer also reported receiving physical correspondence.
There is an important evidentiary limitation here. Public reporting has not conclusively established that this specific phishing campaign was using information obtained through the now-disclosed vulnerability. Help Net Security explicitly notes that the connection remains unconfirmed.
The overlap is nevertheless difficult to dismiss as irrelevant. The impersonation occurred during the period SafePal was receiving incident-consistent reports, and the attackers reportedly possessed information similar to the order data SafePal later confirmed had been exposed.
That leaves a legitimate incident-response question: how long were attackers able to exploit the information before affected customers were warned about the wider risk?
SafePal's public material explains why the investigation took time, but it does not yet provide a detailed chronology showing when the flaw was first technically confirmed, when it was patched, how investigators determined the number of affected customers, or how exploitation evolved between the first May report and the August disclosure.
A future independent incident report could answer those questions.
A Separate Data-Retention Failure Increased the Potential Blast Radius
The authorization flaw was not the only control that failed.
During its investigation, SafePal says it discovered that a scheduled data-cleanup process had stopped operating correctly between September 2025 and April 2026 because of a configuration error.
SafePal is explicit that this configuration error did not create the unauthorized-access vulnerability. Instead, it caused older customer records to remain in the ecommerce system longer than intended. According to the company, that is why affected records extend as far back as March 2025.
These should be understood as two separate security failures.
The authorization weakness created a path through which one customer's information could become accessible to an unauthorized party. The failed retention mechanism increased the quantity and age of the data that remained available behind that vulnerable access path.
This is a useful example of why data minimization is a security control, not merely a privacy-policy issue.
Deleting information that no longer needs to be online reduces the potential damage from future software vulnerabilities, compromised credentials, malicious insiders and third-party failures. A company cannot leak from an active ecommerce database a record that has genuinely been removed from that environment.
For crypto hardware vendors, that principle has an additional dimension. An old shipping record may no longer be operationally valuable to the company, while remaining highly valuable to a criminal because a person's home address and association with cryptocurrency can remain useful for years.
SafePal Had Already Recognized This Risk After the Ledger Breach
The retention issue becomes particularly noteworthy when viewed against SafePal's own historical privacy guidance.
In December 2020, after Ledger's major 2020 ecommerce breach had focused the crypto industry's attention on ecommerce privacy, SafePal published guidance explaining how it handled hardware-wallet order information. The archived SafePal support entry said fulfilled hardware-wallet order information would be kept for 30 days and then destroyed from its online system through a monthly deletion mechanism.
SafePal's current disclosure says it has now shortened personal-information retention in the relevant order-processing environment to 90 days, subject to applicable legal requirements.
Those statements should not automatically be treated as evidence that SafePal violated a continuously applicable 30-day policy. Six years passed between the 2020 guidance and this incident, and companies can change retention requirements, ecommerce architecture and warranty processes.
The public evidence we reviewed does not establish when SafePal's retention policy changed from the 30-day approach described in 2020, what period immediately preceded the breach, or why the new 90-day limit is described as a reduction.
That history does, however, create a reasonable accountability question.
SafePal understood at least as early as 2020 that retaining hardware-wallet customer information increased risk and publicly described automated deletion as a mitigation. In 2026, the company discovered that the cleanup control itself had stopped functioning correctly for months.
The larger lesson is that having a deletion policy is not the same as verifying that deletion is actually taking place. A high-risk dataset needs monitoring around the controls intended to destroy it, because silent failure can turn a short retention period into a much longer exposure window.
SIM Swap Protection
Get our SAFE plan for guaranteed SIM swap protection.
Someone Is Already Claiming to Sell the SafePal Data
The incident may also have moved beyond private exploitation.
A threat actor has reportedly advertised what they claim is SafePal's stolen customer information on a cybercrime forum. According to BleepingComputer and Help Net Security, the seller cited the same approximately 39,798-customer count and affected order period disclosed by SafePal.
The seller reportedly offered prospective buyers sample order IDs and shipping countries that could be checked against SafePal's own breach-verification tool. That creates circumstantial support for the claim because SafePal's tool allows customers to check affected orders using those fields.
It is still important not to turn circumstantial evidence into confirmation.
BleepingComputer states that it has not independently verified that the seller possesses the stolen database, and Help Net Security similarly reports that authenticity has not been confirmed.
Until an independent party validates samples, SafePal confirms the listing, or the database becomes otherwise verifiable, the sale should be treated as a threat-actor claim.
If the claim is authentic, however, the long-term consequences change significantly. Fixing the vulnerable plug-in closes the original access path, but it cannot revoke copies of personal information already downloaded and redistributed.
A database can be resold, merged with other leaks and revisited years later by criminals who were never involved in the original intrusion.
Why Hardware-Wallet Customer Data Is Different From Ordinary Ecommerce Data
A home address does not normally tell an attacker how wealthy someone is.
A hardware-wallet purchase creates an inference.
Someone who buys a dedicated self-custody device may hold only a small amount of cryptocurrency, and purchasing a wallet does not prove wealth. That distinction should be respected.
From an attacker's perspective, however, the dataset has selection value. It filters a large population down to people known to have demonstrated an interest in protecting digital assets.
This can make the data more operationally useful than an ordinary retail mailing list.
An attacker can potentially use it for several overlapping campaigns.
Highly personalized phishing
Instead of sending a generic "your crypto wallet is at risk" message, a criminal can reference the correct brand and purchase history. The message may claim that the victim's device needs an urgent update, replacement or verification process.
The technical objective remains the same as in many crypto phishing campaigns: persuade the user to disclose a recovery phrase, approve a malicious transaction or interact with a fraudulent website.
Voice phishing and customer-support impersonation
The exposed telephone number allows the same pretext to move from email into a phone call.
SafePal's current guidance states that employees do not initiate phone calls to customers, which gives affected users a clear rule: an unsolicited caller presenting themselves as SafePal should not be trusted merely because they know legitimate order information.
Physical mail and fake replacement devices
SafePal also warns customers about letters, unexpected hardware deliveries and QR codes sent through the post. It says SafePal does not send physical letters and advises users to treat unexpected deliveries referencing their SafePal purchase as suspicious.
This matters because physical correspondence carries a different psychological weight from spam email. A letter delivered to the correct home address containing accurate purchase information can appear far more credible.
Mobile-account and recovery attacks
A leaked phone number does not mean a SIM swap has occurred, and there is currently no public evidence showing that SafePal customers have been SIM swapped as a direct consequence of this breach.
The information can nevertheless become part of the reconnaissance used for mobile-account takeover.
SIM-swap attackers frequently build identity profiles from data breaches, public records and social information before attempting to impersonate a victim to a carrier. Full name, email, mobile number and physical address are useful pieces of that profile. Efani's own SIM-swap analysis explains how leaked identity information is combined before attackers target carrier support and account-recovery workflows, the same mechanism that makes why crypto investors need ironclad SIM swap protection for exactly this population.
For a crypto holder, loss of the phone number can then affect email accounts, exchanges and other services that still use SMS or telephone-based recovery.
Physical targeting
The most serious risk requires the most careful language.
A dataset connecting real-world identities and home addresses with hardware-wallet purchases could assist physical reconnaissance, burglary, extortion or coercion against selected individuals.
There is currently no public evidence establishing that SafePal customers have been physically attacked because of this incident.
The risk is nonetheless credible enough that SafePal itself advises customers concerned about physical safety to contact local authorities and tells users to treat suspicious contact arriving by phone, post or in person as potentially malicious.
For high-net-worth crypto holders, that possibility should be considered as part of the threat model without exaggerating it into a confirmed outcome.
Monthly
Yearly
The Attack Can Succeed Without Breaking the Wallet
The operational lesson is straightforward.
Imagine that a criminal knows your name, address, telephone number and exact SafePal purchase. They contact you several months later and claim that your particular model was shipped with a critical firmware issue.
They know when you ordered it.
They know where it was delivered.
They may even know enough about legitimate SafePal processes to make the communication look authentic.
The attacker sends you to a convincing SafePal imitation and asks you to "verify" or "restore" the wallet with your recovery phrase.
If you enter those words, the hardware wallet does not need to be physically compromised. The attacker can recreate the wallet elsewhere using the secret you voluntarily supplied.
SafePal's remediation guidance reflects exactly this distinction. Customers whose order data was exposed do not need to replace their hardware wallet or move their assets solely because of the breach. Anyone who has already disclosed a seed phrase or private key in response to suspicious contact, however, should treat the wallet as compromised and migrate remaining funds to a newly generated wallet.
Hardware wallets remain valuable because they reduce important classes of remote key theft. They do not solve phishing, telecom compromise, identity exposure, coercion or every form of operational failure surrounding the owner.
Security has to account for the whole system.
SafePal's Response So Far
SafePal says it has taken several measures since identifying the incident.
The company says it has fixed the authorization flaw, strengthened access controls and reduced retention of personal data in the relevant order-processing environment to 90 days. It has notified affected customers, contacted logistics and fulfillment partners, opened a dedicated incident-support channel, engaged external legal counsel and started working with an independent security firm to validate the remediation and conduct a broader review.
SafePal has also built an online tool that allows customers to check whether an order was affected using the order ID and shipping country. Its incident page allows customers to request removal of sensitive order information including name, email address, shipping address and phone number, while SafePal retains the order number and shipping country for warranty and after-sales purposes.
For records affected by the incident, SafePal says it has retained a secured offline copy for potential investigative purposes. This is an important context when interpreting the company's deletion policy: the affected dataset has an investigative retention exception rather than disappearing entirely.
SafePal also says it is contacting on-chain asset-tracing specialists in connection with customers who believe they suffered financial losses. The company explicitly states that this process does not represent an admission of liability or a commitment to compensation.
At the time of writing, Efani has not found a reliable public figure establishing how much cryptocurrency, if any, has been stolen as a direct consequence of the SafePal breach.
The independent security review is also not yet public. SafePal says a third-party firm is being engaged to verify the fix and review the wider order-processing environment. Until that work is published, it should be described as an ongoing validation effort rather than independent confirmation that every relevant weakness has been resolved.
SafePal Is Not the Only Hardware-Wallet Company Facing This Problem
The timing of SafePal's disclosure makes the wider industry context difficult to ignore.
Only days earlier, Trezor disclosed a separate customer-data breach involving shipping provider ShipMonk. Trezor said approximately 13,689 customers were affected, with exposed information including names, email addresses, telephone numbers and shipping addresses.
The technical causes are different.
SafePal attributes its incident to an authorization flaw in its order-tracking environment. Trezor says its own systems were not the breach point and that unauthorized access occurred at a logistics provider. Treating the two incidents as identical would therefore be inaccurate.
The outcome is strikingly similar: people who purchased cryptocurrency hardware became identifiable through the commerce and fulfillment infrastructure surrounding the device.
There is also an important contrast in data retention.
Trezor says its affected population was limited by a 90-day retention policy that it also required its fulfillment partners to follow. Older order records had been deleted or anonymized and therefore were not present in the compromised ShipMonk environment.
SafePal, meanwhile, says its cleanup process malfunctioned and allowed older records to remain available.
That comparison demonstrates data minimization in practical terms. It does not prevent the initial breach, but it can materially restrict how many people are exposed when a breach occurs.
The industry has seen this problem before.
Ledger's major 2020 ecommerce breach ultimately exposed approximately 272,000 detailed customer records, including names, postal addresses and telephone numbers, in addition to more than one million email addresses. Ledger subsequently documented aggressive phishing campaigns targeting customers after the database became public.
The recurring pattern should concern the hardware-wallet industry.
Self-custody decentralizes control of the private key, but buying the physical device can create a centralized record of the person purchasing it.
The wallet may be offline.
The customer database is not.
What SafePal Customers Should Do Now
Affected customers should first determine whether their order is included in the incident. SafePal says it emailed impacted customers on August 16 from [email protected], but because criminals are actively impersonating the company, the safest approach is to manually type SafePal's official web address into the browser and navigate to its incident-verification page rather than relying on links in unexpected messages. SafePal itself recommends manually navigating to its domain.
Beyond that immediate check, the appropriate response depends on the user's exposure and threat model.
- Assume unsolicited SafePal contact is potentially fraudulent. SafePal says it does not initiate customer phone calls and does not send physical letters. Accurate order information should no longer be considered evidence that the caller or sender is legitimate.
- Never enter a recovery phrase into a website. Firmware updates, refunds, replacements, investigations and customer-support cases do not require disclosure of the seed phrase. SafePal says it will never ask customers for a recovery phrase, private key or PIN.
- Do not replace a functioning hardware wallet solely because your order data leaked. SafePal says the vulnerability did not expose wallet credentials or firmware. Moving assets unnecessarily can itself introduce operational risk. The exception is anyone who has already disclosed wallet secrets to a suspected attacker.
- Harden the exposed phone number. Review carrier authentication, account PINs, SIM-change controls and port-out protections. High-risk users should also reduce their dependence on SMS for recovery of email, exchanges and financial accounts. Efani's crypto mobile security audit checklist covers the mobile side of that process.
- Review email and exchange recovery paths. A criminal who knows your email and telephone number may target accounts surrounding the hardware wallet rather than the wallet directly. Prefer phishing-resistant authentication such as hardware security keys or passkeys where supported.
- Consider the physical implications of the address exposure. This is especially important for public figures, founders, executives and high-value crypto holders. The appropriate response may include reducing visible evidence of crypto ownership, changing where future security products are delivered, reviewing home-security practices and separating sensitive assets from the residential location.
- Use structural controls for very large holdings. If compromise of one person or one recovery phrase can immediately authorize a catastrophic transfer, the architecture itself may deserve reconsideration. Multisignature arrangements, geographically separated credentials and institutional-grade authorization controls can force an attacker to compromise several independent layers rather than one individual.
The objective is not to respond to every breach by buying another security product. It is to make sure one exposed dataset cannot become the starting point for a chain that reaches your phone number, email, recovery mechanisms, private keys and physical location.
Hardware-Wallet Vendors Need to Treat Customer Identity as Sensitive Security Data
Hardware-wallet companies understandably spend enormous effort securing key generation, signing, firmware and device integrity.
The SafePal incident shows why the order database deserves comparable threat-model attention.
A hardware-wallet vendor holds unusual metadata. Its ecommerce platform can contain a list of people who have effectively self-selected as cryptocurrency users concerned enough about custody to buy dedicated hardware.
That information deserves aggressive minimization.
Order-tracking systems should apply strict object-level authorization. External integrations should receive only the minimum data required. Retention controls should be independently monitored rather than assumed to work. Fulfillment partners should be contractually bound to deletion requirements. Administrative access should be tightly controlled and logged.
Vendors should also consider whether every piece of order data needs to remain associated with an identifiable customer once delivery, return and warranty requirements have been satisfied.
There will always be practical and legal reasons to preserve some records, and those requirements vary by jurisdiction. The objective cannot simply be "store nothing."
The better question is:
What is the minimum amount of identifiable information that must remain accessible, for the minimum necessary period, and how quickly would we know if the deletion mechanism silently stopped working?
For a company serving cryptocurrency users, that is a security architecture question.
Where Mobile Security Fits After a Crypto Data Breach
The SafePal incident primarily occurred in the ecommerce, privacy and operational-security layers. A secure mobile carrier would not have prevented an authorization flaw in SafePal's order-tracking system, just as a hardware wallet does not prevent the exposure of a customer's shipping address.
The layers become connected once the exposed information is weaponized.
A phone number combined with a real name, email address and physical address can make carrier impersonation and account-recovery attacks more credible. Protecting the number against unauthorized SIM changes and port-outs therefore becomes one part of the post-breach response.
At Efani, our role is specifically the carrier and mobile-identity layer. That layer complements rather than replaces strong hardware wallets, secure email, phishing-resistant authentication, privacy controls and appropriate crypto-custody architecture.
For high-risk users, the useful security model is not to search for one product that prevents every attack. It is to make sure the compromise of one layer cannot automatically compromise the next.
The Broader Lesson From the SafePal Breach
SafePal's strongest security claim after this incident is also technically important: based on the evidence available today, the company's hardware wallets and customer private keys were not breached.
I think the more important lesson is what happened around them.
A weakness in an order-tracking component exposed the identities and physical locations of almost 40,000 hardware-wallet customers. A separate cleanup failure meant older information remained available longer than intended. Reports of targeted impersonation appeared months before public disclosure. A threat actor is now claiming to sell the resulting dataset, although that claim has not yet been independently authenticated.
None of those events required breaking the cryptography protecting a hardware wallet.
That should change how crypto holders think about self-custody security.
A hardware wallet is designed to protect a private key. It does not erase the ecommerce record created when you purchased it, secure the phone number you entered at checkout, prevent an attacker from mailing something to your home, stop someone impersonating customer support, or decide whether you reveal your seed phrase to a convincing scammer.
Those are different security layers.
The SafePal breach is therefore not an argument against hardware wallets. Properly used hardware wallets remain an important defense against many forms of key theft.
It is an argument against treating the hardware wallet as the end of the threat model.
For people holding assets valuable enough to attract targeted attackers, security has to extend from the private key to the human identity around it, including the phone number, email account, shipping information, account-recovery workflows, physical environment and the operational decisions that connect them.
SafePal can patch the order-tracking flaw.
For customers whose information has already been copied, the more difficult task is making sure that information cannot be converted into access.
%20in%20Gmail.avif)
