CVE-2026-75458 in XueZhiSi
Summary
by MITRE • 08/31/2026
The teacher-end interface POST /api/teacher/user/delete/{id} in XueZhiSi Open Source Exam System <= 3.9.0 contains a vertical privilege escalatio vulnerability. This interface accepts a user ID and then executes getUserById(id), setDeleted(true), updateByIdFilter() in sequence, without any validation of whether the current user has the authority to delete the target user. An authenticated teacher user (role=2) can delete an administrator account (role=3), constituting a vertical privilege escalation where a lower-privileged user performs a high-privileged operation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in XueZhiSi Open Source Exam System versions up to 3.9.0 represents a critical failure in access control mechanisms, specifically manifesting as a Vertical Privilege Escalation within the teacher-end interface. The affected endpoint is located at POST /api/teacher/user/delete/{id}, which accepts a user identifier from the request path and proceeds to execute a sequence of database operations including retrieving the target user via getUserById(id), marking them for deletion by setting their deleted status to true, and finally persisting this change through updateByIdFilter(). The core technical flaw lies in the complete absence of authorization checks prior to these data manipulation steps. While the system correctly authenticates the requestor as a teacher with role level 2, it fails to verify whether that specific authenticated user possesses the requisite permissions to perform administrative actions such as deleting other accounts. This oversight allows any authenticated teacher to arbitrarily select and remove administrator accounts, which operate at role level 3, thereby bypassing intended security boundaries.
From an operational perspective, this vulnerability poses a severe risk to the integrity and availability of the examination system. An attacker with low-privileged access can effectively neutralize administrative controls by deleting admin accounts, potentially locking legitimate administrators out of the system or disrupting critical management functions. This capability undermines the principle of least privilege, which dictates that users should only have access to resources necessary for their specific roles. The ability to delete high-privilege entities without authorization checks creates a pathway for complete system compromise if combined with other vulnerabilities, although even in isolation it allows for significant disruption and potential data loss depending on whether soft deletes are permanent or recoverable.
This flaw aligns directly with Common Weakness Enumeration identifier CWE-269, which describes Improper Control of Interaction With User, specifically falling under the subcategory of improper authorization checks. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, where an adversary uses legitimate credentials to gain access and then escalates privileges by exploiting misconfigured permissions within the application logic rather than through technical exploitation of a software bug in the underlying operating system or database engine. The vulnerability is classified as CWE-269 because the failure occurs at the point of interaction with the user input, where the system fails to enforce role-based access control policies before executing sensitive operations.
To mitigate this vulnerability, developers must implement robust server-side authorization checks within the delete endpoint logic. Before invoking getUserById or updateByIdFilter, the application should verify that the authenticated session's role ID is equal to or greater than the minimum required role for administrative user management tasks. Additionally, implementing a centralized access control middleware can ensure consistent enforcement across all endpoints rather than relying on scattered individual checks. Input validation alone is insufficient; strict identity and permission verification must be performed using secure session tokens or JWT claims that explicitly define the user's privileges. Regular security audits focusing on Role-Based Access Control implementations are recommended to prevent similar logic flaws in other parts of the application.