# Vine Re-auth Bypass [Twitter Bug Bounty]

Vine's re-auth password check for email change was bypassable by directly PUTting the email field to /api/users/{id} without credentials.

- Payout: unconfirmed
- Severity: medium
- Program: Twitter
- Credited: Abdullah Hussam
- Disclosed: 2016-09-21
- Write-up quality: 6/10
- Original: https://ahussam.me/Vine-Reauth-Bypass
- Library page: https://bugbountylibrary.com/r/blog%3Aahussam-me-vine-reauth-bypass
- Tags: domain:web impact:ato kind:bounty platform:blog sev:medium tech:rest technique:source-review vuln:access-control vuln:account-takeover vuln:auth-bypass

**Target:** REST API endpoint /api/users/{id} on vine.co
**Root cause:** The re-auth password check was enforced only on the /api/users/authenticate endpoint, while the actual email update via PUT /api/users/{id} accepted the email parameter without any re-auth token or password validation.
**Steps:**
1. Observe email change flow: POST /api/users/authenticate with `action=change-email&username=...&password=...` then PUT /api/users/{id} with `email=new@x`.
2. Note the PUT request carries no re-auth token, only the session cookie.
3. Log out and back in, then send PUT /api/users/{id} with `Content-Type: application/x-www-form-urlencoded` and body `email=attacker@x` directly, skipping the authenticate call.
4. Server returns `{"success": true}` and email is changed without password.
**How found:** Researcher noticed the new re-auth form and compared the authenticated POST /api/users/authenticate request against a non-re-auth PUT (vanity URL change), observing no extra token or header distinguished them, then hypothesized the PUT email update itself lacked re-auth enforcement.
**Exploitation:** Attacker with a hijacked session (stolen cookie or physical access) skips the re-auth password prompt by directly issuing the PUT /api/users/{id} request with the new email, enabling account takeover via email reset.
**Insight:** When a re-auth gate is added, compare the gated action's actual state-changing request against other un-gated PUT/PATCH requests on the same resource; if the gate lives on a separate authenticate endpoint rather than the mutation itself, the mutation can be called directly.