Business Logic Error Leads to Unauthorized Privilege Downgrade of Report Owner

“اللهم صلِّ وسلِّم على سيدنا محمد عليه أفضل الصلاة والسلام”

HELLO HACKERS!
Today, I’m excited to share a Logic Bug I discovered in a Public HackerOne Bug Bounty Program (BBP) that led to a Downgrade of Report Owner Privileges and a potential loss of administrative control!

Without wasting any time… let’s dive in!

The target is a well-known customer engagement and business support platform that provides various tools for customer service, sales, and marketing automation.

One of the platform’s key features allows users to create reports for data analysis and collaboration. Within a report, the Report Owner has the ability to share access with other users by assigning different permission levels, such as:

Can-Manage — Full control over the report, similar to the owner.Can-Edit — Ability to modify the report but with limited administrative control.Can-View — Read-only access without any modification rights.

For confidentiality reasons — since the issue is still unpatched — we will refer to the platform as Target.com throughout this write-up.

When I started testing the REPORTS section, I analyzed its different functions carefully. This led me to focus on the SHARE FUNCTION, which allows the Report Owner to share the report with other users with specific roles (Can-Manage, Can-Edit, and Can-View).

And Users who hve access to the SHARE function in Target.com:

✔️ Owner
✔️ Can-Edit
✔️ Can-Manage

❌📌 Users with Can-View permissions do not have access to the SHARE function.

This means the SHARE function is accessible only to the Owner, Can-Edit, and Can-Manage users. Keeping this in mind, let’s explore how this bug was exploited to downgrade the Owner’s privileges!

By intercepting the SHARE REQUEST, I observed that when sharing a report with a user, their first name, last name, and email appeared in the User Interface (UI), and there was no option to edit the name from the UI itself. Even in the Edit User settings (which used the same endpoint), the only available actions were:

Modifying the roleRemoving the user from the reportTransferring ownership

However, when I analyzed the JSON request body, I found something interesting:
There were parameters for firstname, lastname, and email being sent in the request!

I thought, what if I change these parameters?

I modified the firstname, lastname, and email values to something different.The changes appeared in the UI, meaning the system allowed it!However, once I refreshed the page, the values reverted to their original state.

So I tried another approach:

Instead of changing the values, I set the firstname, lastname, and email to blank (“”) and tested the effect:

The values disappeared from the UI, meaning the user was now displayed with an empty name and email.From Can-Edit PerspectiveFrom Can-Edit PerspectiveBut again, after a refresh, the original name and email returned.

At this point, I started to feel like this wasn’t leading anywhere…
Until I noticed something very strange.

Normally, when a user is already shared on a report, their email should not appear in the list of available users to be shared again.

BUT… after I deleted a user’s name and email, and “Before Refreshing the Page” that same user suddenly appeared again in the “Available Users” list for sharing!

💡 This led me to an interesting idea💡

I started thinking… “What would happen if I cleared the Owner’s name and email, then re-shared the report with the same email but with lower permissions?”

To test this, I did the following:

1️⃣ I modified the Owner’s details — I set the firstname, lastname, and email to blank (“”) using an intercepted request.
2️⃣ Before refreshing the page, I shared the report again using the Owner’s original email, but this time with Can-View permissions instead of Owner.

From Can-Edit Perspective

And guess what happened?

The email was successfully added again, and surprisingly, there were now two users with the same email listed! However, something strange happened — both accounts appeared as “OWNER” instead of “View-Only”, despite the fact that I had explicitly assigned a lower role.

When I switched back to the original Owner’s account, I noticed a huge issue:

The Owner’s permissions were downgraded, even though their role was still labeled as “OWNER” But it Just in UI.Several critical permissions disappeared, meaning the Owner lost control over the report!

Here’s what happened:

❌ The OWNER could no longer share the report with Can-Manage or Can-Edit roles.
❌ A View-Only user could not be upgraded to a higher role.
❌ Edit users could not be promoted to Manage anymore.
❌ If no other Manage users exist, the entire report becomes permanently locked, with no way to recover administrative control!

This completely broke the privilege hierarchy, allowing any Can-Edit or Can-Manage user to permanently downgrade the Owner’s access, leading to a complete loss of control.

From OWNER Perspective (One Thing from impact)

This means that an attacker with Can-Edit or Can-Manage permissions could exploit this logic bug to completely strip the original OWNER of their administrative power, leading to a permanent privilege downgrade.

Even though the system still shows them as OWNER, they no longer have the ability to manage sharing settings or modify report access levels. If no other Manage users exist, there is no way to recover control of the report.

“A simple logic flaw that can cause massive disruption!”⚠️

I reported this vulnerability to the program, and after their investigation, they acknowledged the issue and rewarded me with a bounty — Alhamdulillah! 🙌💰

I hope you found my story useful! If anyone has any additions or suggestions, here are my social media accounts — I’d really appreciate it if you reached out.

LinkedIn => https://www.linkedin.com/in/ahmed-esmail-844401298/

Facebook => https://www.facebook.com/profile.php?id=100024307756910

X => https://x.com/aesmail034