Privilege Escalation to Moderator using Email Aliases

On a recent assessment, I discovered an interesting vulnerability in a Firebase application that allowed me to create a second password for another user giving me access to the privileged account.

Application Background

The application is used by users to watch sessions, chat about topics, and have conversations with other users. The application has moderators that can ban users from the platform or delete other users' messages.


The vulnerability was an IDOR that allowed me to create a second user profile on a user account and log in with a new registration number. Basically a user account with two passwords, the victim's password and one set by an attacker.

The schema for users in the application is below:

    "uid": "",
    "claims": {
        "paid": true,
        "moderator": true
    "email": "[email protected]",
    "profile": {
        "email": "[email protected]",
        "registration": ""

The login process uses the email of the user account and the registration number in a user profile.

One of the constraints for creating a second user profile on a victim's account was that you had to be logged in using an email alias from their email address. So in order for the vulnerability to be exploited, an attacker would need to disclose at least two pieces of information, the user ID and email address.

Retrieving User Information

Using the public registration link, I registered an account with my own email address. After submitting the registration form, the user will be redirected to a webpage containing the password for the account known as the registration number.

Access to the registered email address is not required in order to view the registration webpage containing the registration number.

Logging into the application with that account and visiting a Networking page lists all the users. Looking at the JSON data from the web server revealed the user's email address, their user ID, and roles.

Figure 1 - List of user IDs, emails, and roles

Exploiting the vulnerability to become a Moderator

Using the registration link again, I registered an account using the moderator's email address but as an alias (e.g. [email protected]). Using the registration number from the webpage, I logged into the application with the email alias address.

Figure 2 - Registration page containing credentials to log in

In the browser's JavaScript console, the following payload was used to update the current user's profile.


In the Networking tab under Developer Tools, a Firestore HTTP API request was copied as a curl command containing the update user call. Modifying this call with the original moderator's ([email protected]) user ID (1bgH4...) allowed me to create a new user profile with the registration number of my choosing on that user account.

curl '' \
-H 'authority:' \
-H 'content-type: application/x-www-form-urlencoded' \
-H 'origin:' \ 
-H 'referer:' \ 
ration%22%5D%7D%7D%5D%7D' \ 

The above curl command had to be copied from the browser using the DevTools as the SID value in the URL had a short time to live (TTL) and required a new curl command to be resent if the SID expired.

After executing the curl command successfully, an attacker could log into the application using the moderator's original email address ([email protected]) and the registration number the attacker set in the curl command. The attacker would have moderator permissions and could see the moderator's inbox of conversations with other users.

Figure 3 - User escalated their permissions by logging into the moderator's account
Figure 4 - Viewing moderator's messages in their inbox

Firebase Pentesting Reference:

AppSec-Labs | Application Security | Firebase Applications – The Untold Attack Surface