# Email sender identity trusted without verification

Inbound email workflows acting on account state from a From address or alias without proving ownership

_Area: Web authentication and account takeover. Seen in 3 disclosed reports; one confirmed bounty: $3,134; latest 2026-10-20. Updated 2026-10-24._

## How it works
An email-driven workflow treats the sender address, or the address an inbound message was delivered to, as proof of who is acting. The assumption that breaks is that a From address or alias identifies its owner. Anyone who can set a From header, or who can cause mail to land on a shared/reflected alias, is treated as the account holder. The workflow then performs a privileged action (originate mail, verify an account, delete an account) on that unverified claim.

## Where it shows up
- Intake addresses like gdpr-request@, support@, or system aliases that trigger account changes from inbound mail [E3](https://bugbountylibrary.com/r/h1%3A928255.md).
- Sender identity accepted at enqueue but not re-checked at async dispatch [E1](https://bugbountylibrary.com/r/h1%3A4035023.md).
- Aliases whose inbound mail is posted publicly or reflected back to the sender [E2](https://bugbountylibrary.com/r/blog%3Aandmp-com-2018-12-how-i-managed-to-get-google-html.md).
- Verification codes or tokens sent to an address the requester does not own.
- Workflows with no security question, ID check, or out-of-band confirmation before acting [E3](https://bugbountylibrary.com/r/h1%3A928255.md).

## How to review
For every email-triggered action, ask: what proves the sender owns the identity being acted on? The invariant: a privileged action must require a secret or channel the requester controls, not merely a header they can set. Check that sender authorization is re-validated at the moment of dispatch, not only at enqueue [E1](https://bugbountylibrary.com/r/h1%3A4035023.md). Check whether the destination alias reflects content to the requester [E2](https://bugbountylibrary.com/r/blog%3Aandmp-com-2018-12-how-i-managed-to-get-google-html.md). Check whether deletion or rights requests require identity verification beyond From [E3](https://bugbountylibrary.com/r/h1%3A928255.md).

## Variants seen
- Sender identity accepted on external account with unrelated SMTP creds; deletion before async send falls back to first-party DKIM signing [E1](https://bugbountylibrary.com/r/h1%3A4035023.md).
- Verification code reflected through an email-to-comment gateway on a public tracker [E2](https://bugbountylibrary.com/r/blog%3Aandmp-com-2018-12-how-i-managed-to-get-google-html.md).
- Spoofed From on a GDPR intake address triggers account deletion with no verification [E3](https://bugbountylibrary.com/r/h1%3A928255.md).

## Why fixes fail
E2 notes a prior patch was bypassed, showing alias-based reflection fixes can be incomplete and need re-testing after change [E2](https://bugbountylibrary.com/r/blog%3Aandmp-com-2018-12-how-i-managed-to-get-google-html.md).

## Impact and severity
Outcomes ranged from sending authenticated mail as arbitrary first-party addresses [E1](https://bugbountylibrary.com/r/h1%3A4035023.md), to account signup/verification via reflected codes [E2](https://bugbountylibrary.com/r/blog%3Aandmp-com-2018-12-how-i-managed-to-get-google-html.md), to deletion of any user's account [E3](https://bugbountylibrary.com/r/h1%3A928255.md). Severity is high where the action is destructive or grants identity; worse when no verification step exists and the trigger is a spoofable header.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A4035023.md
- E2: https://bugbountylibrary.com/r/blog%3Aandmp-com-2018-12-how-i-managed-to-get-google-html.md
- E3: https://bugbountylibrary.com/r/h1%3A928255.md