become an admin... somehow?

tl;dr

i came across a music samples platform and identified multiple vulnerabilities that allowed me to:

  • enumerate and retrieve details of every user account (including hashed passwords)
  • hijack arbitrary user accounts
  • create an administrator account
  • access the admin panel

all of this was achievable with a few crafted requests, no advanced tooling, and basic observation of the authentication flow.

context

it started with an announcement on a discord server promoting a new website for music samples. out of curiosity, i decided to create an account and explore the platform.

after a few minutes of browsing, i began looking more closely at how authentication and user management were implemented.

google signup without verification

the platform offered account creation using google oauth, which immediately caught my attention. i registered using this method and inspected the signup request.

the request sent to the backend looked like this:

POST /api/user/auth/google-signup HTTP/1.1
Host: [redacted]
Content-Type: application/json

{
    "name": "testuser",
    "email": "any@email.com"
}

there was no oauth token, no signature, and no verification with google. the backend trusted the client-provided email address entirely.

sending this request manually resulted in a valid user account being created.

user enumeration and data exposure

next, i replayed the same request using an email address that already existed.

this time, the response indicated that the user already existed - but also returned the full user object. this included:

  • user id
  • email address
  • name
  • hashed password
  • additional internal fields

at this point, the application allowed unauthenticated enumeration of user accounts and exposed sensitive information in error responses.

account takeover via password reset token leak

while reviewing the leaked user object, i noticed a field named secret. to understand its purpose, i created another test account and observed the same field.

it turned out that this value was the password reset token.

with that token, i could directly reset the password of any user by calling the password reset endpoint:

POST /api/user/auth/forgot-password HTTP/1.1
Host: [redacted]
Content-Type: application/json

{
    "email": "victim@email.com",
    "password": "newpassword",
    "code": "reset_token_from_previous_response"
}

the password was successfully changed without any email verification or user interaction.

additionally, the reset token was not invalidated after use, meaning that once leaked, it could be reused indefinitely.

this resulted in full account takeover for any user.

privilege escalation to administrator

after confirming account takeover, i looked for ways to escalate privileges.

each user object contained a role field. updating this field via the profile update endpoint was correctly rejected.

however, during account creation, the backend accepted arbitrary fields from the request body. by adding a role field during registration, i was able to create an account directly with administrator privileges.

the server did not enforce role assignment on the backend.

logging in with this account granted full access to the admin panel.

impact summary

this vulnerability chain allowed:

  • unauthenticated user enumeration
  • exposure of sensitive account data
  • complete account takeover
  • privilege escalation to administrator
  • unrestricted access to administrative functionality

all issues originated from missing server-side validation and over-trusting client input.

responsible disclosure

i reported these vulnerabilities directly to the website owner.

the issues were acknowledged and fixed promptly. communication was constructive, and the problems were handled responsibly.

testing was limited to my own accounts and passive observation of responses.

conclusion

this case illustrates how multiple small oversights can combine into a critical security failure. none of these issues required advanced techniques - only missing validation and trust boundary enforcement.

authentication, authorization, and role management must always be implemented and enforced server-side.

as a reminder for developers:

  • never trust client-provided identity or role data
  • avoid exposing internal objects in API responses
  • invalidate sensitive tokens after use
  • design authentication flows defensively

security failures are rarely caused by complex attacks. more often, they result from simple assumptions left unchecked.

and that's how i became an admin... somehow.

I'm currently looking for an internship in programming!! if you're interested, you can read my resume here :