Description

lamp-cloud through 5.10.0 fails to validate user identity in PUT /anyone/baseInfo and PUT /anyone/avatar endpoints, allowing authenticated attackers to modify arbitrary user profiles. Attackers can supply target user IDs in request bodies to rewrite profile fields including nickname, ID card, sex, nation, education, work description, and avatar attachments of other users.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-21T22:17:00.327Z",
  "pubdate": "2026-09-21T22:17:00.327Z",
  "executiveSummary": "The vulnerability identified in lamp-cloud through version 5.10.0 is an Insecure Direct Object Reference (IDOR) flaw located within the profile management functionality.\nThis vulnerability allows an authenticated attacker to perform unauthorized modifications to arbitrary user profiles by manipulating the target user identifier within the request body of specific API endpoints.\nThe affected endpoints are PUT /anyone/baseInfo and PUT /anyone/avatar. By supplying an arbitrary user ID, an attacker can overwrite sensitive profile data, including personally identifiable information (PII) such as ID card numbers, education history, and employment descriptions, as well as replace user avatar attachments.\nThe primary risk implication is a significant breach of data integrity and potential identity impersonation, as unauthorized actors can manipulate user-controlled fields across the system.\nExploitation requires the attacker to hold a valid authentication token, though no additional administrative privileges are necessary to conduct the attack against other system users.\nThis vulnerability highlights a critical failure in server-side authorization checks, where the application trusts the user-supplied identifier rather than verifying ownership of the resource against the authenticated session context.",
  "technicalDetails": "The root cause of this vulnerability is the absence of server-side access control validation within the lamp-cloud application logic for the PUT /anyone/baseInfo and PUT /anyone/avatar endpoints.\nThe application relies on client-provided input to determine the target resource for a write operation, failing to perform an object-level authorization check to ensure that the authenticated user possesses the authority to modify the record associated with the supplied ID.\nWhen a request is submitted to these endpoints, the server retrieves the user ID from the request body and proceeds to execute database update queries based on that input. Because the identity of the requester is not verified against the target resource identifier at the controller or service layer, any authenticated user can effectively act as an authorized actor for any target user ID.\nThe attack flow proceeds as follows: First, the attacker authenticates into the application to obtain a valid session token. Second, the attacker crafts a PUT request targeting either /anyone/baseInfo or /anyone/avatar. Third, within the request body, the attacker embeds the user ID of the target victim. Finally, the attacker includes the desired modified fields or attachment references. Upon processing, the backend service blindly applies these modifications to the victim's profile stored in the database.\nThis flaw allows for the systematic modification of sensitive attributes including nickname, ID card number, gender, ethnicity, education background, work description, and profile image attachments. By manipulating these fields, an attacker can deface profiles, misrepresent user identities, or inject malicious content that may be stored or displayed elsewhere in the application, potentially leading to secondary vulnerabilities like Stored Cross-Site Scripting (XSS) if input sanitization is also absent.\nThe vulnerability affects all versions of lamp-cloud up to 5.10.0. The attack vector is strictly limited to authenticated users; however, the lack of ownership verification renders the internal authorization model ineffective against any user logged into the platform. Network exposure is dependent on the accessibility of the lamp-cloud API endpoints, and there are no requirements for elevated privileges, as the application logic fails to distinguish between self-modification and unauthorized cross-user modifications."
}