Ordinary HEY user can make HEY originate authenticated mail from attacker-selected @hey.com addresses

How it was found

Summary

An ordinary HEY user can add an attacker-selected @hey.com identity as an external sender using unrelated, attacker-controlled SMTP credentials.

If the temporary external-account object is deleted immediately after enqueue, HEY delivers the queued message through its first-party infrastructure while retaining the claimed identity.

With Basecamp security/triage authorization, I reproduced this as:

The HEY Team <[email protected]>

The message was sent only to my owned Gmail and iCloud accounts. I did not authenticate to, access, or contact the actual support mailbox.

Proof of concept

This is the exact command used:

python3 poc.py \
  --attacker [email protected] \
  --attacker-password="$(gopass show -o com.hey.app.ios/[email protected])" \
  --spoof [email protected] \
  --sender-contact-name "The HEY Team" \
  --subject "The HEY Team authorized PoC" \
  --message "Authorized inert PoC for HEY sender authorization; no action requested." \
  --recipient [email protected] \
  --recipient [email protected] \
  --smtp-host mail.kamil.gr \
  --smtp-user [email protected] \
  --smtp-password="$(gopass show -o mail/kamil.gr/test)" \
  --authorization-reference BASECAMP-RETEST-001 \
  --confirm-authorized-scope

The PoC:

1. Authenticates as the ordinary attacker HEY account.
2. Creates a temporary external account claiming [email protected] using the unrelated [email protected] SMTP credentials.
3. Enqueues one inert message using [email protected] as the acting sender.
4. Deletes the temporary external account before asynchronous dispatch.
5. Confirms cleanup and revokes the temporary session.

No [email protected] password or mailbox access is used.

Observed result

Both owned recipients received the message in Inbox displaying:

• From: The HEY Team <[email protected]>
• Subject: The HEY Team authorized PoC
• Body: Authorized inert PoC for HEY sender authorization; no action requested.

The server-side evidence recorded:

• Temporary external-account object: 286484
• Existing protected support sender/contact: 217762979
• Accepted message request: e0d53752-61a8-420d-b6c4-a383aa32f9a9
• One message submission and one deletion
• Deletion approximately 0.797 seconds after submission
• Confirmed removal of the temporary external account
• Zero writes or deletions against HEY's protected support Contact

A separate raw-EML reproduction using my owned [email protected] account confirmed the same delivery path produced:

• Exact claimed address in From and Return-Path
• No Sender or Reply-To
• HEY DKIM signature d=hey.com; s=heymail
• SPF, DKIM, and DMARC pass
• Gmail and iCloud Inbox placement

Keeping the external-account object caused delivery through the configured relay. Deleting it before dispatch caused HEY first-party delivery while retaining the claimed HEY identity.

Expected result

HEY should reject any attempt to configure an @hey.com sender that does not belong to the authenticated account.

If sender authorization disappears after enqueue, delivery should be cancelled rather than fall back to HEY's infrastructure while retaining and signing the unauthorized identity.

Impact

This allows an ordinary HEY user to impersonate another HEY user or a trusted service identity such as:

The HEY Team <[email protected]>

The attacker needs no password, session, or mailbox access for the impersonated identity. Because HEY itself delivers the message, recipient systems can treat the unauthorized identity as authenticated hey.com mail.

This breaks HEY's per-user sender-authorization boundary and enables highly credible phishing using HEY's own support identity.

Email spoofing is in scope for HEY based on Program guidelines

PoC attachments

• Standalone PoC script: ████████
• Video demonstration: ████████

████████