Improper Access Control — Generic: How I Gained Full Control Over an Admin Panel

In a recent report, I came across a Swagger UI that exposed API endpoints, which could have let an attacker take full control of the system’s admin functions / Admin panel. It was a simple, public Swagger page revealing sensitive admin endpoints with no authentication or authorization protection. Luckily it wasn’t duplicated! Sounds good, right? But how? why?

Worth noting, I found this using my own automation process. I call it Aspirin :] When it comes to automation in bug bounties it’s crucial to emphasize that it’s not just about running noisy tools like Nuclei and hoping for the best. It is all about asking simple questions from your self about “What automation? Could we have automate that task?” etc. Real automation is about creating a customized methodology, fine-tuned to each bug bounty hunter, pentester, or red-teamer’s approach. It’s about turning your expertise into code to streamline without losing accuracy. I personally prefer Go-Lang for this because of its great performance, simplicity and concurrency features which fit perfectly with my workflow.

Read my blog about “Why Go is the Perfect Choice for CLIs”:
https://medium.com/@rezauditore/why-go-is-the-perfect-choice-for-clis-477281989ace

For those unfamiliar, Swagger is a tool often used by developers to document and test their APIs. It’s a great tool for streamlining development, but in this case, it became a window into the inner workings of the platform’s administrative back end.

As I was exploring, I stumbled upon a publicly accessible Swagger page that exposed a long list of critical API routes. These routes weren’t your run-of-the-mill endpoints — they were related to admin user management and employee records. And the worst part? There were no authentication or authorization checks in place. This means anyone who found the page could interact with the API and execute admin-level actions.

Here are just a few examples of the exposed endpoints:

This was an open invitation to anyone with basic API testing knowledge to take over the admin panel, manage users, and manipulate employee data.

To show how severe this was, let me walk through the steps an attacker could have taken to completely own the system.

1. Access the Swagger Page

The first step was simply accessing the Swagger documentation page. This was publicly available without any restrictions — no login prompt, no security measures, just a list of sensitive API routes, waiting to be tested.

2. Create a New Admin Account

I picked one of the admin endpoints to start with: /api/v3/Admins/AddAdmin. Using a tool like Postman or even Swagger’s own interface or CURL command, I sent a request to create a new admin user:

That was it. I now had an admin account on the platform, giving me full control over the admin panel. so much simple. From here, I could access all the management functions reserved for admins.

3. Reset Existing Admin Passwords

To further demonstrate the scope of the issue, I used the /api/v3/Admins/ResetPassword endpoint to reset the password of an existing admin. Since there were no access controls, all I needed was the admin’s employee ID, which I could easily retrieve from another exposed API endpoint (/api/v3/Admins/List).

With this, I could take over any existing admin account by resetting their password.

4. Delete Admins or Lock Them Out

Next, using /api/v3/Admins/Delete, I was able to delete admin accounts from the system. This would cause a denial of service for legitimate admins, effectively locking them out of their own platform.

5. Full Control of Employee Management

The employee management endpoints were also fully exposed. Using /api/v3/EmployeeManagers/Add, /api/v3/EmployeeManagers/Edit, and /api/v3/EmployeeManagers/Delete, I could add, edit, or delete employee records at will. This meant that an attacker could manipulate critical business data or erase entire employee profiles.

The vulnerability I found allowed for a complete system takeover — something that could have been easily avoided with proper access control mechanisms. Fortunately this issue was resolved responsibly after my report and the platform in question fixed the oversight promptly.

The lesson here is clear: never assume your APIs are invisible. They could reachable with google dorking, public repositories, GitHub repositories or with automation process for example. Secure your Swagger documentation and restrict access to sensitive endpoints. Always think like an attacker when designing your API architecture. Easy.

This was a rewarding find that earned me a nice bounty ($$$$), all because I won the race and was the first to discover it.

Stay sharp, stay secure ❤