Hey, I'm Amrul. I work as a Security Engineer, and in my free time I do bug bounty on YesWeHack. At the end of 2025, I found multiple vulnerabilities that all came from one very simple root issue. What's interesting? It wasn't a crazy RCE. Not a 0-day. Not some advanced crypto bypass. It was something that looked very normal. So normal that at first, I almost ignored it.

Phase 1 : Recon on Private Program (YesWeHack)

The target was a private program on YesWeHack. The scope was huge. Most of it used wildcard domains like: *.tldr.com Which means… a lot of subdomains to explore. So I started with my automate tools :

After some digging, I found something interesting: A backoffice admin portal.

Phase 2 : React JS, JS Files, and Hidden API Mapping

The portal was built with ReactJS. If you've done enough recon on SPA apps, you know the drill: JavaScript bundles often expose API endpoints. So I started digging into the JS files. And yeah… there were a lot of endpoints.

Example:

But here's the problem:

All of them required authentication. And there was no register feature on that portal. I tried a few common approaches:

• SQLi attempts
• Default credentials
• Auth manipulation
• etc

Nothing worked. So I stopped. But I documented everything carefully in Burp and in Google Docs.This is something I always do. Every recon process gets documented. That decision saved me later.

Phase 3 : One Month Later: Something Felt Off

About a month later, I went back to the same private program. While reviewing my old recon notes, I had this feeling: "I probably missed something." So I started again. This time, I checked the main domain tldr.com And I found something I didn't really look at before: A mobile application.

Why didn't I check it earlier? Because technically, mobile wasn't in scope. So I thought it would just waste time. Turns out… that was the game changer 🙂

Phase 4 : Mobile App Analysis

I downloaded the app and installed it on a normal device. First, I ran it normally just to understand the flow.

And guess what? There was a register feature. That was new. To go deeper, I tried intercepting the traffic using Burp Suite. But the app had:

• Root detection
• Emulator detection
• SSL pinning
• Frida detection

So I had to bypass all of that. I used:

• KernelSU for root bypass
• Obfuscated Frida for detection bypass

After bypassing SSL pinning and intercepting the traffic, I analyzed the API calls. And this is where everything connected. The mobile app was hitting:

api-ddd.tldr.com

The exact same backend used by the backoffice admin portal. Now things got interesting.

Phase 5 : The Overlooked Logic Flaw

I registered a normal user through the mobile app. Then I tried logging into the backoffice portal using the same credentials. The UI login failed. But when I checked Burp history I saw this request:

GET /user/v2/me

And it had succeeded.

Meaning: The backend accepted my token as valid. That's when I started suspecting a privilege separation issue. Or worse , broken access control.

Phase 6 : Full Privilege Escalation & Multi-Portal Takeover

At this point, I hadn't confirmed anything yet. All I knew was:

• My token was accepted by the backend
• A /user/v2/me request had succeeded Something didn't feel right

So instead of assuming, I started testing the hypothesis. If the backend only validates the token and not the role what would happen if I tried accessing admin endpoints directly?That's when I went back to the list of APIs I had extracted earlier from the backoffice JS files. I started testing them one by one using my normal mobile user token. I found endpoints like:

GET /user/v2/users GET /user/v2/acl/internal

And surprisingly… they were accessible using a normal user token. Damn :))))

That alone was bad. But then I found something much worse.

🔥 Full Privilege Escalation : Add Myself as Super Admin

I discovered an endpoint that allowed me to modify my own access control

POST /user/v2/acl

The request body allowed specifying a role. So I tried sending:

shitttt :)))) There was no proper role validation. No authorization check. And it worked. I successfully added my own account as a Super Admin. At this point, this was no longer just data exposure. This was:

• Vertical Privilege Escalation
• Broken RBAC
• Full Administrative Account Creation

With that access, I could:

• Manage all users
• Change roles
• Access sensitive data
• Control system configuration

Unexpected Discovery : Another Backoffice Using the Same API

While digging deeper, I found another environment:

invoice.tldr.com

After testing it, I realized it was using the same backend API.

That means: With one escalated token, I could take over two admin portals at the same time. This significantly increased the impact:

• Cross-portal privilege escalation
• Shared backend without proper segregation
• Multi-tenant authorization failure

And the root cause was still the same:

• The backend only validated whether the token was valid.
• It never validated whether the role was authorized.

Scaling the Analysis with AI Assistance

At this point, the scope was huge. There were many endpoints, and the JS bundle was big. I didn't want to miss anything. So I used an Claude code to help with:

• Analyzing extracted JS files
• Mapping all endpoints systematically
• Identifying request body structures
• Grouping APIs by privilege level
• Cleaning up and structuring my reports

Important: All exploitation and validation were still done manually in Burp. AI just helped speed up analysis and reporting. It allowed me to scale from one bug to multiple solid vulnerability reports.

Reporting & Reward Update

instead of submitting one massive report, I split them based on:

• Different endpoints
• Access type (read / write / admin control)
• Severity
• Affected portal

So far, the confirmed total reward has reached: 💰 $20K+ USD And there are still: 👉 9 reports waiting for triage. So the number might grow.

The Core Issue Was Simple

Everything came from one simple mistake: No proper role-based authorization enforcement in the backend. There was no:

• Proper RBAC validation
• Role isolation between portals
• Privilege boundary enforcement

It all comes down to one simple question: Is the backend validating the role or just checking if the token is valid?

In this case, it was only checking the token. But there's another important lesson here. Sometimes we skip something because we think it's not important. In my case, I initially ignored the mobile app because it was technically out of scope. I thought spending time there would just waste my effort. But that mobile app turned out to be the real game changer. it was hitting the same backend. And the entire bug chain started from there. If I hadn't gone back and questioned my earlier assumptions, I probably would have missed everything. Sometimes the biggest breakthrough doesn't come from something complex. It comes from revisiting what we once ignored.