Summary
A broken object-level authorization vulnerability in lamp-cloud allows authenticated users to submit another user's ID when updating profile or avatar data. Under deployments where these endpoints are reachable and target identifiers are accepted without ownership checks, an attacker may alter personal information and avatar attachments belonging to other users.
Affected context
The vulnerability occurs in the PUT /anyone/baseInfo and PUT /anyone/avatar endpoints in lamp-cloud deployments through version 5.10.0. It becomes risky when the API accepts a user identifier from the request body but does not verify that the authenticated principal is authorized to modify the referenced account.
Exploit preconditions
- Attack surface: Authenticated HTTP API endpoints for profile and avatar updates
- Required access: A valid authenticated account or session
- Trigger point: Submission of a profile or avatar update containing another user's identifier
- Why exploitation is possible: The server appears to rely on a client-supplied object reference without consistently enforcing ownership or administrative authorization
Why this happens
The underlying bug is a failure to enforce object-level authorization for user-controlled identifiers. When an endpoint uses a request-supplied user ID to select the record being modified without deriving the target from the authenticated session or checking explicit permissions, an attacker can reference objects outside their authorized scope. This behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key.
Potential impact
- Unauthorized modification of other users' profile fields
- Tampering with identity-related information, including ID card data
- Replacement or abuse of avatar attachments
- Privacy, integrity, or account-trust impacts
- Potential downstream fraud or social-engineering consequences
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the object and field levels rather than trusting client-supplied identifiers.
Common defensive patterns include:
- Deriving the target user from the authenticated session for self-service operations
- Enforcing explicit ownership or role-based checks before every profile update
- Applying allowlisted field-level permissions to sensitive identity attributes
- Treating request-body user IDs as untrusted references
- Separating administrative profile-management operations from ordinary user endpoints
- Using least-privilege service identities and consistent authorization middleware
How teams detect issues like this
Organizations can assess this issue through:
- Static analysis for update queries whose target identifiers originate directly from request bodies
- Code review checks requiring object-level authorization before read or write operations
- API tests that attempt cross-account profile and attachment updates using authenticated test users
- Runtime authorization logs correlating the actor identity with the modified user ID
- Policy enforcement requiring ownership or privileged-role checks on sensitive endpoints
- Automated security testing tools that identify authorization differences across object identifiers
