Cross-tenant user update through missing ownership validation.

Executive impact

A user from one tenant can modify another tenant’s account.

The API trusts a user identifier supplied in the request path without verifying that the target user belongs to the authenticated customer. An attacker with an ordinary account can therefore modify another organization’s user record if a valid identifier is known.

Reproduction

Minimal proof of exploitability.

1. Authenticate as a normal user in Tenant A.
2. Obtain the identifier of a test user belonging to Tenant B.
3. Send an update request while keeping Tenant A’s valid session.
4. Observe that the API accepts the update and changes Tenant B’s record.

PUT /api/users/usr_tenant_b_1042
Authorization: Bearer <tenant-a-token>
Content-Type: application/json

{"display_name":"Cross-tenant proof"}

HTTP/1.1 200 OK

The successful response and subsequent read-back confirm that authorization is enforced at authentication level but not at tenant ownership level.

Root cause

Authorization checks identity, but not ownership.

The handler retrieves the target user directly by identifier and permits the operation after validating only that the requester is authenticated. The authorization layer does not compare the target record’s tenant identifier with the requester’s tenant.

Remediation

Bind authorization to the tenant context.

Resolve mutable user records through the authenticated tenant context rather than a global identifier lookup. Enforce the tenant relationship server-side for every read and write path, return a non-distinguishing error for out-of-scope identifiers, and add regression tests covering cross-tenant object access.

Retest criteria

What I would verify after the fix.

Repeat the original cross-tenant request with multiple roles and object identifiers, confirm that out-of-tenant operations fail consistently, test adjacent endpoints for the same authorization primitive, and verify that legitimate same-tenant workflows remain functional.