An email can pass normal authentication checks and still be a dangerous request for a secret. Trezor says attackers used its Brevo newsletter account to send a phishing message that asked recipients to download an app and enter their wallet backup. The message came from legitimate sending infrastructure after a security incident at Brevo; it was not evidence of a flaw in every Trezor device or of a compromise of Trezor wallets.
That distinction is important. Sender domains, SPF, DKIM and DMARC help establish that a message was sent through an authorized system. They do not prove that the human or system behind a particular request is authorized to receive a recovery secret. When the request is for a wallet backup, recovery phrase, password, API key or approval code, the safest response is to stop and begin a fresh verification path you control.
What is confirmed
Trezor says a September 9 incident at Brevo, its newsletter platform, allowed an unauthorized actor to send email from customer accounts including Trezor's. Trezor says its opt-in newsletter database of roughly 347,000 email addresses was affected, it suspended its Brevo account, and no other Trezor system was touched. It identifies the security-alert message as phishing and says its link prompted recipients to download an app requesting a wallet backup.
Brevo's post-incident report independently confirms a SAML SSO scoping flaw: it says an attacker reached 138 accounts, used six to send phishing email and exported contacts from 43 accounts. Brevo says it closed the entry path, signed out users and deployed a fix to restrict SSO access to the organization that owns the configuration. Trezor's initial post described 120 affected Brevo accounts; use Brevo's later 138-account figure for the provider-wide scope rather than treating the two figures as interchangeable.
What remains unknown
Public disclosures do not establish which individual Trezor contacts were exported, whether a particular recipient clicked the link or entered a backup, how many recipients were harmed, or whether this email-platform incident is connected to Trezor's separate ShipMonk shipping-provider breach. A sent phishing message is not proof that any wallet was drained. It is, however, sufficient reason to treat the affected address as likely reusable in later impersonation attempts.
How to handle an alarming message from a real sender
- Do not use the message's link, attachment or phone number. Close it and open the product's official app or type the known site address yourself.
- Never enter a wallet backup into a website or downloaded app prompted by an email. A backup is the authority to spend; a security notice does not need it to verify your device.
- Verify the claim through a separate channel. Consult the vendor's official status or support path that you opened independently. Ask support to confirm the alert without disclosing the backup, password or a recovery code.
- Preserve only the evidence needed for reporting. Save headers or a screenshot for the vendor's abuse channel if appropriate, but do not forward the malicious link widely or enter it into a shared ticket.
- Plan the recovery path before an incident. Record the approved contact route, device-recovery procedure and escalation owner. A rushed recovery decision is exactly what an authentic-looking message tries to exploit.
For teams that send sensitive requests
This is also a supplier-risk lesson. Inventory every vendor that can send from your domain, access contact lists or invite users through SSO. Require least-privilege roles, review account invitations and federation changes, keep an emergency sender-revocation procedure, and write customer notices that never ask for a password or recovery secret. Your recipients need an independent way to validate an urgent request when your usual mail channel cannot be trusted.
Where Secretus fits—and where it does not
Secretus can reduce plaintext exposure when an authorized team must deliver a small, temporary credential or approval code over a separately verified channel. It is not a wallet-recovery system, a customer-support verification service or a safe place for a complete wallet backup. Do not put a wallet backup in Secretus, email, chat, a ticket or any link-based sharing service; follow the wallet maker's independently verified, offline recovery guidance instead.