CVE-2026-85177 in CRMEB
Summary
by MITRE • 09/03/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in CRMEB versions up to 6.0.0 represents a critical failure in access control mechanisms within the application's messaging subsystem. Specifically, the edit_message handler located in MessageSystemController.php does not perform adequate validation to ensure that the authenticated user initiating the request is the legitimate owner of the message being modified. This oversight allows any logged-in user to manipulate system inbox messages belonging to other users by supplying arbitrary identifiers for target messages during update operations. The core technical flaw lies in the absence of a proper authorization check that binds the session identity or user ID to the resource identifier provided in the request payload, thereby violating the principle of least privilege and failing to enforce object-level access controls.
From an operational perspective, this vulnerability enables attackers to perform unauthorized actions against other users' notifications without needing elevated privileges or administrative rights. By exploiting the lack of ownership validation, an attacker can modify specific columns associated with message records, including is_del, look, and uid fields. Manipulating the is_del flag allows the attacker to delete messages intended for victims, potentially causing denial of service by obscuring critical system alerts or audit trails. Altering the look field permits marking unread notifications as read, which can be used to hide evidence of intrusion or prevent users from noticing suspicious activity. Furthermore, changing the uid column effectively reassigns ownership of these messages, allowing attackers to masquerade as other users within the messaging context or disrupt workflow processes that rely on accurate message attribution.
This type of vulnerability is formally classified under CWE-284, which describes Improper Access Control, and more specifically aligns with CWE-639 regarding Authorization Bypass Through User-Controlled Key. In terms of offensive security frameworks, this behavior maps to the MITRE ATT&CK technique T1078, Valid Accounts, as it leverages existing authentication credentials to perform unauthorized actions on resources not owned by that account. The exploitation does not require complex injection techniques or buffer overflows; rather, it relies entirely on manipulating HTTP request parameters to target arbitrary resource identifiers, making it a straightforward yet impactful attack vector for authenticated adversaries.
Mitigation strategies must focus on implementing robust server-side authorization checks within the edit_message handler. Developers should ensure that every update operation verifies that the user ID associated with the current session matches the uid field of the message record being modified before allowing any changes to be persisted in the database. Additionally, employing indirect reference maps or opaque identifiers instead of direct primary keys can reduce the risk if future logic flaws occur, although explicit ownership validation remains the most reliable defense. Input validation should also enforce that only expected fields are updatable and that their values conform to strict type constraints to prevent secondary injection issues. Regular security audits focusing on object-level access control patterns across all controllers will help identify similar weaknesses in other parts of the application architecture.