A data breach at logistics provider ShipMonk has significantly expanded the scope of an incident involving hardware wallet manufacturer Trezor.
Trezor has confirmed that information belonging to approximately 67,000 additional U.S. customers was exposed through ShipMonk. The newly identified records relate to orders placed between November 2019 and August 2021 and include names, email addresses, phone numbers, shipping addresses and order numbers.
The incident is a particularly important reminder that protecting sensitive customer information does not end with an organization's own infrastructure. Third-party logistics, analytics and other service providers can become an indirect path to customer data.
What happened?
Trezor first disclosed the ShipMonk breach in August, reporting that nearly 14,000 customers had been affected. That initial disclosure covered customers in several countries and included full or partial exposure of names, email addresses, phone numbers and shipping information.
On September 2, ShipMonk informed Trezor that the incident was considerably larger than initially understood.
The investigation identified approximately 67,000 additional U.S. customers whose historical order records were still present in ShipMonk's systems. These customers had ordered Trezor products during the company's previous relationship between November 2019 and August 2021.
This brought the known number of affected Trezor customers to more than 80,000 when the newly identified records are combined with the previously disclosed population.
The retention issue
One of the most significant aspects of the latest disclosure is not simply the age of the records, but why they were still available.
Trezor says it repeatedly requested confirmation from ShipMonk that historical customer data had been deleted and received written assurances that this had happened. The company says it was therefore surprised to learn that the older records remained in ShipMonk's systems.
Trezor has emphasized that the historical data came from the period when the companies previously worked together. The company also clarified that its current 90-day retention requirements were not contractually applicable to ShipMonk during the original 2019–2021 relationship, although Trezor says it subsequently requested deletion of the data.
This turns the incident into more than a vulnerability story. It is also a third-party data governance and retention failure.
How did attackers get in?
The technical starting point was a vulnerability in Metabase, an analytics and business intelligence platform used by ShipMonk.
The vulnerability is tracked as CVE-2026-72898 and is a critical SQL injection flaw. Security researchers reported that the vulnerability could be exploited without authentication and could provide attackers with administrator-level access to a vulnerable Metabase environment and its connected data.
The vulnerability was exploited as a zero-day before it was publicly disclosed and patched.
Researchers subsequently linked the Metabase vulnerability to several organizations that reported data exposure, including ShipMonk.
The attack demonstrates why analytics platforms deserve the same security attention as externally exposed business applications. Although Metabase may be viewed primarily as a reporting tool, it can have access to highly sensitive databases and business information.
Where ShinyHunters fits in
ShipMonk reportedly received extortion communications associated with ShinyHunters, and security researchers have linked the incident to the wider campaign exploiting the Metabase vulnerability.
However, it is important to distinguish between reported attribution and confirmed attribution.
Trezor has publicly confirmed the ShipMonk breach and the resulting exposure of customer data, but it has not publicly established that ShinyHunters was definitively responsible for the initial intrusion.
For that reason, the safest description is that the breach has reportedly been associated with ShinyHunters, rather than stating that Trezor has confirmed the group as the attacker.
What data was exposed?
For the additional 67,000 U.S. customers, the exposed information reportedly includes:
- Full name
- Email address
- Phone number
- Shipping address
- Order number
These details are particularly sensitive in the context of cryptocurrency hardware wallets.
The information does not give an attacker direct access to a Trezor wallet. However, it can provide extremely useful material for targeted social engineering.
An attacker who knows that someone purchased a hardware wallet can construct a much more convincing phishing message than one based on generic information.
For example, a criminal could pretend to be:
- Trezor support
- A cryptocurrency exchange
- A shipping company
- A security or compliance department
- A customer-service representative
The attacker could potentially reference the victim's name, previous order, delivery address or approximate purchase history to make the communication appear legitimate.
Trezor wallets were not compromised
This is an important distinction.
Trezor says the breach occurred at ShipMonk, not within Trezor's own systems.
The company has stated that its systems, products and services were not compromised and that the exposed logistics information does not include wallet seeds, private keys or wallet backups. Trezor has also warned affected users about phishing, fraudulent calls and letters and potential physical-security risks.
In other words, the incident exposed information about customers, not the cryptographic secrets that control their wallets.
That distinction is critical.
A leaked delivery address cannot by itself unlock a hardware wallet. But it can help an attacker identify a cryptocurrency holder and make subsequent social-engineering attempts considerably more convincing.
Why this matters beyond cryptocurrency
The Trezor incident illustrates a broader cybersecurity problem: an organization can secure its own infrastructure and still suffer a serious data breach through a third party.
Modern companies depend on a large ecosystem of suppliers:
- Logistics providers
- Cloud platforms
- SaaS applications
- Analytics platforms
- Payment processors
- Marketing platforms
- Customer-support systems
- Managed service providers
Each provider may have access to information that customers expect the primary company to protect.
In this case, an analytics platform became an entry point into data held by a logistics provider, which ultimately exposed information belonging to customers of another company.
That is a classic example of third-party and supply-chain risk.
What should organizations learn from the incident?
The incident provides several practical lessons for security and compliance teams.
✅ Know where customer data actually exists
A data inventory should not stop at databases operated directly by the organization.
Companies should know:
Who has our customer data?
What data do they have?
Why do they have it?
How long are they supposed to retain it?
✅ Verify deletion instead of simply trusting it
Contractual deletion requirements are useful, but organizations should consider how those requirements are verified.
A written confirmation is not necessarily evidence that data has actually disappeared from:
- Production databases
- Analytics databases
- Backups
- Data warehouses
- Reporting systems
- Development environments
Retention controls need technical and procedural verification.
✅ Secure analytics infrastructure
Metabase and similar platforms can have privileged access to corporate databases.
They should therefore be treated as security-sensitive infrastructure rather than ordinary reporting tools.
Organizations should review:
- Internet exposure
- Authentication requirements
- Database permissions
- Network segmentation
- Service-account privileges
- Patch management
- Logging and monitoring
✅ Minimize the data shared with suppliers
If a logistics partner only needs an address to deliver a package, it should not automatically retain years of historical customer information.
Data minimization reduces the potential impact of a breach.
✅ Prepare customers for targeted phishing
When names, addresses and purchase history are exposed, generic security advice is not enough.
Affected users should be warned specifically that attackers may know they own a particular product.
For Trezor users, the fundamental rule remains simple:
Never provide a wallet recovery seed, backup or private key to anyone.
A legitimate support representative should never need those secrets.
What Trezor customers should do
Customers who received notification of exposure should be particularly cautious about unexpected communications.
Be suspicious of messages that:
- Mention your Trezor purchase
- Reference your delivery address
- Claim your wallet needs to be "verified"
- Ask you to enter a recovery seed
- Ask you to install software
- Request cryptocurrency transfers
- Direct you to a website that looks like Trezor but uses an unfamiliar domain
The exposure of shipping information does not mean that customers need to move their cryptocurrency simply because their address was leaked.
The greater immediate concern is social engineering.
Final thoughts
The Trezor and ShipMonk incident demonstrates how a vulnerability in an apparently secondary system can eventually expose highly sensitive customer information.
The technical attack began with a critical Metabase vulnerability, but the broader story involves something equally important: third-party access, data retention and supply-chain security.
Trezor's hardware wallets and core systems were not compromised, and there is no indication from the confirmed disclosures that wallet seeds or private keys were exposed. Nevertheless, the combination of names, contact information and physical addresses creates a valuable dataset for targeted fraud and social engineering.
Protecting customer data means securing the entire ecosystem around your organization—not just the systems you directly operate. A supplier's database, analytics platform or forgotten historical archive can become the weakest link in the security chain.
