Description

CRMEB through 6.0.0 fails to validate message ownership in the edit_message handler of MessageSystemController.php, allowing authenticated users to modify arbitrary system inbox messages. Attackers can update any message's columns including is_del, look, and uid to delete, mark read, or reassign victim notifications without authorization.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-03T15:17:38.767Z",
  "pubdate": "2026-09-03T15:17:38.767Z",
  "executiveSummary": "CRMEB through version 6.0.0 contains a critical Broken Access Control vulnerability within its notification management system. The flaw exists in the edit_message handler of MessageSystemController.php, where the application fails to perform authorization checks to verify message ownership before processing update requests.\nThis vulnerability allows any authenticated user to manipulate system inbox messages belonging to other users or system entities. By submitting crafted requests to the vulnerable handler, an attacker can modify critical fields such as 'is_del' (deletion status), 'look' (read status), and 'uid' (user association).\nThe primary risk implications include the unauthorized deletion of sensitive notifications, the ability to mark private messages as read, or the hijacking of notifications by reassigning them to an arbitrary user ID. This bypasses security boundaries established for user data privacy. Exploitation requires the attacker to possess a valid, low-privileged authenticated session within the application. No further escalation is required, as the application logic fails to validate the context of the user performing the update against the target resource identifier.",
  "technicalDetails": "The vulnerability is situated within the MessageSystemController.php file, specifically in the function responsible for editing system messages. The core defect is an Insecure Direct Object Reference (IDOR) stemming from a complete lack of ownership validation during the input processing phase of the edit_message handler.\nRoot Cause Analysis: When an authenticated user triggers the edit_message functionality, the controller receives parameters intended to update specific records in the messaging database. The implementation fails to compare the unique identifier (ID) of the message being modified with the user identifier (UID) currently stored in the active session. Consequently, the application trusts the user-provided primary key for the message record and applies update operations without verifying if the requesting user has the authority to interact with that specific object.\nAttack Flow and Exploitation: An attacker initiates the exploitation process by first identifying a target message ID. This is often trivial if the system utilizes sequential IDs or if the attacker can view message metadata. Once a valid target ID is identified, the attacker constructs a malicious HTTP request directed at the MessageSystemController. By manipulating parameters in the request body, the attacker can force the database to execute arbitrary updates on rows they do not own.\nPayload Behavior: The application allows for the modification of sensitive column values. For instance, an attacker can set the 'is_del' column to 1, effectively performing an unauthorized deletion of a victim's notification. Furthermore, by modifying the 'uid' field, the attacker can reassign a notification to their own user account, enabling the exfiltration of potentially sensitive information contained within the message content. Modifying the 'look' column allows an attacker to manipulate the read status of notifications, which can be used to hide the existence of system alerts from legitimate users, thereby facilitating further malicious activities or social engineering.\nAffected Versions: All CRMEB versions up to and including 6.0.0 are confirmed to be vulnerable. The issue persists across installations regardless of the backend database type, as the flaw is inherent to the application's business logic layer. The vulnerability is exploitable over the network by any authenticated user, requiring no special administrative privileges to perform mass modification of notification records across the entire user base."
}