# Bypass auth.email-domains (2)

MySQL utf8 charset truncates at code points >0xFFFF, so an email like attacker@gmail.com𝌆@allowed-domain.com passes the domain allowlist but stores as attacker@gmail.com.

- Payout: $500
- Severity: high
- Program: Phabricator
- Credited: tomvg
- Disclosed: 2014-03-26
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/2233
- Library page: https://bugbountylibrary.com/r/h1%3A2233
- Tags: domain:web impact:internal-access kind:bounty platform:hackerone sev:high tech:php technique:incomplete-fix technique:unicode-normalization vuln:access-control vuln:auth-bypass

**Target:** email-domain allowlist authentication (auth.email-domains)
**Root cause:** MySQL utf8 (not utf8mb4) columns silently truncate strings at the first character with code point >0xFFFF; the domain-allowlist check runs on the full string while the stored email is truncated to the attacker's real address.
**Steps:**
1. Register account with email `attacker@gmail.com𝌆@allowed-domain.com`
2. Allowlist check sees suffix `@allowed-domain.com` and passes
3. MySQL utf8 column truncates at `𝌆` (U+1D306), storing `attacker@gmail.com`
4. Attacker controls the account tied to an arbitrary non-allowed email
**How found:** Prior report #2224 bypassed the same allowlist via length truncation; researcher reasoned the fix only addressed length, then hypothesized a different truncation vector — MySQL's utf8 charset behavior on astral-plane characters — and tested with U+1D306.
**Exploitation:** Attacker registers with a crafted email whose visible suffix matches an allowed domain but which MySQL truncates to the attacker's own address, gaining an account under the domain-restricted auth policy.
**Insight:** When a fix patches one truncation vector (length), check other truncation layers: DB charset (utf8 vs utf8mb4), null bytes, and Unicode normalization between the validation string and the stored string.