Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-31T21:17:48.393Z",
  "pubdate": "2026-08-31T21:17:48.393Z",
  "executiveSummary": "The XueZhiSi Open Source Exam System, in versions 3.9.0 and earlier, is susceptible to a vertical privilege escalation vulnerability located within the teacher-end interface.\nThis security flaw stems from an authorization bypass vulnerability in the user deletion process, allowing authenticated users with lower-privileged roles (e.g., teacher) to execute administrative functions reserved for higher-privileged accounts (e.g., administrator).\nThe vulnerability occurs because the backend endpoint /api/teacher/user/delete/{id} performs sensitive data modifications without verifying the requester's authority or checking if the target user ID belongs to a higher-privileged tier.\nSuccessful exploitation allows a malicious teacher to delete administrative accounts, potentially leading to a complete compromise of the system's management capabilities, unauthorized service disruption, or denial of service.\nThe attack requires an authenticated session with at least teacher-level access. It does not require complex payloads or multi-stage injection, as it is a fundamental flaw in the application's access control logic.",
  "technicalDetails": "The vulnerability resides in the backend controller responsible for user management at the endpoint /api/teacher/user/delete/{id}. The root cause is a failure in the application's authorization logic, which fails to implement Access Control Lists (ACLs) or role-based access checks (RBAC) at the service layer prior to executing deletion routines.\nWhen a request is submitted to this endpoint, the application retrieves the user object via the getUserById(id) function. Subsequently, it proceeds to invoke setDeleted(true) followed by updateByIdFilter() to commit the state change to the database.\nThe security flaw exists because the execution flow assumes that any user capable of reaching this endpoint is authorized to perform the action. There is no validation logic comparing the role of the authenticated session (role=2 for teachers) against the role of the target user (role=3 for administrators).\nAn attacker can exploit this by simply intercepting a legitimate request to the user deletion interface and modifying the '{id}' parameter to correspond to an administrator's UID. Since the server-side code does not evaluate ownership or hierarchy, the database transaction is authorized and completed successfully.\nThe attack flow follows these steps: 1) The attacker authenticates as a user with teacher privileges. 2) The attacker identifies the target administrator's unique identifier. 3) The attacker sends a POST request to /api/teacher/user/delete/{target_admin_id}. 4) The server processes the request without validating if the attacker possesses the necessary administrative clearance. 5) The target administrative account is marked as deleted in the backend database, resulting in immediate loss of access for the administrator.\nThis vulnerability is classified as a broken access control issue leading to privilege escalation. It specifically impacts the integrity of user account management and administrative oversight within the XueZhiSi framework. Because the updateByIdFilter() method is used to persist the state change without verifying the caller's authorization context, the system remains vulnerable to unauthorized administrative deletions until the specific function-level security check is implemented."
}