VulnBank: Using Exposed API Docs and Weak Reset Logic to gain Superadmin Access

Exposed API endpoints are often the starting point for dangerous information leaks. In this write-up, I will demonstrate how a weak password-reset logic in VulnBank’s API allowed for a complete account takeover of the superadmin profile.

Reconnaissance (Directory Bruteforcing)

For initial reconnaissance, I used Gobuster for directory enumeration against [https://vulnbank.org.](https://vulnbank.org.)

This scan yielded some very interesting results ( */dashboard, /console, /api/docs*). API docs are known to be too revealing. I found the endpoint and headed straight to investigate.

Discovering the API Docs

I navigated to */api/docs* and found a fully interactive Swagger interface. I could test every single endpoint right from my browser without an external proxy or Burp Suite.

Looking through the authentication section, I encountered four endpoints:

*/register, /login, /api/v{version}/forgot-password, /api/v{version}/reset-password*

The versioning parameter (v1, v2, v3) hinted at older, less secure API iterations running in the background.

Account Creation and Login

Before going after the big fish, I needed to see how the API handled standard, valid requests. I used the */register endpoint to create a dummy account (`testacc`*).

Once registered, I used the */login* endpoint to authenticate using my newly registered credentials

The successful login returned a valid JWT, confirming the standard authentication flow worked perfectly. With the baseline established, it was time to escalate.

Exploiting the Forgot Password Feature

The real vulnerability that we’d be exploiting is in the */forgot-password* endpoint. It required a username and that version parameter we noticed earlier.

Looking at the endpoint descriptions, we can see that the older versions of the API leak sensitive information. I decided to target the admin account. After a bit of username enumeration, I found the privileged-account *superadmin. I submitted a password reset request for `superadmin*, and forcing the API to use Version 1 (v1`).

It returned a 3-digit reset PIN (*173) right in the debub_info section of the HTTP response body. This is an information disclosure vulnerability. Reset tokens or PINs should never* be revealed to the user making the request; they should be sent entirely out-of-band (like via email or SMS).

Resetting the Password

After getting the leaked PIN, taking over the account was easy. I moved over to the */reset-password endpoint and submitted the target username (`superadmin*), the reset PIN (173`), and my desired *new_password (`12345`*).

It returned a success message! To confirm the takeover, I went back to the */login* endpoint and authenticated with my newly set credentials.

Accessing the Admin Panel

With a valid superadmin credential in hand, I logged in to the frontend dashboard. The interface looked completely different from a standard user account.

And we are in!!! I now have full access to the admin panel, including user management, transaction controls, and the ability to view highly sensitive data. The complete compromise of the application has been achieved.

This walkthrough highlights three critical security failures that every development team must avoid:

1. Exposed API Docs: Never leave Swagger/OpenAPI documentation accessible to the public in a production environment.
2. Insecure Password Resets: Reset PINs and tokens must be sent out-of-band (via email, SMS, etc.). They should never be returned in an HTTP response body.
3. Predictable Usernames: Relying on default or standard high-privilege usernames like *admin or `superadmin`* makes brute-forcing and targeted account takeovers significantly easier.