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

HEY user adds attacker-chosen @hey.com sender via unrelated SMTP creds, deletes the external account before async dispatch, and HEY delivers DKIM-signed mail as that identity.

- Payout: not disclosed
- Severity: high
- Program: Basecamp
- Credited: gachikuku
- Disclosed: 2026-10-20
- Write-up quality: 8/10
- Original: https://hackerone.com/reports/4035023
- Library page: https://bugbountylibrary.com/r/h1%3A4035023
- Tags: domain:web impact:integrity kind:bounty platform:hackerone sev:high tech:email technique:race-window vuln:access-control vuln:auth-bypass vuln:misconfiguration

**Target:** HEY mail external-account/sender configuration and outbound dispatch
**Root cause:** HEY accepts an @hey.com sender identity on an external account authenticated with unrelated SMTP credentials, and when that account is deleted before async dispatch, delivery falls back to first-party infrastructure while retaining and DKIM-signing the claimed identity.
**Steps:**
1. Authenticate as ordinary HEY account `5669.9127.8238@hey.com`.
2. Create temporary external account claiming `support@hey.com` using unrelated SMTP creds `test@kamil.gr` on `mail.kamil.gr`.
3. Enqueue one message with acting sender `support@hey.com` and display name `The HEY Team`.
4. Delete the temporary external account ~0.8s after submission, before async dispatch.
5. Observe recipient inbox: From `The HEY Team <support@hey.com>`, Return-Path `support@hey.com`, DKIM `d=hey.com; s=heymail`, SPF/DKIM/DMARC pass.
**How found:** Researcher noticed sender authorization is checked at enqueue but not re-validated at dispatch; hypothesized that deleting the external-account object between enqueue and async send would cause fallback to first-party delivery while preserving the claimed identity, then tested with a raw-EML reproduction.
**Exploitation:** Attacker with any HEY account configures a spoofed @hey.com sender on a throwaway external account, queues the message, then deletes the account during the async window so HEY's own infrastructure delivers and signs the message as the impersonated identity. No password or mailbox access to the target identity needed.
**Escalation:** Impersonate trusted service identities like `The HEY Team <support@hey.com>` for credible phishing since recipient systems see authenticated hey.com mail.
**Insight:** When a mail system validates sender identity at enqueue but dispatches asynchronously, try deleting or mutating the authorizing object during the window between enqueue and send to see if delivery falls back to first-party infrastructure while keeping the claimed From/Return-Path.