How XHack AI Uncovered a Critical Privilege Escalation Vulnerability

Executive Summary

During a routine security audit conducted by XHack AI on behalf of an automotive industry client, whose identity remains confidential and is referred to throughout this document as Redacted, a critical broken access control vulnerability was identified within the client's web application. The vulnerability permitted any standard authenticated user to access administrator-only API endpoints using nothing more than their own legitimately issued JWT token, with no modification required.

The application issued JWT tokens to all authenticated users regardless of role. Separate admin endpoints existed under a dedicated namespace, and the server performed no role validation on incoming requests to those endpoints. It only verified that the JWT was valid and had not expired. As a result, a standard user's token was functionally identical to an admin token from the server's perspective when directed at the admin API.

The finding was surfaced autonomously by XHack AI during the enumeration phase, triaged to a critical severity rating, and subsequently confirmed by the XHack human analyst team before disclosure to the client. Remediation guidance was provided immediately, and the client patched the vulnerability within the same business day.

No evidence of prior exploitation was found at the time of disclosure.

Client Background

The client operates within the automotive sector and, for privacy and contractual reasons, cannot be identified beyond that descriptor. Their web application serves both internal teams and external partners, handling sensitive operational data including procurement workflows, vehicle telemetry integrations, and supplier management portals.

Due to the nature of their business, any unauthorised administrator access would have exposed not only internal operational data but also third-party partner information protected under data processing agreements.

Scope of the Engagement

The engagement was a web application security audit with the following scope:

• Target: Client's primary web application (authenticated and unauthenticated attack surface)
• Authentication levels tested: Unauthenticated, standard user, and role-based privilege tiers
• Testing approach: Grey-box, using XHack AI for automated discovery and XHack analysts for manual validation
• Out of scope: Internal infrastructure, mobile applications, third-party integrations

Discovery: How XHack AI Found It

XHack AI began the engagement by mapping the application's authenticated attack surface using a standard user account provided by the client as part of the grey-box test setup. Every authenticated user in the application received a signed JWT token upon login, included in the Authorization: Bearer header on all subsequent API requests.

During automated endpoint enumeration, XHack AI identified a distinct set of API routes operating under the /api/admin/ namespace. These endpoints were not linked from the standard user interface, but XHack AI discovered them through JavaScript bundle analysis and observed API call patterns.

XHack AI then issued direct HTTP requests to these admin endpoints using the standard user's JWT token in the Authorization: Bearer header, exactly as the user's session would normally send it. The server accepted the requests and returned successful responses with full administrative data and functionality. No additional token, role claim, or elevated credential was required. The server validated only that the JWT signature was correct and the token had not expired. It did not inspect the role embedded in the token's payload, nor did it enforce any separate admin-level authorisation check.

Why This Happened

The application's authentication and authorisation concerns were incompletely separated. Authentication, confirming that the user was who they claimed to be, was implemented correctly via JWT signature verification. Authorisation, confirming that the authenticated user was permitted to perform the requested action, was entirely absent on the admin API layer.

The admin endpoints appear to have been built under the assumption that only admin users would ever know they existed. This is security through obscurity, and it provides no meaningful protection. Any attacker who enumerates the application's endpoints, which XHack AI did in under 24 hours, can immediately begin issuing requests to them with a standard user token.

Technical Breakdown

The vulnerability is a textbook implementation of OWASP Top 10 A01:2021: Broken Access Control.

Property	Detail
Vulnerability Class	Broken Access Control / Privilege Escalation
CWE	CWE-284: Improper Access Control
CVSSv3 Score	9.8 (Critical)
Attack Vector	Network
Authentication Required	Yes (any valid standard user JWT)
Privilege Required	Low (standard user)
User Interaction Required	None
Impact	Full administrative control of the application

Proof of Concept (Sanitised)

XHack AI demonstrated the vulnerability using the following request. The token shown is a representative sanitised example of a standard user JWT.

GET /api/admin/users HTTP/1.1
Host: [redacted]
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.[standard-user-payload].[signature]
Content-Type: application/json

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "users": [
    { "id": "usr_001", "email": "[redacted]", "role": "admin", ... },
    { "id": "usr_002", "email": "[redacted]", "role": "user", ... },
    ...
  ],
  "total": 847
}

The server returned the full user directory, including administrator accounts and their associated data, in response to a request from a standard user session. No error, no 403, and no indication that the access was unauthorised.

