How I Found a Critical Privilege Escalation That Let an Unprivileged User Become Admin and Earn $579 USD Bounty

Hi everyone — I’m back with a new writeup. I haven’t published for a few months, and I’m excited to share my latest bounty finding: a privilege escalation / broken access control vulnerability discovered on a target in the Cyberbay program. In this writeup I’ll walk you through how I discovered the issue, how I verified it, and how I reported it to the vendor. This post covers detection techniques, proof-of-concept verification (without unsafe exploit code), impact analysis, and recommended fixes. I hope you find it useful — let’s dive in.

🎯 Run Your Bug Bounty Program with Cyberbay — Use My Referral Code

If you’re part of a company or security team planning to launch a bug bounty program, Cyberbay is a fantastic platform to consider. I’ve had a great experience working with them as a researcher, and I highly recommend their platform for managing security reports and collaborating with ethical hackers.

As a valued member of the Cyberbay community, I’m excited to share an exclusive referral code for companies: 👉 Use referral code JIVAN2025 during registration to receive 15% off your company’s first purchase on Cyberbay.

🔐 Ready to get started? Register your organization here: https://community.cyberbay.tech/signup/corporate

Whether you’re a startup or a large enterprise, launching a bug bounty program is a smart step toward strengthening your security. Don’t miss this opportunity to launch your program with a discount and the support of a growing security community!

Have questions about the process? Feel free to reach out — I’m happy to help you get started.

Now let’s start: how I found this privilege escalation vulnerability in [Redacted Dot Com]. Due to security and privacy reasons I can’t disclose the company information, so I am referring to the company as [Redacted Dot Com], where this vulnerability was discovered.

Now I have logged in as an Admin user in [Redacted Dot Com] and started exploring the web application. I found that there are multiple roles available. After that, I intentionally created a new role called AppSecWriteups. This role only has home access and does not have permission to access or modify any other functionality.

In short, any user assigned to this role can log in to their account but cannot modify or view any data. After creating this custom AppSecWriteups role, I invited a new user and assigned this role to them. Then I logged in using the invited user’s account. As expected, this user couldn’t perform any action such as modifying or accessing any details — it was a simple login with no additional privileges. (See the attached screenshot below.)

After that, I started experimenting with the API calls for this user. Initially, I had already reported a few vulnerabilities for this same web application, so I had enough information about its APIs. I simply copied a random POST request for the invited user account into Burp Suite.

In this POST /dms-sit1/workbench-bff/workbench/loadRoles HTTP/2 API request for the invited user, you can clearly see that the user has only home access.

After this, I started looking at the role‑change API request because I had already confirmed that the target API endpoint was vulnerable and allowed privilege escalation for an unprivileged user.

When working in a bug‑bounty program, you must think from an attacker’s perspective: to exploit this privilege escalation, a few things are required, which I noticed — the low‑privilege user needs _id, uiRoles, roles, usernaem, and email.

Now let me explain why I needed this user identifier for exploitation. As I mentioned, I had already confirmed that the endpoint was vulnerable to privilege escalation, so why didn’t I report the bug immediately? The answer is simple: in my initial testing I copied this user identifier from an admin request into the unprivileged user’s request. That means the unprivileged user does not have direct access to the identifier, which directly affects the severity of my report because the identifier is not guessable by a low‑privilege user.

Because of that, I didn’t submit the finding straight to the triage team. Instead, I started looking for where this information could be obtained. Since I had previously reported other vulnerabilities for the same web application, I linked those earlier reports to this privilege‑escalation issue to obtain the user identifier. Let me show you with an image (see below).

Now let me explain how I obtained this user identifier, and how an unprivileged user could obtain that information. Earlier I had already submitted another bug report where an unprivileged user could access other users’ information — email, username, and other details (see the screenshot above). That report was also a broken‑access‑control issue which I’ve already reported.

I’ll write a separate, full writeup about that vulnerability; I’ve only included this summary here to explain how I obtained the required data for the privilege‑escalation test. At this stage I had access not only to my own information but to full registered‑user details. This exposure could allow an attacker to tamper with user accounts or remove users from the organization, which significantly increases the impact of the privilege‑escalation issue.

Now let’s start the exploitation stage. I had all the necessary information for privilege escalation, so I updated the low‑privilege user’s API request from POST /dms-sit1/workbench-bff/workbench/loadRoles HTTP/2 to POST /dms-sit1/atg-bff/settings/saveUser HTTP/2 and added the following JSON body:

{
  "viewModel": {},
  "_id": "USER_ID",    
  "uiRoles": ["ROLE"],  
  "underwriter": "N",
  "activated": true,
  "username": "USER_NAME",
  "displayName": "DISPLAY_Name",
  "email": "EMAIL",
  "updatedAt": "2025-09-18T16:38:23.718Z",
  "roles": ["ROLE"],
  "updatedBy": "cb.admin",
  "groupCd": "nb"
}

In the JSON body for the POST /dms-sit1/atg-bff/settings/saveUser HTTP/2 API request above, I added the user identifier I obtained from the previously reported vulnerable endpoint and then sent the modified update request.

For this privilege‑escalation test I used my own unprivileged user information (email, username, userId, etc.) and forwarded the request from the unprivileged account (myself).

As you can see in the screenshot above, I was able to escalate my privileges from an unprivileged user to an admin. After that I logged out and logged back in — I became an admin and was able to access admin functionality across the web application. This confirms the application is vulnerable to broken access control / privilege escalation.

After gathering all the proof‑of‑concept details and documenting how a low‑privilege user could obtain the user identifier (not only for their own account but for other users as well), I demonstrated that this issue allowed more than privilege escalation — the user could also demote other users in the organization. I compiled a comprehensive report and submitted it to the company. The triage team confirmed the vulnerability, classified the report as Critical, and rewarded me $579 USD as a bounty.

Security Guidance for Developers:

the root cause is missing or insufficient server‑side authorization on role‑change APIs. Fixes should include strict server‑side checks on all role and user modification endpoints, denial of role changes by low‑privilege accounts, validation of target ownership/tenant scope, centralized audited role management, and logging/alerting for suspicious role changes.

🚀🙏 Thank you for reading!