Privilege Escalation: How to Make Yourself an Admin

Hello Hunters! 👋

Today, I want to share one of my favourite bugs that I found in a SaaS program on HackerOne.

For privacy, let's call the target sass_app.com

Understanding the Target

The application supports multiple organizations.

Each organization has different roles, such as:

• Admin / Owner
• Developer
• Read-only
• ….

One interesting feature was the invitation functionality.

An organization admin could invite a new member and assign them any available role > including Admin.

That immediately made this functionality interesting from an authorization perspective.

Finding the Bug

When an admin invites someone, the application sends an invitation email to the invited address.

The normal flow looks something like this:

Admin
  ↓
Invite user@example.com
  ↓
Invitation email
  ↓
User accepts invitation
  ↓
User joins the organization with the assigned role

Admin
  ↓
Invite user@example.com
  ↓
Invitation email
  ↓
User accepts invitation
  ↓
User joins the organization with the assigned role

But I noticed something interesting.

What happens if an attacker can somehow control the invited email address!?

Since the application didn't require email verification during account registration, my first idea was:

1. Attacker knows that an invitation was sent to user@example.com.
2. Create an account using that same email address from /api/register endpoint.
3. Log in normally.
4. Obtain the invitation link from endpoint _/v1/invitations_.
5. Accept the invitation.
6. Join the victim organization with the role assigned by the admin.

If the assigned role was Admin, the attacker would become an administrator of the whole organization.

Pretty serious, right? 😈

I submitted the report to the Program, Then!

The Problem

Then came the response from the program team:

"What you have uncovered is a flaw in our /register process, which is out of scope!"

They explained that the registration path I used wasn't enabled in production and was therefore considered out of scope.

Oh no. 😅

That meant my entire attack chain depended on a registration flow that the program wouldn't consider valid.

At that point, it looked like my High-severity bug was going to become a false positive.

But Wait!!!!!!!

Going Back to My Notes

Instead of abandoning the report, I went back to my notes about the application.

And this is where keeping good notes while hunting really paid off.

I had previously noticed that an existing organization member could change their email address (through API only) to an unregistered email address.

That gave me another way to control the invited email.

I didn't need to create a new account anymore.

Instead:

Existing attacker account (low priviliges)
        ↓
Change email
        ↓
Set it to the invited email
        ↓
Obtain the invitation
        ↓
Accept it
        ↓
Join the organization
        ↓
Receive the assigned role

Existing attacker account (low priviliges)
        ↓
Change email
        ↓
Set it to the invited email
        ↓
Obtain the invitation
        ↓
Accept it
        ↓
Join the organization
        ↓
Receive the assigned role

I tested it.

And it worked perfectly. 🚀

Impact

If the invitation was for an Admin role, this allowed an attacker (low priviliges) to gain full administrative control over the organization.

This could lead to complete compromise of the organization's data, settings, and members.

The Lesson

This bug taught me something important:

Don't give up on a finding just because one part of your attack chain gets blocked.

When the program told me that registration wasn't an active production path, I could have closed the report and moved on.

Instead, I went back to what I already knew about the application.

My notes revealed another Idea that allowed me to achieve the same goal through a completely different path.

And this is one of the reasons I believe good notes are extremely valuable during bug hunting.

I would thank Jayesh for inspiring the main idea of this Bug.

Happy hunting, Hunters! 🐛