Weak isolation on dual-use endpoint

 This vulnerability demonstrates weak isolation on a dual-use endpoint, where a single backend function is used for multiple operations without properly separating privilege levels or enforcing appropriate validation. In this case, the password change functionality is intended for normal users to update their own credentials, but due to poor access control and missing validation, it can be abused to reset another user’s password—including an administrator’s.

The issue begins by analyzing the password change feature available on the user account page. Under normal circumstances, changing a password should require the user to provide their current password as proof of identity before setting a new one. This ensures that only the legitimate account owner can perform the operation, even if their session is compromised.

By intercepting the POST /my-account/change-password request in Burp Suite and sending it to Repeater, the request structure can be examined. It contains parameters such as:

username=wiener
current-password=peter
new-password-1=newpass
new-password-2=newpass

At first glance, the endpoint appears secure because it requests the current password. However, testing reveals a critical flaw: if the current-password parameter is removed entirely from the request, the server still processes the password change successfully. This indicates that the backend does not actually enforce verification of the current password in all execution paths.

This suggests the endpoint may serve multiple purposes internally—for example:

• allowing regular users to change their own password

• allowing administrators to reset another user’s password without knowing the old one

The vulnerability exists because these two use cases are not properly isolated. Instead of having separate endpoints or strict server-side authorization checks, the same endpoint appears to handle both operations and decides behavior based on the presence or absence of certain parameters.

The second critical flaw is that the account being modified is determined by a user-controlled username parameter. After confirming that the current password can be omitted, the attacker changes:

username=wiener

to:

username=administrator

and resends the request.

Because the backend does not verify whether the authenticated user is authorized to change the specified account’s password, it resets the administrator’s password to the attacker-controlled value. This results in a full account takeover.

After logging out, the attacker can log in as the administrator using the newly set password. Since the administrator account has access to privileged functionality, the attacker can access the admin panel and perform administrative actions such as deleting users, including “carlos,” which completes the lab.

The root cause of this vulnerability is a combination of missing authorization checks and poor separation of functionality. Sensitive actions with different privilege requirements should never share the same loosely controlled endpoint. A normal user password change flow should always verify the current password and only apply to the authenticated account. Administrative password reset functionality, if needed, should be implemented separately and protected by strict role-based access control.

This vulnerability highlights the importance of isolating privileged operations and never trusting user-controlled identifiers for authorization decisions. When endpoints are designed to serve multiple purposes without strict validation, attackers can manipulate request parameters to escalate privileges and compromise sensitive accounts.