SafePal Order-Data Breach Turns Shipping Details Into Wallet Lures

SafePal disclosed on August 16 that an authorization flaw in an order-tracking plug-in allowed external access to other customers' order information. The affected population is approximately 39,798 customers who placed orders between March 2, 2025 and April 11, 2026. The exposed fields include names, email addresses, shipping addresses, phone numbers, and purchase details.

SafePal says the incident did not involve seed phrases, private keys, wallet passwords, other wallet credentials, bank accounts, payment cards, government identification, or evidence of access to wallets or funds. That boundary matters, but it does not make the breach harmless. A scammer who knows which wallet product someone bought and where it was delivered can build unusually credible support, refund, firmware, replacement-device, phone, text, and postal lures. Affected customers should protect the recovery phrase rather than move assets solely because order data was exposed.

SafePal's incident notice identifies a narrow but consequential system boundary. An authorization flaw in the order-tracking function for a plug-in associated with customer orders allowed unauthorized access to another customer's order information under certain conditions. SafePal says the flaw was fixed after discovery and that additional security measures were introduced. The company has not named the plug-in, its supplier, the exact request pattern, or whether authentication was required before one customer's record could be retrieved.

The disclosed population is approximately 39,798 customers whose order dates fall between March 2, 2025 and April 11, 2026. SafePal lists names, email addresses, shipping addresses, phone numbers, and purchase details as exposed. It says affected customers received individual email on August 16 from security@safepal.com. Those facts support an order-data breach affecting a defined customer cohort, but the order dates should not be mistaken for the attacker's access window. The public notice does not give the first access date, last access date, request volume, or complete log coverage.

SafePal expressly excludes seed phrases, private keys, wallet passwords, other wallet credentials, bank-account information, payment-card numbers, and government-issued identification. It also says it found no evidence that the incident itself compromised access to wallets or funds, and describes its cold-storage architecture as isolated from e-commerce servers. These are vendor statements about the investigated boundary. They justify avoiding claims that the hardware wallet was hacked, while leaving the independent security review and fuller timeline as unfinished work.

The incident has two causes with different security consequences. The authorization flaw enabled one party to reach an order record that did not belong to it. OWASP calls this class of problem broken object-level authorization when a service accepts an object identifier but fails to verify that the requester is allowed to act on that specific object. SafePal has not published enough technical detail to assign a formal category, but its description points to the same engineering requirement: every lookup must enforce ownership or policy on the server, regardless of whether an identifier looks random.

The second failure changed how much historical data was available. SafePal says a scheduled cleanup process stopped working correctly between September 2025 and April 2026 because of a configuration error. Older order records therefore remained in the system longer than intended. The company says this did not cause unauthorized access, but explains why the affected order range reaches back to March 2025. SafePal has since shortened the relevant retention period to 90 days, subject to legal requirements, and retained a secured offline copy of affected records for investigation support.

A sound fix must address both paths. The order endpoint needs object-level authorization tests for every read and field returned. The data pipeline needs monitored deletion jobs, retention exceptions with owners and expiry dates, and proof that records disappear from searchable production systems and replicas when the deadline passes. A successful cleanup dashboard cannot compensate for weak authorization, and a correct authorization check cannot justify keeping sensitive shipping history indefinitely.

A hardware-wallet order links an identifiable person and address to an interest in self-custodied cryptocurrency. Purchase details may help an impersonator choose a believable device, accessory, warranty, shipment, or firmware story. A phone call can cite the product, an email can offer a refund, a text can claim a delivery problem, and a physical letter can present a QR code for a supposed security check. None of that data grants wallet access by itself. Its value is that it makes the request for the actual secret feel specific and timely.

SafePal says it has identified and taken down more than 30 fraudulent websites and phishing links tied to scam activity. The company warns about fake support messages, firmware-update requests, refund offers, malicious sites, unexpected calls, letters, and hardware deliveries. It also says its staff do not initiate phone calls and never request a recovery phrase, PIN, private key, or password. Customers should use those behavioral rules, not a display name, sender address alone, order number, caller ID, or knowledge of a delivery address, to judge a contact.

