August 6, 2026
How I Almost Made $1,000 with a Pre-Account Takeover
While testing the authentication functionality on redacted.com, I came across something quite interesting involving the combination of…

By Ahmad Farel Pratama
2 min read
While testing the authentication functionality on redacted.com, I came across something quite interesting involving the combination of Google OAuth and the Change Email feature. At first, I simply wanted to see how the application handled email changes on an account created using Google OAuth.
I started by creating an account using Google OAuth with an email address I controlled:
"attacker@example.com"
After successfully creating the account, I went to the account settings and found the Change Email feature. Since I was testing the functionality, I decided to change the email address to another email address that I was using as the victim account:
"attacker@example.com" to "victim@example.com"
Interestingly, the change went through immediately :)
There was no confirmation or verification required for the email change. The email address was simply changed.
At this point, I started asking myself…
What would happen if the actual owner of victim@example.com tried to create an account?
Testing from the Victim's Side
I then switched to the victim's side and attempted to register using:
"victim@example.com"
As expected, the application told me that the email address was already in use. The victim was then redirected to the login page and tried using the password reset functionality. After completing the reset process, the victim created a new password and successfully logged in.
So far, everything might seem normal.
But something was actually wrong.
The victim had just logged into the same account that I had previously created using Google OAuth.
In other words, the victim didn't get a completely separate new account. They had logged into an account that was already under my control.
What About Attacker Side?
This was the part that made me even more interested.
I went back to the attacker's side and tried logging in using Google OAuth with the email address I originally used to create the account:
"attacker@example.com"
I actually expected the authentication to no longer work because the account's email address had already been changed to victim@example.com.
But then...
I could still log in :D
The Google OAuth identity I originally used was still linked to the account. So now there were two different ways to access the exact same account.
From the victim's perspective, they believed they were accessing their own account. Meanwhile, from my perspective as the attacker, I still had access through the Google OAuth identity I used when I initially created the account.
Is This Already an ATO?
I don't want to immediately call this a Full Account Takeover. In my opinion, this is more accurately described as a Pre-Account Takeover (Pre-ATO).
The reason is that the attacker isn't taking over an already existing victim account. Instead, the attacker can prepare an account beforehand, associate it with the victim's email address, and still retain the authentication method they already control.
Nice Try
I reported this vulnerability through HackerOne, but unfortunately, it was marked as a duplicate.
This is my first write-up, and I've only been doing bug bounty for five months, so I apologize if some parts are unclear. I'll keep working harder and continue improving :)
Thank you for reading!