Shopify: email confirmation bypass → account takeover

What happened

@ngalog found this bug while retesting the fix for report #791775 on Shopify (myshop.myshopify.com). The first bug had already been closed. @ngalog checked the patch, found it was incomplete, and filed a second report the same day — hence the Part II title.

The mechanic: Shopify's email confirmation flow had a bypass that let an attacker associate someone else's email with their own account. Once verified, they gained access to the legitimate owner's account — no password, no second factor.

This is *privilege escalation* (gaining access beyond your authorization level without legitimate credentials): a normal user account becomes a vector to control someone else's. The entry point is an email verification flow — it feels low-risk but it's the identity anchor of the whole system.

Shopify responded fast: the feature was disabled immediately and a permanent fix shipped in two hours.

Why it matters

"Retest the fix" is one of the highest-yield patterns in bug bounty. Mature programs like Shopify carry complex legacy auth flows and ship patches under pressure. That creates two recurring opportunities:

• Incomplete fix: the patch closes vector A but leaves vector B exposed in the same flow.
• Regression: the fix introduces a new bug in adjacent code.

Email verification flows are especially rich because they involve scoped tokens with complex binding (which account does this token belong to?), they're easy to get wrong — predictable tokens, reusable tokens, tokens not bound to the originating session — and the impact is usually direct ATO (Account Takeover — full control of another user's account).

In programs with millions of users, even "a small subset of accounts" can mean thousands of real users exposed.

What to do

If you're hunting programs with a public HackerOne history:

• Find resolved reports in your target vuln class (email verification, account linking, OAuth). Read the title and response timeline.
• Map when the fix landed and identify what functionality was touched in that commit or sprint.
• Retest the full flow, not just the exact reported vector. Patches cover the happy path but miss edge cases: tokens sent to multiple emails, email-change flow vs. initial verification, internal APIs vs. public UI.
• Always test with two accounts: attacker and victim. Email-based ATO bugs require confirming real cross-account access — don't accept a false positive.

In identity systems, "verified email" is the trust anchor for password reset, SSO, and merchant permissions. Any bypass in verification is automatically critical scope — and Shopify had two in the same flow.