This article documents the discovery and exploitation of a privilege escalation vulnerability caused by improper trust in client supplied authorization state. The application relied on values returned by the client to make access control decisions after authentication.

The issue was identified through manual request inspection and logic testing rather than automated scanners. Exploitation resulted in unauthorized access to administrative functionality from a standard user account.

Application Context

The target was a modern single page web application backed by a REST based API. User authentication was implemented using a server issued session cookie generated after successful login.

Following authentication the application returned a user context object to the client. This object contained identity and authorization related fields intended to represent the user access level during subsequent requests.

While authentication was enforced consistently authorization logic was not fully bound to server side session state.

Initial Observation

During post login traffic analysis an API response was observed returning structured user context data. The response included fields such as user identifier role permission set and account tier.

These values were later reflected back to the server in multiple requests involving sensitive actions. No integrity controls or verification mechanisms were applied to these fields.

This behavior suggested that authorization decisions might be derived directly from client supplied state.

Endpoint Analysis

While intercepting authenticated requests an endpoint responsible for account management functionality was identified.

POST /api/account/manage

The request body included role and permission fields that matched those returned by the server during login. The backend appeared to consume these values directly when evaluating access control logic.

No server side recalculation or validation of authorization context was observed.

Threat Model

If the backend trusted the role or permission values supplied in the request body it should be possible to escalate privileges by modifying these values while keeping the authenticated session unchanged.

Under this model authentication would remain valid and only authorization context would be manipulated.

Exploitation

The request was replayed with the session cookie unchanged. Only the role value in the request body was modified.

The original request included a role value corresponding to a standard user account. This value was replaced with an administrative role.

All other request parameters headers and cookies were left intact.

The server accepted the modified request and returned a successful response.

No authorization error was triggered and no secondary validation occurred.

Impact Verification

Following the modified request previously restricted endpoints became accessible.

Administrative functionality such as viewing other user accounts modifying account settings and accessing internal management interfaces executed successfully.

This confirmed a full vertical privilege escalation from a standard user to an administrator.

Root Cause

The vulnerability originated from a fundamental trust boundary violation.

Authentication verified user identity but authorization decisions were delegated to client supplied state. The application treated role and permission data as trusted despite being fully attacker controlled.

Authorization logic was not bound to server side session context which allowed privilege escalation through simple request manipulation.

Security Impact

This issue enabled complete administrative compromise by any authenticated user.

No brute force cryptographic attacks or race conditions were required. The attack was deterministic low effort and highly reliable.

Vulnerabilities of this nature are particularly dangerous because they often leave minimal forensic traces.

Remediation

The issue was reported with full request and response context demonstrating the privilege escalation.

Recommended fixes included removing all client supplied authorization data deriving roles and permissions exclusively server side and enforcing centralized access control checks bound to session identity.

Key Takeaways

Client side state must always be considered attacker controlled.

Authorization decisions should never rely on values provided by the client.

Logic vulnerabilities like this are high impact frequently overlooked and rarely detected by automated tooling.