Foundation reports over 23,000 phishing attempts after email system compromise
News
Published 26 Oct 2026
Updated 26 Oct 2026
7 min read
Summarize with
October 26, 2026
Foundation, the maker of Passport Bitcoin hardware wallets, says attackers exploited a vulnerability in a self-hosted application, reached backend systems and obtained email credentials. The company has identified more than 23,000 phishing attempts across its email systems. Its official incident notice says attackers could send legitimate-looking email and likely access its support inbox.
The investigation has also identified reachable customer contact records, including approximately 5,600 mailing addresses and 5,200 phone numbers. Those categories overlap. Neither those figures nor the email counts establish a unique victim total. Foundation reports no evidence that Passport devices or the private keys they hold were compromised.
What the phishing counts establish
Foundation published its notice at 08:00 UTC, followed by investigation updates at 15:40 and 18:53 UTC. Its account describes abuse of credentials accessible through its own compromised infrastructure. It does not establish that the email providers themselves were breached.
The company distinguished messages delivered through one service from messages sent through another. That wording matters when assessing the campaign's reach. Its reported figures are:
|
|
|
|---|---|---|
All email systems | Over 23,000 | Phishing attempts |
Mailgun | 19,057 | Delivered messages |
Google Workspace | 1,503 | Sent messages |
Foundation's reported email figures on October 26. Provider counts cover only part of the overall attempts.
The two named provider counts do not add up to the full attempt total. Foundation said some recipients received multiple messages, while some attempts failed or were stopped before delivery. Treating every attempt as a delivered email, or every message as a different person, would overstate what is known.
I would keep delivery scope separate from exposure scope: email activity measures the campaign, while evidence of access to stored records determines the data investigation. Neither is a count of people who followed a link or disclosed a recovery phrase.
Reachable records included older customer details
In its later same-day update, Foundation identified records containing approximately 5,600 mailing addresses and 5,200 phone numbers, alongside names and email addresses. The company could not confirm whether attackers accessed every reachable record, so it is treating all of those records as potentially exposed.
Foundation also said more than 5,000 recipient email addresses did not match its store customer records. It suspected outside data contributed to the recipient list, but the provenance remained under investigation. A mismatch with store records does not, by itself, establish where an address originated.
Contact categories overlap
A person's record can contain both a mailing address and a phone number. Adding 5,600 and 5,200 does not establish 10,800 distinct people. Potential exposure also does not mean confirmed access to every record.
The retention problem was broader than the visible store view. Foundation said legacy database copies and abandoned-cart records retained personal information despite redaction visible to administrators. Its account covered records associated with its former WooCommerce store and current Shopify store; it did not establish a platform-wide breach of either service.
For ecommerce teams, the immediate lesson is specific: verify redaction against underlying tables and retained copies. An admin screen showing blank customer details did not prove the information was erased everywhere.
Compromised sending access is an authentication blind spot
Sender authentication alone cannot stop abuse of compromised authorized sending credentials. SPF checks whether sending infrastructure is authorized for an envelope domain. DKIM verifies a domain's signature over signed message content. DMARC ties a successful SPF or DKIM result to the visible From domain under its domain-matching rules.
An attacker using an authorized sending account can submit harmful messages through infrastructure that already authenticates legitimate mail. That is a general technical possibility, not a finding about the headers in this incident. Foundation did not publish authentication headers proving that these messages passed SPF, DKIM or DMARC.
Domain impersonation
A sender outside the authorized mail system claims another organization's domain. Correctly configured authentication and an enforced DMARC policy help receivers reject that misuse.
Authorized account abuse
An attacker uses compromised access to a legitimate sending service. Credential revocation and sending controls address that access; a successful authentication result cannot establish benign intent.
Nothing in the published account establishes a failure of DKIM cryptography or theft of DKIM signing keys. Access to an email API credential is different from possession of a domain's signing key, even when a sending service signs submitted messages automatically.
Keep production SPF, DKIM and DMARC working during containment. A DMARC rejection policy targets messages that fail its checks; it does not revoke an API credential. Change DNS authorization when the investigation identifies an obsolete or unauthorized source, while checking required transactional routes.
Containment must include credentials and queued mail
Foundation said it revoked affected credentials and API keys, cleared queued phishing messages, took affected legacy services offline and preserved evidence. Its evening update said all keys and secrets were being rotated out of caution. Those are reported response actions, not confirmation that the investigation is complete.
For sending-domain owners and MSPs, I would prioritize the following actions after a comparable compromise. Each needs an owner, and restoration should depend on evidence that exposed access has been removed:
- Inventory access: Identify sending API credentials, application secrets and mailbox permissions, including access retained by legacy services.
- Revoke exposure: Disable compromised credentials and remove unnecessary permissions. Examine the application vulnerability before reconnecting it.
- Inspect queues: Suspend affected sending, preserve queue evidence and remove malicious pending messages before resuming approved traffic.
- Review logs: Examine provider and support-mail logs, including access and forwarding changes. Separate submission events from confirmed delivery.
- Preserve evidence: Retain relevant logs and system snapshots before cleanup removes the ability to reconstruct access and activity.
- Warn recipients: Use established channels to publish verified guidance. Check retention across underlying tables and legacy copies alongside the messaging response.
For recipients, accurate personal details do not make an email safe. Foundation warned that the messages sought recovery phrases. Never enter a wallet recovery phrase into a website or disclose it to someone claiming to be Foundation.
After containment, a DMARC checker can validate the published record. A test message through each restored sending route can then check its actual authentication behavior. Neither check proves an application or mailbox is free of unauthorized access.
Monitor restored sending without assuming a pass means safety
For MSPs managing transactional mail, recovery includes confirming which client domains each credential could send for. Review shared integrations and unexpected senders, and compare provider activity with the sources normally used by each domain. Abuse can occur within an existing source without introducing a new one.
A useful review connects a sending event with the application and credential responsible for it. Investigators should preserve message identifiers and timestamps so that queue entries, provider events and recipient reports can be compared. A familiar sending IP address does not identify who controlled the application, and a clean queue does not explain messages already sent.
Our platform, Suped, provides DMARC monitoring to review sending sources and investigate authentication failures. That workflow supports domain oversight alongside provider logs. Aggregate reports are not a complete activity log and cannot reliably identify malicious content sent through an otherwise authorized source. An authentication pass rate can stay high during such abuse because the sending route itself has not changed.
Suped's email tester lets an operator send a real message and inspect authentication after restoring a route. Use that result as a delivery check alongside the credential review, rather than treating a passing result as proof the incident is resolved.
The investigation still has distinct questions to resolve
By Monday evening, Foundation had described containment actions and identified categories of potentially exposed contact information. The number of unique people affected, the extent of actual record access and the origin of unmatched recipient addresses remained unresolved in its same-day updates.
Foundation said it would continue publishing confirmed findings. Until those questions are resolved, message totals and reachable-record categories should remain separate figures. Its finding of no evidence of compromised Passport devices or private keys should also remain distinct from the continuing investigation into email and customer information.
Frequently asked questions
Foundation reported more than 23,000 phishing attempts, not unique people. Some recipients received multiple messages and some attempts failed or were stopped. The company had not confirmed the unique number of people whose information was exposed.
The published notice did not include authentication headers establishing that result. Compromised authorized sending access can produce authenticated mail, but that technical possibility does not prove these particular messages passed SPF, DKIM or DMARC.
Foundation could not confirm full access. It treated the reachable records as potentially exposed. The mailing-address and phone-number categories overlap and must not be added together as a count of distinct people.
Foundation reported no evidence that Passport devices or their private keys were compromised. Its warning focused on phishing messages intended to obtain recovery phrases, which recipients should never disclose through a website or to a purported support representative.