XHack AI proceeded to enumerate additional admin endpoints and confirm the scope of accessible functionality, then immediately ceased further testing to avoid unnecessary data exposure and flagged the finding for human review.

Triage and Confirmation

Following automated discovery, XHack AI flagged the finding for human review with a Critical severity classification. The XHack analyst team performed independent manual validation:

1. Reproduced the vulnerability using a separately provisioned standard user account to confirm the issue was systemic and not specific to the test account.
2. Enumerated the blast radius by mapping all reachable admin endpoints using the standard user JWT. A total of 14 admin API endpoints were found to be accessible, covering user management, data export, application configuration, and audit log retrieval.
3. Inspected the JWT payload to confirm the token contained a role: "user" claim, verifying the server was not accidentally granting admin access based on a misconfigured token. The token was unambiguously a standard user token. The server simply was not checking it.
4. Checked for existing exploitation by reviewing available server access logs for requests to the admin namespace originating from non-admin user sessions. No evidence of prior malicious use was found.
5. Confirmed remediation scope and determined that role enforcement needed to be implemented server-side on all endpoints under the admin namespace, not solely on the individual endpoint first discovered.

The vulnerability was confirmed valid, fully reproducible, and critical in severity.

Impact Assessment

Had this vulnerability been discovered and exploited by a malicious actor before the audit, the following impacts were plausible:

Confidentiality

• Full read access to all registered user accounts, including partner and supplier contact details
• Ability to export sensitive procurement and telemetry datasets
• Access to audit logs, allowing an attacker to study internal operations or erase evidence of their own activity

Integrity

• Ability to modify or delete any user account in the system
• Ability to alter application configuration and business logic settings
• Ability to promote any attacker-controlled standard account to administrator, creating a persistent privileged foothold that would survive password resets

Availability

• Administrative controls included the ability to disable user accounts and reset application state, creating a vector for targeted disruption of internal operations or partner access

Regulatory Exposure

Given the client's data processing relationships with third-party automotive partners, unauthorised access to the data held under those agreements would likely constitute a reportable personal data breach under GDPR Article 33, carrying a mandatory notification obligation to the relevant supervisory authority within 72 hours of becoming aware of the breach.

Remediation

XHack provided the following remediation guidance to the client:

Immediate Actions (Completed Same Day)

• Implement server-side role validation on every endpoint under the /api/admin/ namespace. Each request handler must extract the role claim from the verified JWT payload and confirm it matches an allowlisted admin role before processing the request. A valid JWT signature alone is not sufficient authorisation.
• Do not treat endpoint obscurity as a security control. Any endpoint that exists in the application can be discovered by an attacker with sufficient time and tooling.
• Audit all API routes for similar patterns across the entire application, not only within the admin namespace.

Short-Term Actions (Completed Within One Week)

• Introduce a centralised authorisation middleware applied globally to all admin routes. This ensures that role enforcement cannot be accidentally omitted from newly developed endpoints.
• Enrich the JWT payload with a specific admin scope claim and validate it independently of the role field, providing defence in depth at the token layer.
• Add automated API security tests to the CI/CD pipeline to catch broken access control regressions before they reach production.
• Ensure audit logs capture the JWT subject and role claim on every admin API request, so that any future anomalous access by a non-admin token is immediately detectable.

Recommended Longer-Term Controls

• Adopt a zero-trust authorisation model in which every API request is evaluated against an explicit policy, regardless of how the session was established.
• Consider deploying an API gateway with centralised policy enforcement, reducing the risk of individual endpoint teams omitting authorisation checks during development.
• Run periodic automated access control regression scans against staging environments as a standard part of the release process.

Outcome

The client patched all 14 affected admin endpoints on the same business day as the disclosure call, adding server-side role validation to each route's request handler. A follow-up verification test conducted by the XHack team confirmed that all admin endpoints now correctly return 403 Forbidden when presented with a standard user JWT, regardless of the endpoint being called or the action being requested.

No evidence of prior exploitation was identified throughout the engagement. The client's engineering team acknowledged that the admin namespace had been developed on the assumption it would remain undiscovered, and that the absence of server-side role checks had never been flagged in previous internal reviews.

This case demonstrates the core strength of XHack AI: methodical, exhaustive endpoint enumeration that does not rely on visible UI surfaces, combined with systematic access control probing across every discovered route. A manual engagement focused on common attack vectors would likely not have surfaced this vulnerability during a standard test window. XHack AI found it in under 24 hours.