Compromised Phrase accounts sent phishing through notification emails
News
Published 6 Nov 2026
Updated 6 Nov 2026
5 min read
Summarize with
Phrase disclosed on November 6, 2026 that attackers had used compromised user accounts to send phishing through its notification emails. The company's public postmortem dates the incident to late August through October 2026. The November 6 UTC disclosure, November 7 in Sydney, describes that earlier activity.
Phrase said the attackers used valid credentials compromised outside Phrase. They abused user invitations and custom email templates. The company reported no evidence that its infrastructure was breached or that its email delivery service credentials leaked; it rotated those credentials as a precaution.
How the attackers used notification emails
According to Phrase, attackers logged into existing application accounts with correct usernames and passwords. The account compromise described was access to Phrase, not a finding that users' email accounts had been breached.
Once signed in, the attackers used normal application workflows to reach external recipients. The distinction matters: a service-generated email still needs checks on who requested it, its recipients and its content.
User invitations
Compromised accounts sent normal user invitations to external email addresses, turning an account-management workflow into a way to distribute phishing messages.
Custom email templates
In Phrase TMS, attackers changed CC/BCC recipients, inserted phishing links and triggered notifications at high volume.
Some attackers also created additional accounts or organizations to retain access. That made containment broader than changing the original user's password: sessions, tokens and newly created access also needed investigation.
The incident timeline preceded the disclosure
Phrase's timeline records repeated abuse and successive restrictions during 2026. The September 14 activity involved high-volume template abuse; September 25-27 brought another path for inserting links into templates.
Its September 29 statement that there were no new confirmed intrusions was an assessment at that point. It should not be read as a current attack-status statement or substituted for the incident period described in the November disclosure.
|
|
|---|---|
Late August | First phishing reports |
September 14 | High-volume template abuse |
September 15 | Affected-organization password resets |
September 16-18 | Hourly sending limits introduced |
September 25-27 | New template link path; editing restricted |
September 29 | No new confirmed intrusions at that point |
October | Organization-wide 2FA enforcement available |
November 6 | Public postmortem published |
Selected milestones reported by Phrase. All dates are in 2026.
Phrase said it disabled compromised accounts, ended sessions, revoked attacker-created tokens and removed accounts or organizations created by attackers. It also reset passwords across affected organizations, rather than only for known compromised users.
Other completed mitigations included per-user and per-organization sending limits, restrictions on template CC/BCC recipients and external links, and disabling template creation and editing by default. Phrase also expanded activity logging and monitoring. These are reported actions already taken, separate from the general checks below.
Where DMARC's protection ends
When mail is sent through an authorized service, authentication can validate the sending domain even when an account or notification workflow has been abused. DMARC requires a passing SPF or DKIM result with the required domain match to the visible From address. It does not determine whether the request behind the message was legitimate.
SPF checks sending authorization for the envelope domain. DKIM verifies a domain's signature over signed message data. Neither establishes that a link is safe or that the person triggering a notification was the rightful account holder.
No published authentication verdicts
Phrase's postmortem provides no message headers or SPF, DKIM or DMARC verdicts. It does not establish that the phishing messages passed or failed those checks.
For a domain you administer, a DMARC checker checks the published policy. DMARC monitoring helps track receiving systems' reported authentication results. Neither replaces application audit logs or inspection of a suspicious message.
Checks for operators and security administrators
For SaaS and transactional-mail operators, service-wide sending totals are insufficient. Monitor invitations and notifications by tenant and account, including changes in the number of distinct external recipients.
The following are general controls, rather than claims about additional steps Phrase took. Email and security administrators should connect message evidence to application activity wherever logs are available.
- Sending volume: Alert on unusual invitation or notification rates per tenant and account. Apply limits that contain an individual account's abuse.
- Template changes: Audit edits to links and CC/BCC fields. Investigate unfamiliar external recipients and restrict who can change notification destinations.
- Account access: Enforce MFA or SSO. Review new users and organizations, restrict token permissions, and revoke suspicious tokens and sessions alongside password resets.
- Incident evidence: Preserve original messages with full headers and relevant logs. Retain timestamps, account identifiers and template-change history for correlation.
Verify unexpected requests independently
I would verify an unexpected notification through a known contact or by opening the service independently. A familiar sender name, or even successful domain authentication, is insufficient evidence for a request to enter credentials or make a payment.
Recipients should report suspicious notifications through a known support or security channel. Anyone who entered credentials should use the legitimate service to change the exposed password and have active sessions and account access reviewed.
Frequency asked questions
Phrase reported no evidence that its email delivery service credentials leaked and said it rotated them as a precaution. The disclosed abuse involved compromised Phrase user accounts.
The postmortem provides no message headers or authentication verdicts. Authorized-service abuse can coexist with passing authentication, but that general possibility is not a finding about these messages.
No. Phrase described notification abuse as the attackers' main focus. That does not support a blanket conclusion that content in every affected account was untouched.
Containment should also cover sessions, tokens and attacker-created accounts. Additional access can survive a reset of the originally compromised password.