Physical address exposure also changes the channel. Email filters cannot stop a convincing letter or an unsolicited package. Treat any replacement device or recovery card that arrives without a request as hostile until independently verified. Do not connect the device, scan an enclosed code, install software, or enter a phrase. Contact SafePal through a manually typed address or an existing trusted support record, and preserve the packaging and message if reporting is necessary.

For customers who only received the breach notice, SafePal says there is no need to replace the hardware wallet or move assets. That is the proportionate starting point. Verify affected status through a manually entered SafePal address, keep the notice for records, strengthen email and mobile-account protections, and warn household members or staff who might receive a call or package. Do not follow an incident email link simply because the sender and subject match the vendor's notice.

The decision changes immediately if a recovery phrase or private key was typed, spoken, photographed, uploaded, or scanned into an untrusted workflow. At that point the old wallet secret should be considered copied. SafePal advises creating a new wallet on a trusted SafePal device or official application and moving remaining assets. Do not create the new wallet from the exposed phrase, and do not accept migration instructions from the person who initiated contact. Record relevant addresses and transaction identifiers before reporting the loss or attempted theft.

If a lure obtained only an account password, email session, remote-device access, or installed application, contain that compromise on its own evidence. Revoke sessions, reset affected credentials from a clean device, inspect mailbox rules and downloads, and remove unauthorized remote access. A hardware wallet can preserve signing boundaries while the surrounding computer, phone, email account, browser, or support process is compromised. Response therefore has to follow the data and access actually surrendered.

E-commerce data is often treated as operational rather than security-sensitive. For a hardware-wallet seller, order history creates a target list for people likely to control crypto assets. The order-tracking surface should therefore receive the same basic scrutiny as an account API: explicit authorization for every object, response schemas that return only required fields, rate and enumeration controls, alerting for sequential or high-volume lookups, and tests that try to retrieve records across customer boundaries.

Minimizing fields is separate from controlling objects. A tracking page may need a delivery state but not a full address, phone number, email address, or product history after the purchase flow has completed. OWASP's object-property guidance recommends returning only properties required by the business function rather than serializing an entire backend record. Tokenizing tracking access, limiting its lifetime, and separating warranty records from live delivery details can reduce the payoff even when another control fails.

Retention also needs observable enforcement. SafePal's failed cleanup job shows why a written policy is insufficient. Operators should measure eligible records, deleted records, exceptions, replica lag, backup handling, and job failure age. Alerts should reach an owner before months of data accumulate. Vendors should also ask logistics and fulfillment partners to document their copies and deletion rules, while avoiding claims that a partner was breached unless the investigation proves it. SafePal says it contacted those partners and has so far found no evidence that the issue extended to their systems.

SafePal says a report consistent with the issue arrived in early May and was initially treated as isolated. It escalated the matter into a formal investigation, added protections, began a full review and rebuild of the order-processing pipeline in July, and then confirmed the root cause. An independent security firm is being engaged to validate the fix and review the wider order-processing system. That sequence explains the delayed disclosure but does not yet establish when unauthorized access began or ended.

A useful follow-up should publish the access prerequisites, affected endpoint and fields, first and last confirmed unauthorized request, total record and request counts, logging limitations, method used to identify the 39,798 customers, and evidence supporting the boundary around logistics partners and wallet systems. It should also distinguish the May user report, subsequent scam activity, and any confirmed exploitation evidence. Taking down fraudulent sites does not by itself prove which operator accessed the records or how every site obtained its targets.

Customers should watch for those updates without waiting to adopt the core rule: no legitimate support process needs the recovery phrase or private key. The cryptographic boundary can remain intact while the commercial data around a device becomes an attack tool. SafePal's incident is therefore best understood as an identity and social-engineering risk created by an order-system failure, with wallet compromise occurring only if an attacker succeeds in crossing the separate human secret boundary.