CVE-2026-108885 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the SysMessageController delete handler that allows low-privileged authenticated users to delete message records. Attackers can send DELETE requests with arbitrary id values to remove any sys_sms row, erasing records of sent notifications without ownership checks.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The identified security flaw resides within the SysMessageController component of JeecgBoot versions up to and including 3.9.5, specifically affecting the HTTP DELETE handler responsible for removing message records from the system. This vulnerability is classified as a Broken Access Control issue, aligning with CWE-284 in the Common Weakness Enumeration taxonomy. The core technical deficiency lies in the absence of proper authorization checks during the deletion process. While the application correctly requires authentication to access certain endpoints, it fails to verify whether the authenticated user possesses the necessary privileges or ownership rights relative to the specific resource being targeted for removal. Consequently, any low-privileged authenticated user can bypass intended security boundaries by directly manipulating request parameters without triggering appropriate permission validations.
From a technical perspective, an attacker exploits this flaw by crafting and sending HTTP DELETE requests containing arbitrary identifier values corresponding to sys_sms database rows. The backend logic processes these requests based solely on the validity of the provided ID rather than cross-referencing it against user-specific access control lists or ownership metadata. This lack of object-level authorization allows malicious actors to delete message records belonging to other users, administrators, or system-critical notification logs. By leveraging tools such as Burp Suite or custom scripts, an adversary can iterate through sequential IDs or utilize known identifiers to systematically erase specific entries within the sys_sms table, effectively bypassing any frontend restrictions that might otherwise prevent non-administrative users from accessing deletion functions.
The operational impact of this vulnerability is significant, particularly regarding data integrity and auditability. The ability to arbitrarily delete message records means that critical communication logs can be erased without detection or traceability. This capability undermines the reliability of notification systems used for security alerts, transaction confirmations, and user communications. Furthermore, it facilitates potential evidence tampering in scenarios where these messages serve as part of an audit trail. An attacker could selectively remove notifications related to account compromises or policy violations, thereby obscuring malicious activities from system administrators and compliance auditors. This erosion of trust in the messaging subsystem can lead to operational disruptions if users fail to receive important updates due to unauthorized deletions by other parties within the same tenant environment.
To mitigate this vulnerability, developers must implement robust object-level authorization checks within the SysMessageController delete handler. The application should verify that the authenticated user initiating the request is either an administrator with broad deletion privileges or the legitimate owner of the specific message record identified in the request parameters. This can be achieved by querying the database to confirm ownership before executing the DELETE operation and returning a forbidden error if the check fails. Additionally, implementing role-based access control at the controller level ensures that only users with designated roles can perform destructive actions on system messages. Regular security audits and penetration testing should also be conducted to identify similar patterns of missing authorization across other endpoints within the JeecgBoot framework.